[cryptography] [ramble] [tldr] Layered security where encryption is used?

Ben Lincoln F70C92E3 at beneaththewaves.net
Sun Jul 21 17:40:46 EDT 2013


Maybe I am misunderstanding (and I apologize if so), but I don't think 
authenticated encryption will address the main problem I'm trying to 
solve. Preventing tampering is important (and I think some of what I 
suggested has the effect of making it at least a little harder to tamper 
with the data), but it's by far the secondary concern.

The main problem is trying to reduce the likelihood that the system will 
decrypt data of a different type than it expects, and then display that 
decrypted data to the user (IE allowing them to decrypt arbitrary data 
without themselves knowing the encryption key). Unless I'm missing 
something (and that is certainly possible), then the data will always 
pass an authentication check, because it's always generated by the 
system in question - it just isn't intended to be decrypted and 
displayed by that specific part of the application.

Using separate keys for separate types of data will go a long way there, 
but I am trying to come up with a completely separate mechanism that 
operates using a different method, but which will also help prevent the 
unwanted outcome even if someone makes a mistake and uses the same key 
for sensitive and non-sensitive data. In other words, the mechanism I'm 
trying to come up with can't involve using different keys, because I 
already have a mechanism based on that principle.

For comparison, think of physical safety features in industrial 
equipment. The B Reactor at Hanford had a gravity-based system that 
would automatically insert the control rods in the event of a power 
failure, but there was also a system that could drop a bunch of 
neutron-moderating fluid and/or ball bearings into the reactor in case 
the first system jammed or was inoperable for other reasons. Because 
they were based on different designs, it's unlikely that they would both 
fail in an emergency, unless the emergency involved loss of gravity locally.

Alternately, in software development, we strongly encourage developers 
to check their code for e.g. buffer overflow vulnerabilities, but we 
also strongly encourage them to perform input validation so that e.g. if 
they are working on one piece of code and someone less-capable is 
working on another, and that second person introduces a buffer overflow 
issue, malicious input never makes it to the second system because the 
input validation of the first system catches it (or passes the first 
mechanism but is stopped by the second, if the skill of the two 
developers is reversed).

Using HMAC or AES-GCM would improve the overall security of the system, 
but I don't think either of them address the core issue I have. That 
core issue seems like it's outside the scope of the encryption, but the 
reason I'm asking here is because I don't want to compromise the 
encryption in some way as a result.

On 2013-07-21 13:55, CodesInChaos wrote:
> 1) If you want to prevent tampering, use a MAC, not a cipher. My
> recommendation is HMAC-SHA-2. Be sure to use a constant time equality
> check while verifying the MAC.
> 2) If you want to encrypt something symmetrically, use authenticated
> encryption. Either with a specialized mode, like AES-GCM or with an
> encrypt-then-mac scheme. Use a proper IV and don't forget to include it
> in the MAC.
> 3) Use separate keys for different uses. This avoids interactions
> between different parts of the software.
>      If you want only a single key in the config, then don't use it
> directly. Instead derive a distinct key for each usage with a key
> derivation function.
>      My recommendation for a KDF is HKDF with HMAC-SHA-2 as building block.
>


More information about the cryptography mailing list