Stupid phone The reason for that cipher over xor was to avoid non printable characters.
Any other solution is fine. Xoring the lower 4 bits reduced the entropy too much in my view. On Aug 5, 2014 6:11 AM, "Donald Stufft" <[email protected]> wrote: > On August 3, 2014 at 9:48:53 PM, Adam Brenecki ([email protected]) > wrote: > > The patch I've written implements this mitigation, with one difference: > > instead of using xor, it uses a Vigenère cipher (as suggested by > FunkyBob), > > as xor was creating non-printable characters which caused problems. I > think > > this should be OK as Vigenère is commonly used for one-time pads and does > > more or less the same thing to characters that xor does to bits. > > > > This is pretty much what django-debreach does, except that *it* uses AES > > instead of xor (i.e. the output is K + AES(K, S).). However, this adds > > processing load to every request and a dependency on PyCrypto, and as far > > as I can tell this doesn't actually add any benefit over xor/Vigenère. > > > > So, in summary, I think I'm doing nearly exactly what the paper says, > and I > > think it effectively makes the attack practically impossible, but I'd > love > > to hear from someone who has a better idea than I as to if I'm actually > > correct on all of this. > > Thoughts: > > -1 on implementing our own Vigenère cipher. > > If I understand the patch correctly it doesn't use the pad as a nonce > exactly, > it will happily accept the same pad + CSRF token multiple times over and > over. > Anything that treats the CSRF token as an opaque sequence of characters > (which > is essentially what it is prior to this patch) should be backwards > compatible > if my understanding is correct. Further more it looks like the original > unpadded CSRF token is still in the cookie so anything that pulls it's > tokens > out of the cookie directly should be completely unaffected. > > Is my understanding correct? If so then the only thing I can imagine this > breaking is something that expected a certain length for the CSRF token and > afaik the length of the token is not within our backwards compatibility > promises. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/etPan.53dfe906.327b23c6.1280a%40Thor.local > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAG_XiSDDwnEScQ26DJduiYDTyYjCK5B8R0mBvHOr4HQGMBC7%2BQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
