Comment 17 for bug 1175367
Revision history for this message
| Simo Sorce (simo-x) wrote Re: Memcache encryption middleware improperly implemented | #17 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Patch looks quite good, similar code to what I am implementing in oslo-incubator, with some minor differences.
I wonder if we want to make it possible to interchange it so that we can consolidate later ?
Some observations:
- I would use HKDF (exapand) from RFC 5869 for the key derivation, insted of just a plain HMAC, as that function has properties that are desirable (I have an implementation available if we want that I have implemented for message signing and can contribute it).
- On the ciphers/hash sides, I think SHA256 would be sufficient, also I would find AES 128 in CBC (as we do not need a stream cipher here) mode wiith random IV prefereable, given AES-128 is faster and also seem has (relatively) less weaknesses than AES-256
- Returning a CACHE_KEY as derivation from the secret is not necessary, you could as well just return the random IV as the kay as it is already exposed in the data anyway. There is no reason to use a piece of a HMAC output signature as a key that I can see, and I rather not publish any key material, derived or not.
None of these remarks are critical, I think all security properties that we want from this change are fullfilled with the current approach as well.