> > http://www.untruth.org/~josh/security/radius/radius-auth.html > > > I'm not familiar with this protocol at all, but in briefly skimming > this paper and the description of the cipher, it seems like the > there's opportunity for padding oracle attacks, provided the server > somehow indicates (through timing or otherwise) whether the 0 padding > is valid.
Hmm, sorry, no this is much more like CFB mode than CBC, and the vast majority of passwords are going to fit into one block. So, I guess the question is: If a users password is "password", and the decryption routine receives a replayed and modified ciphertext (with, say, a bit flipped in the last byte of the ciphertext) that decrypts to: password\x00\x00\x00\x00\x00\x00\x00\x01 How will it handle that? Will it try to do a strcmp and ignore the corrupt final byte? Will it hash the entire block and compare with a stored hash, or will it treat the block as string efore feeding it to a hash routine, thereby ignoring the final \x01? If it ever treats the block as a C-style string during validation, then it would be trivial to determine the length of the user's password. In diabolicly bad implementations, you could even argue for full decryption of the password through timing side channels, but that's probably tough to pull off in practice. tim _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
