I actually have done just that. It holds the whole cipe config in its nvram
and will only provide it when given the correct password.
On Friday 17 January 2003 05:20 pm, you wrote:
> If the only data encrypted is the key itself (a truley random sequence
> of bits), then there is no way to verify that the key has been cracked,
> other than to try it out by connecting to the cipe server. This is
> something we could potentially defend against on the cipe server end
> (max tries, or time-lags). If we encrypt the whole config file, then
> hackers would easily know when they had found the right password,
> because the keywords (ME, PEER, etc) show up in the decrypted file.
> We could encrypt the key in the config file directly (in the KEY field),
> and have ciped ask for the password when it starts (if given the
> apropriate flag). Then, ciped would decrypt the key in memory, and it
> would never apear on the disk in visible form.
> An external javaring also sounds good to me, but I'd like to use it in
> conjunction with a user provided password.
> -- Bill Cox
> Damion Wilson wrote:
> >They can, and it's not a bad idea. The javaring approach uses an embedded
> >microprocessor (running Java) which can run any code you like.
> >However, whenever you use a password, it requires a stored representation
> > of the password to compare against such as the crypt()'ed passwd field of
> > the /etc/passwd file. This representation provides an opportunity to
> > 'crack' the mechanism if it can be obtained. One way hash functions help
> > a lot but physically preventing keys from being obtained, hashed or not,
> > is a better approach. Encrypting the key using the password directly
> > requires that the password be a large and unique enough value to prevent
> > easy cracking. Using the password as an accessor to a larger decryption
> > key (PGP approach) still leaves the problem that the means to decrypt
> > and the decryption key are in the same place. It's almost like hiding the
> > house keys in the rain gutter when you go out. It's much better to take
> > the keys with you (randomising their location with respect to the house).
> >In short, removing the key from the computer gives you the best
> > opportunity to prevent both the facilitator (computer) and the accessor
> > (static key) from being obtained at the same time and, IMHO, that's
> > stronger security than reliance on passwords.
> >Bruce Schneier's writings explain these things far better than I ever
> > could.
> >On Friday 17 January 2003 02:41 pm, you wrote:
> >>>From: Damion Wilson
> >>>Instead of all that, why not put the key on a USB solid state disk ($20)
> >>>or use something like a JavaRing ? Why not put the whole CIPE config on
> >>>the thing ? Run ciped-cb from inittab and it'll keep dying until the key
> >>>becomes accessible.
> >>Do those have a mechanism for getting a password from the
> >>user? Someone stealing the laptop might get it with the
> >>device connected.
> >> Les Mikesell
> >> les,AT,futuresource,DOT,com
> >Message sent by the cipe-l,AT,inka,DOT,de mailing list.
> >Unsubscribe: mail majordomo,AT,inka,DOT,de, "unsubscribe cipe-l" in body
> >Other commands available with "help" in body to the same address.
> >CIPE info and list archive:
> > <URL:http://sites.inka.de/~bigred/devel/cipe.html>