Keys subject to timing attacks

[daurnimator]

By storing private keys in lua strings < LUAI_MAXSHORTLEN (40) characters long, you're exposing them to a potential timing attack due to interning.

Please return keys inside of some type of userdata so that they don't get interned.

[daurnimator]

Oops, secret keys are 64 chars long (not 32) as I first read; so you're safe as long as no one uses a secret key as a table key.

Still though: I think you'd be better off if you used a userdata.

[philanc]

Thanks for the heads up. I probably don't understand enough about how string interning works. How could it be exploited for timing attack?

Secret keys are 64 bytes only for the ed25519 signature functions. I use 32-byte secret keys in many places here and in other libraries of mine. So I 'd better understand this issue!

[daurnimator]

Thanks for the heads up. I probably don't understand enough about how string interning works. How could it be exploited for timing attack?

When a short string is created in lua it undergoes "interning" -> meaning that lua will index the internal copy of it, so that if someone pushes the same string again it doesn't have to store it twice. When this occurs, it takes a slightly different amount of time to check if a string is already interned on not, depending on a common prefix (due to use of memcmp).
Therefore you can do a timing attack to see if a lua string has been seen by a given lua state before.
A similar attack exists when a longer string is used as a table key to check for collisions.

To see where this may hurt imagine you have a http server that uses lua to process requests and sign a response: e.g. each string in an json api request will be converted to a lua string, allowing a remote attacker to try and probe for your secret key.

[philanc]

Thanks for the explanation. I must give it a serious look.

[philanc]

I am still thinking about this one.
I really want to see keys as strings, at least at some point (for example being able to wrap / transport / store them from Lua programs) and I don't want to make the API too complex. And even adding some functions to convert keys from strings to userdata doesn't eliminate the timing attack possibility (when the key is a string before converting it to a userdata)...

[daurnimator]

I think you should return keys as userdata. Then have some method on that userdata :asstring() with some big fat warnings in the documentation.