Re: SVND -k and -K ERRATUM
I did notice something along those lines. I have some special characters in my encryption keys. They work fine when entered in the main OpenBSD shell, and work fine when run out of an XTerm. They don't work if I try to use them from a KDE Konsole. Woodchuck <[EMAIL PROTECTED]> wrote: A problem here is that evidently getpass() is reading the terminal in "cooked" mode. Unfortunately, the characters that are consumed in "cooking" can vary depending on user settings (man stty). This can lead to surprises if you get too loose about what control (and high ascii, maybe) characters you use in input to getpass(). An svnd device you mount one day from an xterm might be mysteriously unreadable when you mount it from a text console during a single-user session. The source for getpass() is in /usr/src/lib/libc/gen/readpassphrase.c You might wish to analyze that routine with respect to what state of "cooking" it places /dev/tty or STDIN into. You're one step away from "hexadecimal armor" or whatever the PGP folks call it. ;) Considerations like the preceding paragraph as well as internationalization issues are why PGP keeps its various things as ascii-hex characters. They also simplify storage on paper in the bank deposit box. Dave -- "I believe that banking institutions are more dangerous to our liberties than standing armies." -- T. Jefferson - Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games.
Re: SVND -k and -K ERRATUM
On Tue, 30 Jan 2007, Don Smith wrote: > I looked at the source code. In /src/sys/dev/vnd.c, it > has the lines: > > blf_ecb_encrypt(vnd->sc_keyctx, iv, sizeof(iv)); > if (encrypt) > blf_cbc_encrypt(vnd->sc_keyctx, iv, addr, bsize); > > This looks like it encrypts the key using the iv of > all zeroes. True, it doesn't add any salt using -k, > but it doesn't look like the user's key is the key > that is actually used. I am curious what happens if > the user enters a key longer than 448 bits. If the > user enters a 456 bit key, would the extra 8 bits just > be dropped from the key? You're looking in the wrong place for salt. The user's entered key and salt in the -K case are hashed together in vndconfig (userland), generating the key that is the actual one used in the kernel routines (blf*). The salt doesn't survive vndconfig as a separate entity. Compare the "case 'k':" and "case 'K':" code in vndconfig.c This is an incomplete comment; the fate of the user entered key should be traced out to its bitter end. This will involve the initial setup of blf when the svnd is mounted. > I was playing around on my system, and it seems that > you can enter around 248 or so of the 256 possible > characters. Exceptions include CTRl+C,CTRL+D, and a > few others. A problem here is that evidently getpass() is reading the terminal in "cooked" mode. Unfortunately, the characters that are consumed in "cooking" can vary depending on user settings (man stty). This can lead to surprises if you get too loose about what control (and high ascii, maybe) characters you use in input to getpass(). An svnd device you mount one day from an xterm might be mysteriously unreadable when you mount it from a text console during a single-user session. The source for getpass() is in /usr/src/lib/libc/gen/readpassphrase.c You might wish to analyze that routine with respect to what state of "cooking" it places /dev/tty or STDIN into. You're one step away from "hexadecimal armor" or whatever the PGP folks call it. ;) Considerations like the preceding paragraph as well as internationalization issues are why PGP keeps its various things as ascii-hex characters. They also simplify storage on paper in the bank deposit box. Dave -- "I believe that banking institutions are more dangerous to our liberties than standing armies." -- T. Jefferson
Re: SVND -k and -K ERRATUM
On 1/30/07, Don Smith <[EMAIL PROTECTED]> wrote: I looked at the source code. In /src/sys/dev/vnd.c, it has the lines: blf_ecb_encrypt(vnd->sc_keyctx, iv, sizeof(iv)); if (encrypt) blf_cbc_encrypt(vnd->sc_keyctx, iv, addr, bsize); This looks like it encrypts the key using the iv of all zeroes. True, it doesn't add any salt using -k, the iv is the block number. but it doesn't look like the user's key is the key that is actually used. I am curious what happens if it is turned into a key suitable for blowfish to use. the user enters a key longer than 448 bits. If the user enters a 456 bit key, would the extra 8 bits just be dropped from the key? the extra is ignored.
Re: SVND -k and -K ERRATUM
I looked at the source code. In /src/sys/dev/vnd.c, it has the lines: blf_ecb_encrypt(vnd->sc_keyctx, iv, sizeof(iv)); if (encrypt) blf_cbc_encrypt(vnd->sc_keyctx, iv, addr, bsize); This looks like it encrypts the key using the iv of all zeroes. True, it doesn't add any salt using -k, but it doesn't look like the user's key is the key that is actually used. I am curious what happens if the user enters a key longer than 448 bits. If the user enters a 456 bit key, would the extra 8 bits just be dropped from the key? I was playing around on my system, and it seems that you can enter around 248 or so of the 256 possible characters. Exceptions include CTRl+C,CTRL+D, and a few others. Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html
Re: SVND -k and -K ERRATUM
On Sat, 27 Jan 2007, Woodchuck wrote: > Disclaimer: I am not a cryptanalyst. Maybe that's all FUD and blown > smoke. > > If I recall the source code correctly, using -k, you > are already using salt -- of zero. Checked the source code, I was wrong. In the -k case, the passphrase is passed without processing to the vnd routines. In the -K case it is passed to pkcs5_pbkdf2 for massage and hashing. Dave the Erring
