information leak to server operator

[burntout]

notes should not reveal any internal intormation while at rest on the server. Currently they show at least

1. Whether a passphrase has been set
2. Whether a duress key has been set
3. The size of the note ( modulo AES block size )

I've created a new branch that resolves issue 1.

If a note has a passphrase then the HMAC tag can not be calculated from the URL so we do not need a '.key' file. This simplifies fetch_url also.

This would be compatible but I've removed zlib. I'm not happy with the zlib try catch block on decryption. If the HMAC tag matches we've got what we encrypted and should return data NOT do a second check ?

To solve 2. I'm not sure. Any ideas

To solve 3. I'd pad all notes to 100KB in size. If notes that have more data than they would be split and chained together to reconstruct.

[atoponce]

For points 1 & 2, I think this is a good idea. I'm glad you solved the first point. For the second, we could append the duress key to the end of the text. This opens up the possibility that the end of the text could match the durress key exactly, but because the server is generating a random 22-character string, seems like this would be a remote possibility.

For the third point, by removing compression, you are opening that up. By keeping ZLIB compression in place, all that is known is "the plaintext is bigger", but it's not known by how much, although good estimates would put it at 10x the compressed ciphertext. I prefer keeping ZLIB compression. It's generally considered best practice before encryption, and increases the overall entropy of the system.

[atoponce]

The try block for zlib decompression isn't needed. We can take that out, seeing as though all the bits were verified with the hmac. So, if the hmac verifies, decompress the note.

I'm still thinking how to solve the duress key storage.

[burntout]

I've added zlib back.

I'm not clear what you propose for securely preventing the server operator to know of a duress key's existence.

I would propose creating something along the lines of having an inner and outer part to a note.

The inner part would be what we store at the moment inner = hmac(hmac_key, enc(aes_key,plaintext )) || enc(aes_key,plaintext )

the outer would be the inner concatenated with a duress key, AEAD encrypted with a random key ( generated from the url as we do now )

outer = hmac( outer_hmac_key, enc(outer_aes_key, dkey || inner )) || enc(outer_aes_key, dkey || inner)

which we write to disk.

The outer_hmac_key and outer_aes_key are generated from the url ( as we do know ).

The inner keys are generated from the user passphrase ( or from the url if no passphrase is given )

• If we can decrypt inner succesfully (i.e. the hmac tag matches ) then we know to render it.
• If we cannot we ask for a passphrase
• we attempt to decrypt again with the passphrase to generate the inner keys
• If we cannot decrypt it we check that the passphrase given matches the dkey, and we know to return duress text and destroy data.
• otherwise we ask for the passphrase again and repeat.

[atoponce]

Why not just create a "duress_key" salt, like we do with the rest of the salts and keys? If a passphrase is given, we can automatically return a duress key on /post (no radio button on index), and we can automatically calculate it as needed, and don't need to store it on disk.

[burntout]

I'm not sure I get that yet. Can you explain in more detail when you get chance ?

[atoponce]

Pushed. The duress key is dynamically built from the URL (nonce), if the user supplies a passphrase. It's never stored to disk.

[burntout]

I'd wanted to allow the user to set a duress key that was human memorable, but this certainly resolves the problem as described.