covert-encryption commented 2 years ago

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

codecov[bot] commented 2 years ago

Codecov Report

Merging #81 (4ead68c) into main (f9343a0) will increase coverage by 3.12%. The diff coverage is 91.62%.

@@            Coverage Diff             @@
##             main      #81      +/-   ##
==========================================
+ Coverage   75.43%   78.55%   +3.12%     
==========================================
  Files          23       27       +4     
  Lines        2190     2649     +459     
  Branches      513      609      +96     
==========================================
+ Hits         1652     2081     +429     
- Misses        419      431      +12     
- Partials      119      137      +18

Impacted Files	Coverage Δ
covert/passphrase.py	`59.58% <0.00%> (-0.42%)`	:arrow_down:
covert/path.py	`81.81% <81.81%> (ø)`
covert/cli.py	`82.03% <87.16%> (+3.10%)`	:arrow_up:
covert/__main__.py	`96.09% <87.50%> (-0.53%)`	:arrow_down:
covert/idstore.py	`89.92% <89.92%> (ø)`
covert/clihelp.py	`93.93% <93.93%> (ø)`
covert/blockstream.py	`87.80% <96.00%> (+0.75%)`	:arrow_up:
covert/cryptoheader.py	`95.12% <100.00%> (+3.69%)`	:arrow_up:
covert/ratchet.py	`100.00% <100.00%> (ø)`
covert/tty.py	`18.09% <100.00%> (+4.33%)`	:arrow_up:
... and 4 more

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update f9343a0...4ead68c. Read the comment docs.

heikkiorsila commented 2 years ago

If the sender profile (alice) does not exist, it will be created. If no -i is provided, a new keypair is created.

Would it make sense to not create a new sender automatically, but ask for a confirmation (y/n) before creating a new key? There is a small possibility of a typo in sender name. Creating unused redundant keys is bad. It does not matter for receiver names much.

covert-encryption commented 2 years ago

Would it make sense to not create a new sender automatically, but ask for a confirmation (y/n) before creating a new key? There is a small possibility of a typo in sender name. Creating unused redundant keys is bad. It does not matter for receiver names much.

There certainly could be a prompt when running in a terminal. Probably needs to default to "yes" in non-interactive use.

covert-encryption commented 2 years ago

Static keys fully implemented and working but still needs further work on UX and an implementation of temporary or ratchet keys. On decryption any keys in ID store are automatically tried before asking for passphrase, and the -I parameter is only used on encryption.

I plan to add -I for decryption too, to specify where to save any keys received, if the peer is not already known (in which case it can be matched automatically). Alternatively, random peer names could be created whenever decrypted using some identity from the store but with unknown peer, and implementing renaming of IDs separately via covert id subcommand.

covert-encryption commented 2 years ago

# Generate a keypair (new id:bob) and use it as a recipient
covert enc -I bob:bob ...

# Generate another keypair (new id:alice) and use the existing local id:bob as recipient
covert enc -I alice:bob -A
 🔒 covert    🔗 id:alice:bob 🔷 01e502fd4e5eda4a5cef9513  🖋️ id:alice  📋 copied

# Decrypt the message just created
covert dec -A
 💬
Hello
 🔑 Unlocked with id:bob
 🔷 File hash: 01e502fd4e5eda4a5cef9513
 ✅ id:alice Signature verified

covert-encryption commented 2 years ago

covert id --secret      # List all stored keys in Age format
covert id alice         # Create idstore and/or generate/show the public key for ID alice
covert id --passphrase  # Change the master password
covert id alice:bob --delete
covert id --delete-entire-idstore  # With shredding

covert-encryption commented 2 years ago

Basic CLI for forward secrecy as of now:

covert enc --id alice:bob -r (bob's public key)  # Initial message

Multiple initial messages may be sent, all use normal public key format. Bob needs to decrypt one or more of them, in any order:

covert dec   # Using bob's key already in idstore, decrypts the message as normal
covert dec -I bob:alice   # Additional parameter to make Covert store Alice's keys and start a conversation
covert enc -I bob:alice   # All messages sent use forward secrecy and require no key inputs

Alice receives and responds

covert dec   # Conversation automatically detected as alice:bob, no need for parameters
covert enc -I alice:bob

covert-encryption commented 2 years ago

This PR is getting big, and I will need to do major code refactoring for cleanup before proceeding with further tasks. Since the refactoring will make diffs unusable, I am asking for a review at this point - to get the biggest problems fixed but no full QA prior to merge - so that work can continue with another PR keeping the diffs and the scope of review reasonable.

covert-encryption commented 2 years ago

I am considering to entirely remove support for creation/modification of local keys via covert enc, as that is now supported via covert id which seems more suited for the job. Adding recipients on encryption remains a useful convenience shortcut but local IDs rarely need to be added.

heikkiorsila commented 2 years ago

I am considering to entirely remove support for creation/modification of local keys via covert enc, as that is now supported via covert id which seems more suited for the job. Adding recipients on encryption remains a useful convenience shortcut but local IDs rarely need to be added.

I think that's a good idea. It can be later added as an option for "covert enc" when and if we know better what is needed/practical.

covert-encryption / covert

Implement ID store in a file #81

Codecov Report