[liberationtech] Trsst Encryption (was: About Telegram)

[Michael Powers]

Thanks, Steve, for your quick response.  

This is just the key exchange; not trying to sign or otherwise authenticate here.  The containing XML document is what gets signed via ECDSA as specified by XML-SIG.

In this part, we're trying to distribute the same randomly-generated 256-bit key to multiple recipients with known static public keys.

For each recipient we perform ECDH to get a shared secret that we SHA hash (combined with message unique id) into 512 bits.  We use those 512 bits to encrypt the 256-bit key plus the 256-bit hash that we use as a checksum of the key.  

Without the checksum, you'd have to download and start performing AES on the separate, larger AES-encrypted payload before you realized that you didn't successfully decrypt the key.

> What is that trying to do? It looks like you made up your own attempt
> at an authenticated cipher mode. That's generally a bad idea.
> 
> I don't buy the argument that you need to make up your own
> construction for speed. As is, in this Java code, I think the
> KeyAgreement and multiple MessageDigest object instantiations will
> dominate the cost.
> 
> I'd use AES-CBC and HMAC if you're trying to authenticate and encrypt.
> Keep it simple and well-understood.


We were indeed originally using AES and HMAC for the key exchange, but it looked to be overkill when the inputs were effectively random and the sizes were fixed.  

We have a 512-bit random-looking hash that both participants can calculate, and we have 512 random bits that need encrypting.  So it seemed like xor would be the simplest possible cipher as well as the most well known, fastest, and easiest to implement.  Not trying to invent anything new, but definitely proceeding with caution, hence this discussion.

An important consideration is that we need to also have a javascript implementation (not necessarily running in a browser) so simplicity and speed are decision factors, particularly in the use-case of sifting through a large number of unaddressed private messages looking for keys intended for the recipient.

> Some specific comments & questions:
> 1. You don't do anything to check that sharedKey is a fixed-length or
> use an unambiguous delimiter between entryId:
> https://github.com/TrsstProject/trsst/blob/master/src/main/java/com/trsst/Crypto.java#L72

We're just feeding those into SHA-512 so was not concerned about their size nor delimiting them.  Still, a good idea to assert the shared key is the expected length and not zero or null.

> 2. What cipher mode is being used here? It's not using ECB by default is it?
> https://github.com/TrsstProject/trsst/blob/master/src/main/java/com/trsst/Crypto.java#L176

You are correct: now specifying CBC explicitly, thank you.

> 3. Where is the authentication?
> https://github.com/TrsstProject/trsst/blob/master/src/main/java/com/trsst/Crypto.java#L180

I'm not sure about the authentication needed here -- can you clarify?  We're just using the AES key decrypted earlier to decrypt the payload.

> 4. This is padding with zero bytes. Is it expecting fixed-length messages?
> https://github.com/TrsstProject/trsst/blob/master/src/main/java/com/trsst/Crypto.java#L177

Definitely not fixed length, but had thought that null padding is ok with AES in this context.  Still, that class defaults to PKCS padding; I think based on that alone, I'll change this to use the default, thanks.    

> 5. This might be shady since it doesn't do any input validation on the token:
> https://github.com/TrsstProject/trsst/blob/master/src/main/java/com/trsst/Crypto.java#L246
> 6. Vulnerable to timing attack:
> https://github.com/TrsstProject/trsst/blob/master/src/main/java/com/trsst/Crypto.java#L263
> 7. Vulnerable to timing attack:
> https://github.com/TrsstProject/trsst/blob/master/src/main/java/com/trsst/Crypto.java#L331

5/6/7 refer to the implementation of hashcash anti-spam proof-of-work; this isn't part of the encryption routine.  Trsst servers generally accept any feed entries that are signed and have computed valid work stamps, so that validation only happens when they are posted to the server.

> 8. Why did you decide to use BouncyCastle?

Mainly because complete source was open and available, and we can distribute, and we can invoke it directly to bypass the default java runtime plugin provider architecture.  

> 9. You're throwing the wrong SecurityException. Probably want to catch
> GeneralSecurityException and not Exception:
> https://github.com/TrsstProject/trsst/blob/master/src/main/java/com/trsst/Crypto.java#L31

Indeed; fixed.

> I only spent a few minutes looking at this. It needs a lot of work.

And that few minutes was helpful and appreciated.  Happy to dig in further on- or off-list if you have the time and the inclination.

  - Michael

> -- 
> Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys at stanford.edu.