Introduction
What Doco is there?
More information on SDP1 is found in the SDP1 defining document and the
Status
The password shared secret method is a WIP.
How Does Password Secret Sharing Work?
KDFs
A program takes a password and generates all the necessary keys directly from this using a Key Derivation Function (KDF). This algorithm is a simple key expansion using the fixed keynames, each concatonated with the password and hashed. The method is suitable for starting up two pairs of cooperating servers where an administrator is accessing them both via ssh(1).Key Derivation Functions take a password and spit out keys. There are lots of references on this, so this will only be a brief discussion here.
In essence, KDFs are hash functions that take the secret passphrase, concatonate that with some extra stuff like a salt and a key name, and then cycle through a hash function. The result is then turned into a key.
Which one is used?
This one seems closest to PBKDF2 ("password-based Key Derivation Function") as documented in RFC2898.
The Spec
Context
In order to generate the context, use the F (below) many times over the key set needed.
mode = "Zero" # 4 bytes long: " Two" / " One"
password = "My Secret Key" # as long as is liked
for keyname in {all key names} # 8 bytes long: "AES128SK" ...
do
text = salt || key || mode # "SDP1SaltAES128SKZero"
K = F(password, text)
done
For each key needed the first order bytes are taken. That is, for the AES 128 bit key, the first 128 bits are taken from the 160 bits of output of F and the remainder are junked.
F
The function F(password, text) is the following:
U = text
f = 0
for 1000
do
U = HMAC-SHA1( password, U )
f = f || U;
done
The HMAC is passed over the text (for example "SDP1SaltConInitV One") and is keyed with the passphrase. This produces U the intermediate text. The text is 20 bytes long, as is each succeeding U. The U is fed into the HMAC again keyed with the passphrase, and this cycle is done 1000 times.
The resulting key is the XOR of all the intermediate texts (U 1 through 1000, not including the original text).
This should be the same function as with PBKDF2 with the exception that the original text is calculated differently.
Modes
There are three modes, numbered 0,1,2. Mode Zero (0) is default. In mode Zero, the keys generated are totally symmetrical, so encrypt and decrypt will use the same key, CIV and MAC secret.
In modes 1,2 the keys generated are for two party communication, parties 1,2 respectively of the key sharing agreement. The two modes employ the same sets of keys but in different orderings.
In general mode zero should be sufficient. Modes 1,2 will take twice as long to calculate, the user of the program has to specify which ordering is required, and it will not be suitable for multiparty comms (where there are more than 2 parties).
In the KDF, the modes are written as their ascii words with a leading space to make up 4 bytes: "Zero", " One", and " Two".
Key Names
The key names are ascii strings of 8 bytes each: "AES128SK", "ConInitV", "HMAC Key", "DG Token".
Salt
The standard salt is the 8 ascii octets "SDP1Salt".
User programs may permit the selection of alternate salts, but as this complicates the password metaphor for users, this should not be "encouraged" in normal practice. Rather it can be reserved for distributions that are placed within a clear boundary, such as departments that never wish to talk outside.
Design Notes
KDF
A minor issue then becomes which KDF to use. Should we use SHA1 or just use the HMAC as it is needed? It seems that every available implementation would have SHA1 available by definition anyway as we use HMAC-SHA1, but RFC2898 recommends HMAC-SHA-1 over straight SHA1 anyway. So HMAC-SHA-1 it is, as that is slightly less explanation for the implementor.
This makes the KDF HMAC-SHA-1 with the key as the passphrase and the salt as the text.
Text
As each intermediate U is the product of the HMAC-SHA-1 function and that produces 20 bytes or 160 bits, the initial text is also set at that length for ease of implementation.
Salt
RFC2898 recommends a salt of 8 octets long.
Password Length
As HMAC-SHA-1 bounds the password effective length to 160 bits, consider that as an upper limit to the search space. However the algorithm sorts out anything longer.
Security
Security of passphrases is always an issue, and dictionary attacks and common short passwords are well discussed elsewhere.
Trying Passwords
It is assumed that an oracle exists in that SDP1 packets can be created and sent, and a reasonable reply seen if the packet is acceptable. An attacker could try passwords to generate keys, generate a packet and then send it to the oracle. The packet would have to have a valid HMAC, and decrypt sensibly to both key and CIV, and semantically generate a reasonable reply. This is a tall order.
Token Oracle
As the tokens are in the clear, this indicates that the attacker has a partial oracle available to him. For this reason the tokens generated by this method are kept short, only 1 byte long. This effectively reduces his attack space to 152 bits of length for a random password but this may be very useful if the passphrase is known to come from a given dictionary set.
This weakness is perhaps best addressed by requiring the user to generate their own cleartext token names.
Miscellaneous
Other Refs
Lynn suggests DUKPT from x949. Adam suggests the KDF2 function in IEEE1363a:
Random Links (WIP)
In the fullness of time, these should be incorporated as full references, or disappear.