I thought about the integrity issue, but wouldn't it be sufficient to just prepend a known string to the data and verify it on thaw?
According to this page (http://www.cryptopp.com/benchmarks.html), SHA-1 and AES are about equal in speed (SHA-1 is marginally faster). But I would guess that in this situation even an order of magnitude difference probably wouldn't matter. (Warning: unsubstantiated claim!) I just noticed that the RDoc does make the nonconfidentiality assumption explicit, so this is probably less of an issue than I had originally thought. On Mar 21, 2007, at 1:30 PM, S. Robert James wrote: > > You'd still need to do the HMAC also, otherwise they could modify the > session. Even if they're modifying in the dark, they could cause > funny things to happen (eg imagine storing an id of a model which will > be deleted...) - witness what happened to WEP when they forgot this. > > I agree with you that this should be an option. But I think that even > symmetric encryption is much slower than a simple HMAC - so there > would be a performance hit. > > Brad Ediger wrote: >> (apologies if this goes through multiple times, it's been almost 24 >> hrs and I haven't seen my original post) >> >> First of all, I love the new cookie-based sessions. Thanks bitsweat. >> I just have an architectural question / suggestion. >> >> The CookieStore takes great care to provide integrity of session >> data, but we seem to have lost confidentiality in the process. The >> server-side storage methods had the implicit advantage of keeping the >> session data secret, but I don't know if this was intentional or just >> an unintended consequence. >> >> Would anyone see a disadvantage to symmetrically encrypting the >> cookie data rather than signing it with an HMAC? >> >> As far as I can think, this would retain all of the benefits of the >> current arrangement while obscuring the session data from a >> potentially untrusted client. (Not that untrusted-client is the >> normal way of things, but I tend to think fail-secure.) I don't think >> we need the full authenticity that an HMAC provides, since we're not >> trying to prove session authenticity to anyone other than the server >> that generated the session. >> >> Thanks! >> --be >> --Apple-Mail-37-430566699 >> Content-Type: text/html; charset=ISO-8859-1 >> Content-Transfer-Encoding: quoted-printable >> X-Google-AttachSize: 7340 >> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
