Our goal is to primarily use only X25519 keys (i.e. encryption keys, Montegomery Curve), and for signatures to convert them to corresponding Ed25519 keys (signing, Edwards Curve). Such a practice is commonplace and is considered safe in this scheme. The key conversion from Ed25519 to X25519 is implemented in libsodium and thus is commonly available. Covert already implements to opposite conversion, as specified by Whisper Systems / Signal in their XEd25519 (XEdDSA) scheme.

The sign problem

One problem with the opposite conversion is that X25519 keys lack a sign bit that is present on Ed keys, meaning that a single key can produce two different public keys, and thus incompatible signatures. Signal's specification suggests forcing the sign bit zero, and by modifying the secret key so that it matches. We believe that this approach is bad, and it would appear that Signal have also abandoned it for another approach that actually stores the sign bit in an unused bit within the signature itself.

Rather than forcing or storing the sign, one can easily try verifying the signature with the bit flipped both ways. One will fail, but if the other passes, the signature is good. Therefore, this is not really an issue.

The hashing problem

In principle the secret keys of both schemes are identical, and only the public key needs conversion. However, it is a common practice to take sha512 of an Ed "secret key" (i.e. what is stored in the keyfile) to obtain the actual secret key used by the algorithms. Thus, a secret key converted back won't work, because this extra round of hashing breaks it. Unfortunately this hash operation is built deep inside libsodium/ref10, and cannot be disabled.

X25519 operations do not use such hashing but instead use the given secret key directly. The libsodium ed25519_sk_to_curve25519 conversion function does just this hashing.

Signal solves this by their own XEd25519 signing algorithm that omits the hashing. This is almost perfect for our intentions as well, except for the fact that there are no commonly available implementations of this signing algorithm, and maintaining our own Python implementation of it does not seem optimal. Also, the algorithm opts for simplicity and does not require the public keys to be entirely unique (fully reduced).

Choices

Thus, as for implementation, we have two main options:

1. Signal's XEd25519, which allows us to use any Ed25519 or X25519 keys, and stores the sign bit in signatures
2. Standard Ed25519 which can only work with Ed25519 keys

Option 1 seems more sensible for the future, where XEdDSA is expected to be implemented in crypto libraries, and if so, it would simplify Covert implementation.

Option 2 might be reasonable because nearly all keys that we might want to use come in Ed25519 format. SSH and minisign keys would work for encryption and signing but Age keys could only encrypt. We would need to handle keys differently depending on which format they were sourced from.

Leaving the issue open for discussion.

Covert needs persistent keystore to avoid always typing keys on command line and more importantly to enable forward secrecy in conversations (because temporary keys need to be stored somewhere).

This is a draft implementation that still contains bugs ~~and does not implement anything but static keys.~~

covert enc -I alice:bob -i ~/.ssh/id_ed25519 -R github:bob   # Encrypt a message, store keys in database
covert enc -I alice:bob   # Encrypt another message using the stored keys

If the sender profile (alice) does not exist, it will be created. If no -i is provided, a new keypair is created. Keys may be replaced later by providing another recipient or -i arguments. It is planned that bob won't need to add alice's key when replying. In near future this should also enable a conversation mode where replies have forward secrecy and post-breach secrecy. The profile names are strictly local and are never sent to peers.

The ID store is protected by a longer than normal 5-word passphares, which is automatically created the first time the keystore is used. All profiles share the same master passphrase.

Breaking change: Signatures of upcoming 0.7 will be incompatible with prior versions.

TODO:

• [x] Public ID key storage and automatic generation
• [x] Use ID-based keys, display IDs in authentication and signatures instead of raw keys (CLI)
• [x] ID management (key export, changing of passphrase etc) covert id subcommand
• [ ] ID selection dropdowns and other functionality based on ID store (GUI)
• [ ] Daemon (agent) that remembers the passphrase for a while
• [ ] Time-based expiration of keys (locally, not planned to be included in messages)
• [x] Code cleanup / refactoring & UX polish
• [ ] Workflow to "reply" to messages in an easy way (CLI, GUI)
• [x] Forward secrecy in conversations

