Long Wiki Edits Thread

Could you please slightly update Full Disk Encryption (FDE)? @HulaHoop

The plausible deniability feature is available with volume types Normal+Hidden Truecrypt/Veracrypt. Veracrypt volumes support crypto-cascades as a feature, so manual nesting is unnecessary. However, be warned that Truecrypt/Veracrypt volume types only support AES-128. Plain dm-crypt containers with a non-zero offset can be used to provide hidden volumes according to Zulucrypt’s manual. This is yet to be tested by Whonix ™ developers.

As is could be misconstrued as endorsement of deniable decryption?

It may be possible to get plausible deniability on Linux hosts using methods other than those listed below, but the topic is a rabbit hole (see footnotes). [2]

That reference is offline and not archived.

Plausible deniability and Full Disk Encryption (FDE) are also useless if subjected to physical abuse by a captor.

Could you please add its own chapter for plausible deniable encryption?

Could you please also add that in some scenarios it is actually better to avoid using software with plausible deniable encryption? Using such software by itself is suspicious. If one unlocks the decoy disk and the adversary is not happy, one might face indefinite detention or worse, if there really is no hidden volume. Related to that, is this article any good to link to or quote from?

Sleep mode:

Hibernation is also a safe alternative because the swap partition is encrypted in the default FDE configuration for various platforms (like Debian), so long as no changes were made.

But cryptsetup LUKS key does not get wiped from RAM.

systemd feature request: cryptsetup luksSuspend (wipes encryption key from kernel) on suspend [archive]

Perhaps own chapter for sleep mode too?

new wiki page:

new wiki page::

new wiki page:

I guess so.

Unfortunately the wikimedia archiver plugin isn’t able to detect when the target link doesn’t allow wayback crawling. So it’s lost forever

OK I’ll find something

That was not meant for the cold boot attack model. Merely making the user aware that leaving their system in hibernate is safe as opposed to standby (without cryptsetup-suspend).

Perhaps belongs as a sub-chapter of the coldboot page?

EDIT:

1 Like

You mean the [Archive] links in Whonix wiki? These are just links.

It for example takes
https://askubuntu.com/questions/486297/how-to-select-video-quality-from-youtube-dl
and then adds a new [Archive] link with
https://web.archive.org/web/https://askubuntu.com/questions/486297/how-to-select-video-quality-from-youtube-dl
but it doesn’t have any auto archiving feature. It’s just a small usability enhancement. Should any link be offline, try clicking [Archive]. Might be lucky.

But help is still required. Specifically when adding new links. Click the archive link for yourself. See if it’s archived already. If not, hit the Save button on web archive. Only then it will be archived.

I haven’t found any mediawiki extension capable of auto arching links. Only GitHub - internetarchive/internetarchivebot but that looks difficult to setup.

1 Like

I see. Is there anyway to enumerate the references for th entire wiki in one page/list so I can manually start checking that everything is preserved?

Not really.

The markdown backup might come handy.

grep -r '\[http://'

and

grep -r '\[https://'

Was looking at Special pages - Kicksecure. Most useful thing I found was this:

Something under 5000 links. Could be a lot duplicates though. Even if there was a list, I doubt it’s possible do that manually? This would need to be scripted.

  • generate list of links probably starting by greping Whonix / whonix-wiki-backup · GitLab
  • drop links which are already pointing to web archive
  • check if link is already archived
  • use (already existing) web archive cli tool to ask web archive to archive it
  • wait a few seconds to not hit web archive rate limits

Can you make a regex to extract links from a line? Example line:

Metadata.mw:| text = In recent times, leakers of high-value or high-security source documents have been identified (and jailed) via [http://blog.fastforwardlabs.com/2017/06/23/fingerprinting-documents-with-steganography.html embedded steganographic messages] or the [Fingerprinting with Zero-Width Characters zero-width space (homoglyph substitution)] technique. In the latter method, the leaker is unable to see additional zero-width or zero-width non-joiner characters which are used to fingerprint text. Even a single type of zero-width character provides enough bits of entropy to fingerprint the relevant text.

Required result:

[http://blog.fastforwardlabs.com/2017/06/23/fingerprinting-documents-with-steganography.html embedded steganographic messages] [Fingerprinting with Zero-Width Characters zero-width space (homoglyph substitution)]

(Or with newline. Even better.)

And another regex to convert for example.

[http://blog.fastforwardlabs.com/2017/06/23/fingerprinting-documents-with-steganography.html embedded steganographic messages]

to

http://blog.fastforwardlabs.com/2017/06/23/fingerprinting-documents-with-steganography.html

I need help with the regex for creation but the rest I think I can script.

But does this need to be invented? Are the other tools or services which scan an entire website and start to archive all external links?

1 Like

The original (deleted) page from cellebrite:

This can maybe fit somewhere in the wiki.

1 Like

https://nitter.net/moxie/status/1337434126186553345

According to moxie (founder of signal):

" This (was!) an article about “advanced techniques” Cellebrite uses to decode a Signal message db… on an unlocked Android device! They could have also just opened the app to look at the messages."

Claims stay claims until being proved by cellebrate.

1 Like

It should not be added to the wiki. Cellebrite had an unlocked and rooted device to read local messages. Having full filesystem access to the device obviously grants you full filesystem access. Haaretz was duped into publishing nonsense. You can see that Cellebrite removed the original article out of embarrassment. Also see: Broken Encryption · Issue #10277 · signalapp/Signal-Android · GitHub

The Signal protocol is still safe.

2 Likes

I already clarified the position of that article by moxie response. But on the same time it doesnt worsen anything when adding cellebrite claims and the debunked responses by moxie or signal.

1 Like

That may be alright. If doing so, you should add these links also:

2 Likes

Another one:

Also the edit of Bruce Schneier’s article:

https://www.schneier.com/blog/archives/2020/12/cellebrite-can-break-signal.html

I need to apologize for this post. I finally got the chance to read all of this more carefully, and it seems that all Cellebrite is doing is reading the texts off of a phone they can already access. To this has nothing to do with Signal at all. So: never mind. False alarm. Apologies, again.

2 Likes

Thunderbird wiki if we need to upgrade the instructions without the need of enigmail plugin there are 2 ways to do that:

1- Ether use Thunderbird internal OpenPGP
2- Or use external tool

first method is maybe more convenient since its all happening within the same application but the downside of having this feature is efail and snowden recommended against that and better using external tools to do the encryption

Second method less convenient but its what recommended to be used. In our case GPA is shipped by default within whonix.

So which one we should add and upgrade the wiki with?

1 Like

TNT_BOM_BOM via Whonix Forum:

the downside of having this feature is efail and snowden recommended against that

Citation required.

Was a bug in enigmail that was patched and may very well be accounted for with the new TB crypto implementation. Instructions should direct users to Thunderbird which has the best usability. Stuff is hard as it is.

1 Like

https://efail.de/

Short term: No decryption in email client. The best way to prevent EFAIL attacks is to only decrypt S/MIME or PGP emails in a separate application outside of your email client. Start by removing your S/MIME and PGP private keys from your email client, then decrypt incoming encrypted emails by copy&pasting the ciphertext into a separate application that does the decryption for you. That way, the email clients cannot open exfiltration channels. This is currently the safest option with the downside that the process gets more involved.

And snowden he said it in one of his videos on youtube.(i need to dig into too many hours to find it but efail attack enough to explain)

1 Like

Could you review Full Disk Encryption: Difference between revisions - Whonix please? @HulaHoop

1 Like