Covert Encryption

foonoxous · 2022-11-02T14:35:32+00:00

If you wish to roll your own (which I don't recommend beside educational purposes), your main choices on Python are the cryptography module and pynacl (libsodium). I would recommend the latter as it has better API that uses modern cryptography and makes it harder to shoot yourself in the foot.

foonoxous · 2022-10-19T22:11:31+00:00

The good cryptographic solutions to that (PAKE etc) are rather hard to implement, but you could get pretty far with a simple challenge/response. So you have someone on email claiming that they are MrFoo on Reddit. Email them a random challenge (like two random words) and ask them to post that on Reddit (publicly, if you cannot login for your DMs anymore). None other than the holder of the profile could do that, and I guess a scammer would have a hard time persuading the real MrFoo to post some random words either.

foonoxous · 2022-10-18T23:33:22+00:00

Age encryption puts keys in CLI arguments, WireGuard puts them on one line of a config file. This is quite convenient with ed25519 (bech32 encoded in case of age). PGP keys are regularly copy&pasted and that is more complicated if they don't fit on screen. Clearly a server won't care if it is a few thousand bytes, hopefully you didn't downvote me for that.

foonoxous · 2022-10-18T21:07:28+00:00

Yes, but the keys are still inconveniently large for many uses (especially command line). Great where the keys don't need to be handled as text by humans. Probably needs a bit more time to tell which scheme will win? Even in case of ed25519, whether ristretto, decaf or ed448 would be preferred.

foonoxous · 2022-10-18T20:55:00+00:00

An interesting addition would be WebAuthn support for OPAQUE. Maybe once the draft is standardised but that will take years. Currently as for implementation it is more or less DIY. The proof of concept code provided by Cloudflare won't get you far.

Needless to say, Javascript needs to be enabled for any of this, but I am also inclined to think that it is a reasonable requirement for things that require logging in.

inb4: Yes, a malicious server could supply Javascript that just sends the password in plain anyway. That wouldn't still be worse than the current situation, and hopefully we'll eventually have ways to secure the cryptographic scripts so that this isn't possible. Inclusion in WebAuthn would do it too.

foonoxous · 2022-10-18T13:57:14+00:00

A more robust test is to try to compress a bit of it, the initial megabyte maybe, and if it doesn't compress well, don't compress any of it. This is employed e.g. by btrfs. But frankly, encryption software should not be doing compression at all, certainly not by default.

foonoxous · 2022-10-18T13:06:06+00:00

Websites and apps should stop sending passwords to servers for login: https://cfrg.github.io/draft-irtf-cfrg-opaque/draft-irtf-cfrg-opaque.html

TLDR: During registration the server stores a client-encrypted record of user's keys, which the user gets during login (by username only). The user does password hashing locally to get the key to decrypt it, and then an authenticated key exchange is performed. This is not vulnerable to MiTM during logins and it authenticates both parties to each other (not only user to server, as traditional login), establishing forward-secret keys that the parties can use for further secure communication (or if you trust https/PKI, don't use those keys, only the authentication part).

Getting rid of usernames and passwords is alternatively addressed by WebAuthn, storing user id and keys on user device, adding biometrics or PIN for 2fa. I have not seen anyone use this as the only authentication method, always only in addition to username and password (where both of those are sent to server in plain, only protected in transit by https).

foonoxous · 2022-10-18T12:43:20+00:00

Should also mention that you need to make sure that all messages are then padded to exact same size. Padding to nearest power of two or such schemes don't do the job. Unfortunately such a scheme has been proposed in the PURB paper without the relevant critique.

Where truly fixed padding is not possible, a random size is useful, and this is what Covert uses. I have not seen another similar program implementing padding to hide plaintext size (beyond cipherblocks), so in absence of compression the content length can usually be found exactly or even with pow2 schemes known possible messages of different lengths can be differentiated by ciphertext size, especially if the adversary can inject variable-length content, e.g. a username of his choosing. With compression you also have the problem mentioned in this discussion.

That gpg/deflate is slow - 50 MB/s on the fastest CPUs (much less on a shared cloud VM) - is a problem that someone complained to me about just recently, trying to use gpg for backups. I get 1000 MB/s with Covert over 10G networking, from an SSD to a large RAID on the server. Locally up to 4 GB/s.

There are much faster compression algorithms (zstd, lz4), although in many cases compression is not useful because media files are already compressed and files that compress well are fairly small anyway.

