Big fat disclaimer: I'm also not a crypto expert. Don't trust this without verification from somebody who is.
To add to what CodesInChaos said, just in case you can't use different keys for different types of data then just before encrypting it you could add a HMAC of the plaintext with a tag (should be pregenerated random strings) that specifies the permissions as the HMAC key. So when the server decrypts it, it checks if it's HMAC'ed with the tag for "top secret" or for "can be shared with the user". If you don't also add the "permissions tag" in plaintext form, you'll get a small performance hit here if there's a lot of different tags to test, and possibly it would also introduce an "oracle attack" that reveals what type of tag it has through timing. This also helps you against that known-plaintext attack against the first cipher block which you said you fear (although simply using a proper IV works equally well for that part). And that would be in ADDITION to doing HMAC on the ciphertext or using an authenticated encryption mode. > I can definitely see an argument that this is a bunch of over-engineering It's not. You should never even leave wiggle-room for attackers. At least for as long as it doesn't cost you more than a successful attack would. Also, no you can't just simplify crypto guidelines that way. Just can't be done. There's too many potential sidechannels and flaws and misconceptions that could screw it up. If it could be simplified that way then it would have been already, and you would already have heard of it. 2013/7/21 CodesInChaos <codesinch...@gmail.com> > 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. > > > _______________________________________________ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > >
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
