[cryptography] [ramble] [tldr] Layered security where encryption is used?
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