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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