Three bits of information per file were still leaked in ephemeral keys, weakening the deniability property. This is fixed by implementing dirty keys that use all eight of Curve25519 subgroups rather than only the prime group.

Also implements and uses Signal's XEdDSA (XEd25519) for signatures as is written in Covert specification. Previous versions used EdDSA instead, making it impossible to sign with Age and Wireguard keys. Now all key types are good for both signatures and encryption.

Fixes #55 Fixes #2

Improved low order point encoding that is now inconsistent with libsodium and monocypher but more logical and able to represent all low order points correctly. The point at infinity is encoded as u=-1 (mod p), which is not a curve point and has no birational mapping to Ed25519 anyway (division by zero), while everything else uses the standard mapping and encoding specified in RFCs. Similarly the Ed25519 neutral element (ZERO, equivalent to the point at infinity) cannot use birational equivalency as it too causes division by zero due to its y coordinate being 1.

Hi,

I’ve been pointed to your work, and I see you’re using my work for exactly what I wanted it to be used, that’s nice!

I think I found a bug, that makes the encrypted archives easily distinguishable from random. It’s a subtle, easy to miss issue about Elligator2. Here’s the culprit: you’re taking a freshly generated public key from vanilla X25519. The error is using vanilla X25519.

See, Curve25519 is not quite a prime order group. It has a non-trivial cofactor of 8. DJB got around the issue by inserting special precautions in the design of X25519. One of them was making sure all the generated points are in the prime order subgroup, which comprises only one eight of the curve. (He does this by clamping the scalar down to a multiple of 8).

Elligator2 however operates over the whole curve, not just the prime order subgroup. So when an attacker sees the file and tries to unhash the key, they’ll notice that all the resulting points always happen to be on the prime order subgroup. (To verify which subgroup a key belongs to, you can just multiply it by its order L.) With truly random files this is supposed to happen only one time in 8.

In other words, for each file you encrypt, you expose 3 bits of evidence to the attacker that this is an encrypted file, not a truly random one. (Now one might suspect things about random files, but those 3 bits can also leak part of the file format, and my guess is that you want to hide as much meta data as possible.)

To correct the problem, you need to generate points on the whole curve, not just the prime order subgroup. You need a "dirty" X25519 key somehow, yet still retain full compatibility with vanilla X25519. You need Monocypher’s crypto_x25519_dirty_fast().

Now I see you’re mainly using Libsodium, and only pulled my Python Elligator2 code (which by the way is not constant time, though it probably does not matter for offline uses). The problem is that Libsodium has no way that I know of to generate the dirty keys you need. (Last time I checked Frank Denis was explicitly not interested in supporting indistinguishability from random.)

My recommended course of action is to use Monocypher’s high-level crypto_hidden_key_pair() function. The third party Pymonocypher bindings may help you there. It will fix both timings & indistinguishability issues.

Cool project first off all.

Running pip install covert downloads version 0.2.1 which is weird. I thought maybe i have a cached old version of covert so i tried --no-cache-dir --force-reinstall commands. Same result, v 0.2.1)

Running pip install covert==0.5.3 shows the following error :

ERROR: Could not find a version that satisfies the requirement covert==0.5.3 (from versions: 0.2.0, 0.2.1)
ERROR: No matching distribution found for covert==0.5.3

This issue maybe is only on my computer but i thought maybe it's something worth checking.

In the homepage i prefer if you change the pip install command to pip install "covert[gui]" (with double Quotation marks).

In addition, writing a good Installation guide for covert must be done, and a guide on how to build/run the code from source, Dev environment, etc. This will save a lot of time for interested people to take a look at the project instead of spending some time and effort to figure how to run it. Good luck!

Thanks!

Implements covert edit CLI command that extracts an existing archive, allows editing its text and then re-encrypts the data. Any attached files of the archive are kept without extracting them or the message to disk. The original file is overwritten.

This function is intended to allow adding and removing attachments, as well as using public keys, but for now it is limited to message editing and passphrases. Also, all data must fit in RAM, as no streaming is yet implemented for this mode.

