On Mar 21, 2:44 pm, Brad Ediger <[EMAIL PROTECTED]> wrote: > 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?
Not always. This is getting into very difficult crypto. Basically, depending on the cipher, there may be cases where you can change one part of the text without changing the other. WEP tried to do the trick you're talking about - for performance - and got nailed. There's no reason to open up a can of worms like this. If you want integrity, you need a good HMAC. > > 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 -~----------~----~----~----~------~----~------~--~---
