Yubico Forum

Re: assymetric keys

2009-09-18T22:18:44+01:00

you guys are over thinking it all you have to do is pass an encrypted string into the assykey have it decrypt it and then pass the value back to the server. you dont need the key sig because the key should only have one inside of it. no counters no timers just a way to do the decryption on the key and a way of getting the data into the key because you can also use the yubikey 2.0 design for getting the public key and the decrypted string out of the assykey.

Statistics: Posted by RtFM — Fri Sep 18, 2009 10:18 pm

Re: asymmetric keys

2009-08-11T22:27:48+01:00

Yubikey needs a central authority to prevent replay attacks with or without asymmetric encryption. The Yubikey encrypts a monotonically increasing counter and checks to make sure it's higher than any previously seen counters. Without the central authority the OTP you send to server A will be accepted by servers B, C, and D, no matter what kind of encryption is used.

Instead of having to worry about the integrity of a single authentication server you now have to worry about the N servers you log into, your computer, and the channel between them, your OTP is 20 times longer, and your key is more expensive.

If you want to take away the central party then you should go buy a smart card and then try to set up its reader and drivers on each system you use. Smart cards generate a public and private key internally, they can only reveal the public key, and they use their private key to sign a challenge received from the server.

Statistics: Posted by dholth — Tue Aug 11, 2009 10:27 pm

Re: assymetric keys

2009-04-22T03:50:22+01:00

I completely agree with mtiller.
What about the idea that Simon posted? The output is only 64 bytes, which can be encoded to 90 characters. This is only 2x of the current output.

What I don't quite understand is what would be the input to encrypt.

Code:

$ openssl genrsa -out rsa.pem
Generating RSA private key, 512 bit long modulus
..........++++++++++++
.++++++++++++
unable to write 'random state'
e is 65537 (0x10001)
$ echo 'this is a new hash' | openssl rsautl -encrypt -inkey rsa.pem | openssl enc -base64 -out hash-b64.out
$ wc -c hash-b64.out 
90 hash-b64.out
$ cat hash-b64.out 
IsXIx0rnI/qvsAAw5ZpyrgibEtlg3Mii0jq5Rf1nsRleCYBCBpDxIKU7OoPxBZ+n
Xxq0xnZNpU34Z5j01TEk4Q==

Statistics: Posted by hacho — Wed Apr 22, 2009 3:50 am

Re: assymetric keys

2008-07-08T15:20:15+01:00

I got a Yubikey because I loved the principle of a hardware token with open source infrastructure. But after contemplating it for a while I came to the conclusion that symmetric keys are a significant weakness (for reasons already pointed out in this thread). I just wanted to add my "2 cents" by saying that I think assymetric keys would help address what I see as the single biggest weakness of the Yubikey. I'd love to see a second generation device that uses public/private key pairs.

I'd like to see this discussion continue in the hope that somebody comes up with a clever idea for addressing some of the issues brought up so far (e.g. reducing the size of the encrypted blob, etc).

P.S. - Regarding clock drift, I was wonder if they clock couldn't be resyncronized? While it is true that the Yubikey should be able to operate without requiring any software to be installed but of course a user could optionally install software that resync'd the Yubikey (as a performance improvement, for example).

Statistics: Posted by mtiller — Tue Jul 08, 2008 3:20 pm

Re: assymetric keys

2008-06-02T08:45:29+01:00

If you look at just PKCS#1 RSA encrypt/sign, I believe the output will be as long as the modulus size. Thus, a 2048 bit key (which is the minimum you want to use to be safe) would be 256 bytes, or 512 modhex characters. Right now the output is 44 modhex characters and it is getting on the long side.

There is ECC though, which has significant shorter signatures.

/Simon

Code:

