On Friday 17 November 2006 4:58 am, Anderson Briglia wrote: > - Password caching: when inserting a locked card, the driver should try > to unlock it with the currently stored password (if any), and if it > fails, revoke the key containing it and fallback to the normal "no > password present" situation.
Is there some reason why the key isn't associated with the MMC/SD card identifier(s)? It should be practical to swap several cards in/out without the kernel _needing_ to discard their keys. What you're saying is that you'll cache only one key at a time, and that it won't have anything associating it with a particular card. That's not at all how the key retention service is designed to work... > - Some cards have an incorrect behaviour (hardware bug?) regarding > password acceptance: if an affected card has password <pwd>, it > accepts <pwd><xxx> as the correct password too, where <xxx> is any > sequence of characters, of any length. In other words, on these cards > only the first <password length> bytes need to match the correct > password. I thought the MMC vendors expected to see the actual user-typed password get SHA1-hashed into a value which would take up the whole buffer? In general that's a good idea, since it promotes use of longer passphrases (more information) over short ones (easy2crack). Plus, such hashing would prevent this issue ... if vendor tests are done with hashed passphrases, that would explain why this class of hardware issue got past design validation. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
