Join GitHub today
How-To Crypto #249
This issue is intended for discussing and formulating rules about how to correctly and securely use crypto. If you notice any suboptimal, insecure, or incorrect use of crypto:
Rules of Thumb for Signatures
Without the random oracle assumption (hashes):
You should be able to reconstruct your data-structure (type included) from the signed data.
With the random oracle assumption:
Given a random oracle (a cryptographic hashing algorithm) and a way to invert hashes (go from a hash back to the hashed data), you should be able to reconstruct your data-structure (type included) from the signed data.
Basically, if you can't parse the data you shove into the signing algorithm back into the datastructure you're trying to sign, you're probably doing something wrong.
Encryption Versus Authentication
Not all crypto is authenticated.
As a matter of fact, most (all?) stream ciphers are not authenticated by default because adding a MAC (message authentication code) per block (often 256bits or 32 bytes) is a lot of overhead, you generally want one per packet, not one per block.
How-To Authenticated Crypto
Encrypt then MAC. That is, encrypt the data, then MAC it. There's a really nice StackExchange answer explaining why.
One thing you need to remember is what's being authenticated. In this case, you're authenticating the ciphertext. That means that the ciphertext is was "signed" (MACed) by a party knowing the shared key. However, this does not mean that the ciphertext is, e.g., the next ciphertext in the stream, or that you haven't already seen the cipher text, or even that the cipher text came from this particular stream.