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