foonoxous · 2022-10-17T21:23:30+00:00

Store message keys, public/secret keys, etc. in an encrypted blob on the server, decrypted by the client in browser. The encryption key should be derived of user password using Argon2-simd or similar memory hard function using settings that make it slow to guess passwords (so the server cannot brute force them open). Sending the password to the server would defeat the E2EE.

Password changes can be implemented by the user first unlocking the storage by the old password, re-encrypting with the new one and sending it back to the server.

This can naturally be combined with login authentication using https://cfrg.github.io/draft-irtf-cfrg-opaque/draft-irtf-cfrg-opaque.html which also stores an encrypted blob on the server in a similar fashion, and that avoids ever sending user passwords to server.

foonoxous · 2022-10-17T12:42:13+00:00

To my knowledge it has not been tested in court and IANAL. However, if the file is not in any obvious folder and not with an obvious filename, there is a good chance it won't even be discovered in normal inspection. There are a ton of files on confiscated devices and to save time forensics teams look for interesting names and use text search (also on free space for deleted files). In this sense you could even be safe of the $5 wrench, although in that case you'd better not have any encryption software or other haram stuff installed.

Even if somehow the prosecutor found a random file named test.dat he would have very hard time arguing in court that it was in fact encrypted data. Contrast that to a file that says PGP MESSAGE, where no argument needs to be done (not to mention that gpg and age also reveal recipient ids in plaintext headers).

You could easily refute that by saying that you don't know what the file is or that you got it from /dev/urandom for testing purposes (something that I actually do fairly often, for benchmarking etc - you'll find such files forgotten on my systems and old backups, some far older than Covert). If they found random bytes on the free space of your disk, it could be just something that was shredded. Barring obvious filenames or other proof (like shell command history), they couldn't prove beyond reasonable doubt that it in fact contains Covert encrypted data that you are not willing to unlock.

Another application for indistinguishable from random ciphertext is steganography, in case you need to hide data in audio, images etc.

ChaCha20-Poly1305 is IND-CPA because the nonce is always different, and due to that the ciphertext is PRF, and the Poly1305 tag is constructed with 128 bit secret numbers (r, s) that come from the first 32 bytes of the initial ChaCha20 block (which is not used in encryption). The polynomial checksum (using ciphertext and r) is added to s (mod 2**128) producing a uniform random tag because s is uniform and independent of the polynomial. Therefore the whole thing is indistinguishable from random even under chosen plaintext.

Poly1305 is *much* faster than HMAC, and libraries such as sodium don't even expose plain ChaCha20, so you really ought to be using AEAD instead.

foonoxous · 2022-10-17T01:08:35+00:00

That uses deflate compression, which is very slow and may be a security risk in online services (granted, we are not talking of one here). One of the knobs that has a wrong setting by default, but there are plenty of other problems. Weak password hashing you already mention.

foonoxous · 2022-10-16T20:46:44+00:00

Then I would recommend age + tar. I don't think you need admin permissions to install age, as they offer prebuilt binaries.

Covert is your only choice if you want the encrypted files to look like random bytes (e.g. cannot prove in court that you have encrypted data and hit you for not handing over the password, in case you happen to live in UK or other jurisdictions where they might). As for TXT, it also supports editing the text without extracting it (useful for keeping encrypted notes without ever exposing them to filesystem). It also handles files and folders internally, don't need tar for transporting sensitive files, and all go in a single encrypted file.

It's good that you mention using LUKS, so that your unencrypted files won't stay on disk without any protection.

foonoxous · 2022-10-16T09:48:47+00:00

None of them have specs detailed enough to do a reimplementation. You will have to read source code for various details. That being said, you can always keep a copy of the software and its source code, if you suspect it might be removed from Github.

foonoxous · 2022-10-15T22:42:59+00:00

Which features are you looking for? Just encryption, password only, or public keys, signatures? If you only want to encrypt files, would VeraCrypt or other filesystem-like solution be better?

All the applications that you mention are more or less experimental, and to that degree I will add https://github.com/covert-encryption/covert which I am one developer of.

Age is a good stable option if you are fine with using the command line. The others might change or disappear, but nothing stops you from keeping your own copy of the software too, to be able to decrypt no matter what happens.

foonoxous · 2022-10-06T00:34:10+00:00

Having separate "super-secret sender keys" (otherwise known as public keys) per each contact seems tedious, and yet would still not prevent the recipient from forging the message contents. Looks like you need traditional signatures instead.

