On Mar 31, 2015, at 1:53 PM, Sam Hartman <hartmans@mit.edu> wrote:
So, I'd handle this by providing a utility to generate a strong random key and copy that between servers.
Which means that the systems have to communicate, and there's one more step to getting it to work.
Alan says something about a per-user ticket session key. You don't need that; you can have the same encryption key per-cluster, provided that you both encrypt and MAC and you don't do something horrible with how you encrypt things like reuse counters or nonces.
I have no idea how the session tickets are encrypted. That's the responsibility of the TLS people.
You're assuming that if I sign the same data twice the signature will be the same. That's true for RSA with a particular old type of padding. That is not generally true of public key signatures. I can't remember off the top of my head if it is a desirable security property that signing the same item multiple times generates distinct signatures or not.
Good point.
Hashing the signature definitely makes it better. The enginex design really scares me.
My updated recommendation to Arran is to simply do: key = hmac_sha256(server key, user identifier) Which should still be secure, easy to derive, and hard to crack.
Besides what I mentioned above , you could take the private key itself plus the input from the administrator and use that to key an hmac you use for key derivation. In practice that's probably secure, except that it doesn't work with smart cards/cryptographic security modules, and that using a private key other than as a private key will make people twitchy.
Yeah... that's life. Alan DeKok.