Fixes #57

This error occurs when I use qcovert and choose Open Covert File, an armored or unarmored passphrase-encrypted text file.

The file can be decrypted at the command line.

Traceback (most recent call last):
File "/home/ap/.local/lib/python3.10/site-packages/covert/gui/app.py", line 104, in decrypt_file
self.decrypt(data)
File "/home/ap/.local/lib/python3.10/site-packages/covert/gui/app.py", line 109, in decrypt
d = DecryptView(self, infile)
File "/home/ap/.local/lib/python3.10/site-packages/covert/gui/decrypt.py", line 35, in __init__
self.decrypt_attempt()
File "/home/ap/.local/lib/python3.10/site-packages/covert/gui/decrypt.py", line 105, in decrypt_attempt
if self.blockstream.header.key:
AttributeError: 'BlockStream' object has no attribute 'header'

From here, nothing happens - we are at the main screen.

Example (armored) file --

Password is oakpigartbecome

Unz4TxF16QTcqbtEbpc56IgOm+gmaIbD+/dpcIVeTc1PH8b9DQevQ5SsMum99yhgRAByRKJ360tDCo8yLEogl3kGNCw3ISbH161ux7EVvQZCPJF6JfyVQ4Cq/6fCd1fBK2eOqKXf4w6atfIS+NCP8V2eBbfJrog0w73jVQ

Installing covert from pip, a few dependencies weren't pulled into my system required for qcovert to run properly:

• PySide6 (pip install pyside6)
• showinfm (pip install show-in-file-manager)

These don't appear to be part of any default install on my Kubuntu system, at least.

Hi, what's the process for reporting security vulnerabilities?