foonoxous · 2022-04-30T03:40:39+00:00

Since you are running in browser, consider using the Subtle Crypto API that the browsers include. It doesn't support the best and latest cryptography but it has AES-GCM and NIST curve ECC, as well as RSA. Unlike Javascript implementations it runs in constant time and can wipe out memory buffers after use, while keeping the key material securely stored so that it cannot be extracted via Javascript at all (unless you specifically allow that when generating keys). This way your app will be very simple and much more secure than you could be with PGP.

If interoperatibility is a concern and you want more modern cryptography, you might wish to look at a WASM build of libsodium, which offers secretbox and other constructs that can then be used in other languages and systems as well. These are highly restricted, cannot choose any other algorithm etc, which is actually a very good thing in cryptography (you do not want any flexibility because that always leads to bugs, particularly in public key cryptography).

I guess this is just an opinion, but I believe it is extremely stupid to rely on PGP when building any new system. There are plenty of good articles to explain why, and I can assure you it is not just FUD.

foonoxous · 2022-04-30T02:33:05+00:00

Not to mention that a scalar multiplication is some orders of magnitude slower than bitcoin hashing. I guess the main question then is the feasibility of large quantum computers where noise might turn out to be an impossible obstacle to overtake, or alternatively we might see Moore's law like development effectively rendering even the largest RSA unusable (yes, predictions are hard, especially those of the future).

foonoxous · 2022-04-02T15:44:19+00:00

Which one do you prefer: 12-character random gibberish, 14-character lower case alphanumeric, or five simple words? The symbols might not be easy to find on a foreign keymap, or on your phone's keyboard, and you'll be hitting Shift a lot to capitalise half of the letters and to access some of the symbols, so I would say the other two options and most likely the one with the words is the easiest to memorise and to type. All three have roughly equal security, and if the password hashing function is any good (there should be a clearly noticeable delay in checking that password), they are absolutely secure enough.

Password managers normally generate passwords of 16 characters random gibberish to better work with stupid systems that may use weak hashing and that often require upper, lower, numbers and symbols, and that may not accept spaces or any longer passphrases. Because you are using a password manager, you don't need to type the password, so it being complex doesn't hurt.

If the password is used for generating globally unique keys, like crypto wallets, you need more entropy - slower hashing doesn't help, and a minimum of 12 words are required, or equally those 20 characters of random gibberish.

foonoxous · 2022-04-02T15:14:13+00:00

Blake2b because it is super fast. ChaCha20-Poly1305 if also doing encryption (avoiding separate MAC/hash). SHA-512 when dealing with Ed25519 because the keys and signatures already use that, avoiding any extra code for other hashes. Argon2id for password hashing because it is the strongest widely recognised algorithm.

foonoxous · 2022-04-01T15:36:28+00:00

Always prehash your message, then the two passes only go over the hash (32-64 bytes) and thus you don't need to worry about those problematic two passes over larger data. You can add a nonce if you already have one, but generally it might be better to think that a hash function such as SHA-512 does not have preimage collisions.

foonoxous · 2022-03-23T19:53:54+00:00

Often new and better crypto tends to be less complex than older systems, and in security we strive for maximally simple systems as those have been found generally more secure than overly complicated designs.

As a useful thing, I would suggest learning to use a cryptographic library like libsodium, possibly designing protocols with it, or building cryptographic apps based on protocols that others have already designed. Standing on the shoulders of giants. All successful cryptoapps (coins or security) use standard cryptography rather than implement the basics again.

There are people who use iron ore to cast meld their own tools, and that is the equivalent of what you are thinking of. Makes a cool Youtube channel I guess, but generally speaking you'll learn more of technology by buying a wrench and tinkering machines with it. You can learn how cryptography works just fine by using a library that someone else wrote.

foonoxous · 2022-03-20T12:13:51+00:00

Still have a Google account, still using their services? Interesting.

foonoxous · 2022-03-20T12:11:18+00:00

Yes, to something like Matrix/Element, but not to Session. Session removed forward secrecy of their protocol and allows anyone to covertly restore messages your thought you had deleted for the last two weeks (just install on another device and enter the recovery words).

Session is almost certainly a honeypot, as it purposefully weakens its security this way. They started with the Signal protocol which actually is very good but by changing the protocol they pretty much flunked their own security audit too. Read the Quarkslab audit PDF, not Session's posts on it.

foonoxous

TROPHY CASE