jas@mocca:~$ openssl genrsa -out rsa.pem
Generating RSA private key, 512 bit long modulus
.++++++++++++
.++++++++++++
e is 65537 (0x10001)
jas@mocca:~$ cat rsa.pem
-----BEGIN RSA PRIVATE KEY-----
MIIBPAIBAAJBAMJ8JDWnjv/qfvVwv5A6Sm3MyVp59L5RhW8JCOTBYy2yZKa1CeVE
jaJQotpoI4AZ7j+y9Z23bw/a7OFHo3G08MsCAwEAAQJBAI/aOQJCxOAAOBYdZmQs
6X6budelW2UmcVb2zNA/Rre17wwKHpB7RQkchf4Tyc0z2cCXffINi72fWpOw58jj
TVkCIQD4OGywdOzgQLRclVHRq9a685UwW5AYe9JS2N4LwXdytwIhAMiUkyW1InZj
MRrqFGHTWG43RqCa2hqFYMzB4DwOwU6NAiEA9Mvo3SmjRxJpDfmxJGAdOGjrlDJo
7MyIw23fpqZZYAcCIAhfq4T3eujWW0Z0X0V2PUrco+YwkMpqpw/lSCc5tnhBAiEA
3QMqy4qSjSgn4LQdxDWMpFj/kjSMwinD+i9BeEgv7iY=
-----END RSA PRIVATE KEY-----
jas@mocca:~$ echo 'hi'|openssl rsautl -encrypt -inkey rsa.pem  -out foo.out
jas@mocca:~$ ls -la foo.out 
-rw-r--r-- 1 jas jas 64 2008-06-02 09:43 foo.out
jas@mocca:~$ 

Statistics: Posted by Simon — Mon Jun 02, 2008 8:45 am

Re: assymetric keys

2008-05-30T08:02:10+01:00

The above scenario won't work by the way. The public key can't decrypt a hash of the encrypted data. It can only decrypt unaltered data.

How big would the output of a 10 character string be that has been encrypted with a long private key?

Statistics: Posted by metamind — Fri May 30, 2008 8:02 am

Re: assymetric keys

2008-05-29T23:24:09+01:00

regarding drift: you would store the "Local key time" with the user profile and the drift window would only be relative to the time of the last logon. So if the user hasn't logged on for a whole year the drift window would be "only" 106 minutes. If they log on each week the window would only be +-1 min.

Statistics: Posted by metamind — Thu May 29, 2008 11:24 pm

Re: assymetric keys

2008-05-29T23:00:26+01:00

It sounds like you are refering to something more like an asymmetric version of the SecureID, Vasco et.al. , is that right ?

- The variant part would then be a timer, with say one minute resolution
- The "blob" would be encrypted with RSA-2048 or so
- Then hash the stuff with SHA-1 or so, reducing it to 160 bits. A shorter hash would do as well of course...
- Convert it to 40 characters

That would be nice of course and it's definately worth keeping in mind.

Matching the OTPs would be considerably more complex, given that you would have to try over a fairly wide time window. A low-cost crystal varies at least some +/-100 ppm and given that we have about 526,000 minutes on a year that would be some +/- 53 minutes drift.

Maybe there is some other way to do it.

Regarding the Yubico server being a specific target for bad guys, that's a point. But there are so many services relying on symmetric keys, I beleive most people would agree there are ways to maintain and store these keys in a secure way. It is furthermore important to say that we won't be the single point of attack. Things will grow and lots of sites will maintain their own keys. It's going to be distributed, just like password databases.

Regards,

J

Statistics: Posted by Jakob — Thu May 29, 2008 11:00 pm

Re: assymetric keys

2008-05-29T21:40:25+01:00

I was thinking of making the otp an encrypted digest of the time (see my other forum thread) so the otp need not be all that long. only the "public" key could decrypt it ensuring that it was really "The Key" that encrypted the otp. This would mean that your customers could "publish" the public key to all the services that use the key for authentication and

i. there is no need for a central authorising party (so offline validation works)
ii. there is not the issue of the risk of the key repository getting compromised

You are going to become a very high value target for hackers / foreign government agencies with all those secrets you hold.

Statistics: Posted by metamind — Thu May 29, 2008 9:40 pm

Re: assymetric keys

2008-05-29T19:44:34+01:00

The question has been up a few times and conceptually it would have been nice.

There are two main problems as I see it

a) The hardware required to do an asymmetric encryption is a magnitude more complex than the one we have now. We would need a serious bignum engine on board and we beleive that would make the product significantly more expensive

b) Anything less than 2048 bits signatures would not impress. That OTP would be *very* long to send in via the keyboard port. Given that some 20 keystrokes per second can be safely sent, this will take a bit too long time to execute.

Bottom line: Not now, but we might find out some nice compromise as time gets by.

Regards,

Jakob E
Firmware and Hardware guy @ Yubico

Statistics: Posted by Jakob — Thu May 29, 2008 7:44 pm

assymetric keys

2008-05-29T09:52:24+01:00

Hi,

Do you have any plans to produce a yubikey that uses assymetric keys to encrypt the token?

Statistics: Posted by metamind — Thu May 29, 2008 9:52 am