begin quoting Andrew Lentvorski as of Mon, Sep 01, 2008 at 04:42:25PM -0700: > SJS wrote: > >Fob encrypts hash with private key -- that's your digital signature -- > >and then you hash *that* to get the short string to send to the server. > >That's what you suggested, yes? > > > >The point of digital signatures is that I can't create 'em with the > >public key. > > Yeah, the more I think about this, the less convinced I am that it can > work. There really isn't any way to transfer a *part* of something in a > way that the other side can verify *and* not be in a position that you > can be impersonated by the server.
Seems that way, especially if you're trying to log in to multiple servers. > Okay, RSA keyfob display doesn't work without shared secret. > > So, if I assume that this thing *has* to be USB connected, I really like > the whole "impersonate a keyboard" thing. So, effectively you sign > something with your private key on the fob and transmit it across the > channel in full even if it's lots of bits. Yah. Dialup may be kind of tricky if we're sending too many bits, plus the more bits we send the bigger the "allowable time window" needs to be. > So, the question is what do you sign? Obviously, time should be part of > it, and with full access to the time the fob thinks it is buried in the > message, you can actually have tighter time granularity than an RSA fob. If you want multiple servers to use this, you REALLY want to make the tolerance very tight... I'm thinking of a 3-stage login process: prompt for the username, then prompt for the password, then prompt for the fobstring, and note when the fobstring starts and finishes arriving. If each server has a different password, then a compromised client box can't snag the input data to try to log in somewhere else. Of course, if you log in TWO servers from a compromised client box, the second login's fobstring can be used to log in to the first server. On the other hand, if we presume that level of sophistication in the attack, they could also presumably just hijack your login session and never let it go. If you're okay with that risk, then the above attack probably isn't worth worrying too much about. > However, if *time* is the only thing that changes, is that enough? My > gut feel is that there might be some attack, but maybe not. Most > encryption algorithms shuffle bits sufficiently well that even small > changes propagate to large differences. Well, you'd want to use a nonce (random data used once) as well as the time, so it wouldn't just be the time that would change. > So, the question is, is there a "known small plaintext" attack against > digital signatures. > > And is there any way to use AES for public-key digital signatures? The > question is asked since these chips have an AES engine on them. The problem with AES is that you need a shared secret again. Presumably you could generate a random AES key, encrypt the time, concatenate the key, encrypted time, and whatever random data it would take to pad it out to a reasonable size, and you'd have what would seem to be a lot of randomness... but at this point you might want to float the scheme by the sci.crypt folks for a sanity check. -- I really want a lock function on logins across servers. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