(FYI: GitHub automatically treats the file docs/Security.md as the project's security policy, but that file actually contains information about the encryption format rather than instructions for reporting security vulnerabilities.)

Implemented a thread for opening a file using mmap in the decrypt_file() function in /gui/app.py. It was listed as a TODO item to replace the with open() call.

AEAD schemes are vulnerable to an invisible salamander attack where one ciphextext may decrypt to many different plaintexts depending on the key used. The process involves creating at least two different keys and manipulating the ciphertext blocks such that desirable decryption is obtained. There will be a lot of random noise in the messages but with a bit of brute forcing for suitable keys it is possible to find keystreams that produce for a few bytes two messages so that the garbage is ignored (the original paper demonstrated making the data seem either as JPEG or BMP, depending on a few header bytes that would skip the other image and the rest of the garbage). The attack applies to ChaCha20-Poly1305 which is employed by Covert, as well as to AES-GCM and other AEAD constructs.

Covert should probably implement a key commitment header that contains a 12-byte hash of the file key. This avoids the aforementioned exploit (that does affect all other kryptographic software based on AEAD where keys may be chosen maliciously), and it could also make testing for recipient keys a bit easier, not having to brute force block0 location and size, as is currently done. Only after a matching key is found, does one need to go looking for block0. Adding this would be a breaking change to all existing users. We can implement legacy mode to also support the old format for now, but that would be removed prior to 1.0 release.

Normally the recipient controls the keys, so this is not an issue, but there are a number of cases where it can be.

The signature scheme (which is based on signing the Poly1305 tags) is broken: When a file has multiple recipients, one recipient can carefully edit the blocks in a way that leaves the Poly1305 tags unchanged. Other recipients will not be able to detect the modification.

This is because Poly1305 is not a cryptographic hash function. Knowledge of the key allows an attacker to construct almost-arbitrary plaintexts that have a desired Poly1305 tag.

I don't have a proof-of-concept, but I think this is apparent from the definition of Poly1305. I can probably construct an example if requested.

Suggestion: Compute a cryptographic hash of the plaintext data, then sign that hash (and encrypt the signature). Some suggestions for hash functions:

• SHA-512 (which is also used internally by Ed25519)
• BLAKE2 (which may be faster than SHA-512).

It will probably be a little slower than Poly1305, but that can't be helped.

Also, the scheme used to encrypt the signature is very suspect. It uses filehash[:32] as the encryption key and hash(filehash + recipient_public_key)[:12] as the nonce. But filehash is public (it is a SHA-512 hash of the Poly1305 tags, which are appended to the ciphertext and are therefore public). So if an attacker knows the recipient's public key, the attacker can decrypt the signature block. And if the attacker doesn't know who the recipient is, they can use the signature block to test known public keys and determine if they are the recipient.

Suggestion: Encrypt the signature using a secret key.

Finally, a minor comment (which may soon be irrelevant): The scheme for calculating filehash repeatedly calls sha512, but there is no apparent reason for doing so. It would be faster to just compute the SHA-512 of the concatenation of all the values to be hashed.

XEdDSA requires a 64-byte nonce as additional security against such a case where the same message was signed many times and a computational error or a side channel leak could then reveal the secret key. Such additional security is not of any use in the case of Covert where the message itself is always different, and would not be necessary in any case if an implementation was free of side channel leaks and the CPU was not broken. There is discussion of this trade off in the Signal XEdDSA specification and in RFC 6979 as well as in Bernstein's Ed25519 paper.

The message being signed in Covert is the file hash which should already be unique for each file, even if everything else stays the same, because it depends on the file nonce which is randomised. This patch removes the unnecessary use of additional random bytes on signatures and instead implements deterministic XEdDSA by using the file hash as both the message and the nonce (staying compatible with XEdDSA which requires a 64-byte nonce, rather than omitting the nonce from SHA-512 hashing).

The choice of nonce in signatures does not affect signature verification, and thus each implementation is free to do this whichever way they prefer without compatibility concerns. The nonce only affects the secret random commitment r, whose corresponding public key R is published as part of the signature.

It would be good to have wordlists for languages other than English. We intend to create our own, following the principle of unique 3-prefixes as with English (for easy autocompletion and avoiding prefix word issues). Further, it would be ideal to avoid accented characters and pick words that only use ASCII in all languages where that is feasible (Spanish, German etc). Each language should have its own list of 1024 words, which is a low enough number so that common words and names can easily fill the list (and adding more doesn't make passwords much more secure).

Chinese and other Asian languages are a whole different ordeal. They may require other arrangements as well and probably cannot have autocompletion. If any native speaker of such languages is reading, would you consider a minimum password length of 8-10 randomly picked characters (pictograms) too long or too complicated? Which characters or words should be used on the list of autogeneration?

Help is wanted: anyone speaking a language other than English is invited to comment on this, so that we could find an ideal solution for everybody.

We also need large wordlists of many thousands of words as input. The lists should contain some information on which words are more common (either contain only common words or rank the words by how common they are), and ideally should contain well known names as well (many dictionaries don't and lose a good opportunity). The largest lists or text corpus don't need to be cleaned of punctuation and other garbage. We cross-reference several lists and apply automatic cleanup and filtering to find candidates for the 1024 words to include in our wordlists. Please post links to any usable lists here.

Decoding of keys, in particular of encrypted minisign and ssh secret keys, is not tested adequately. A single unit test for each of those using the keys within tests/keys/ should be added, and ideally also the various error checks should be tried. The ssh password is password while the test key for Minisign has an empty password.

These use cryptographic functions not used by any other parts of Covert, so having them tested is not only about our code quality but also to avoid regressions if we switch cryptographic libraries.

Both have a lot of error checking and special conditions that are never hit in normal operation, thus needing specialised tests that hit every line of code there, to avoid otherwise hard to find bugs. As an added difficulty, Minisign password hashing is so slow that we want to avoid doing more than one true run of that in automated tests. Other cases (such as incorrect password entry) need to be tested by mocking those functions to go faster. Not a particularly easy task to do, but someone with advanced coding skills would be welcome to pick up on this, despite not knowing the cryptography very intimately.

Currently it returns a tuple (password, ~~valid~~ visible), which is not meaningful for non-Covert passwords. Should refactor this utility function ~~not to return validity but rather handle that via a separate function call if needed.~~