https://bugzilla.novell.com/show_bug.cgi?id=197493 suse-beta@cboltz.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | ------- Comment #3 from suse-beta@cboltz.de 2006-10-21 15:09 MST ------- (sorry for the long delay) OK, this is basically a problem with losetup; boot.crypto "only" suffers from that problem. Accepted - but this does not make the whole bug invalid ;-) (In reply to comment #2)

[...] You are not able to check the correct password length because for this you have to know the full password. Otherwise the password algorithm would be vulnerable

Well, I don't see the problem here. _losetup_ (not: boot.crypto) reads the password from stdin - therefore it knows it. What I expect is a different exit code for a) too short password entered (<= 7 chars) b) just pressed enter Reasons: a) is most probably a user error (mistyping the password) expected behaviour: ask user if he wants to enter the password again (as already done if mount fails because of wrong, but long enough password) b) is most probably intentional (skip mounting of the encrypted partition) expected behavious: continue booting since not mounting the encrypted partition was probably intentional (same behaviour as on timeout) The main fix is to implement different exitcodes for a) and b) in losetup. Once this is done, boot.crypto can be updated to the expected behaviour. BTW: I don't see the security implications here. Do you really think it makes a difference for an attacker if the error message is "no password given" or "too short password given"? (could also be the "mount failed" message in boot.crypto, which would IMHO reduce the risk because the attacker has seen the user typing some keys and now knows the password is short)

and the lenght should be longer than 8 charcters to get a secure password.

That's the difference between theory and practise - and a good 8 char password is still ways better than a non-encrypted partition ;-) Well, it won't stop a secret service, but it stops the other 99% which are thiefs etc. Oh, and I believe my data isn't interesting enough for secret service *g* -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.