Re: [9front] dp9ik specification

Re: [9front] dp9ik specification

[sl]

> i wrote down a specification for the new dp9ik and authsrv protocol:
> 
> http://felloff.net/usr/cinap_lenrek/newticket.txt
> 
> any feedback welcome. spelling errors, unclarities... missing stuff...
> there might be even errors in the design as i'm no a cryotpgrapher,
> but it might never get pointed out when nobody understand the spec :)

Some minor English corrections:

newticket.txt:1,33 - newticket.txt.new:1,33
  abstract:
  
  the goal of this crypto scheme is to replace DES in the plan9 authentication
- and to augment the authentication server with a authenticated key exchange
- to prevent offline dictionary attacks on the users secret key. we propose a
+ and to augment the authentication server with an authenticated key exchange
+ to prevent offline dictionary attacks on the user's secret key. we propose a
  new protocol named dp9ik as an alternative to p9sk1 that uses the new authsrv
  capabilities and can optionally be negotiated in p9any.
  
  problem:
  
- the users secret key is derived from a low entropy password that is prone
+ the user's secret key is derived from a low entropy password that is prone
  to dictionary attacks. with the old authserver protocol, it is easy for an
  attacker to just try to decrypt tickets with a dictionary of DES keys.
  the dictionary can be precomputed once and will then work forever for
  all users as the key is only dependent on the password.
  the ticket contains known plaintext that makes it is easy to check if decryption
- succeeded or not. also due to the small 56-bit key size of DES it is possible
+ succeeded or not. also, due to the small 56-bit key size of DES it is possible
  to bruteforce the key with modest computing resources.
  
  to address the small key size of DES, we replace the DES cipher with
  128-bit AES, introducing a bigger 128-bit key called the aeskey that is derived
- using a expensive pbkdf2 key derivation function. Ticket encryption is also
+ using an expensive pbkdf2 key derivation function. Ticket encryption is also
  changed to use 128-bit AES-CBC with hmac_sha2_256 for message authentication.
  
- we add a authenticated (elliptic curve diffie hellman) key exchange (AuthPAK)
- at the beginning of a authsrv session to establish temporary keys (pakkey)
- that are used to encrypt/decrypt the tickets instead of using the users
+ we add an authenticated (elliptic curve diffie hellman) key exchange (AuthPAK)
+ at the beginning of an authsrv session to establish temporary keys (pakkey)
+ that are used to encrypt/decrypt the tickets instead of using the user's
  secret keys directly. the public keys are derived in a way that to complete
- the exchange requires the knowledge of the users secret. this forces the
- attacker to know the users key in advance when requesting a ticket limiting
+ the exchange requires the knowledge of the user's secret. this forces the
+ attacker to know the user's key in advance when requesting a ticket, limiting
  the attacker to only one guess per ticket request.
  
  aeskey[16]:
newticket.txt:97,109 - newticket.txt.new:97,109
  as the salt to the key derivation function so that any manipulation on
  the public keys in the message exchange causes a pakkey mismatch.
  
- client and server both etablish new pakkeys with the authentication
+ client and server both establish new pakkeys with the authentication
  server each time a new ticket is requested.
  
  dp9ik and authsrv protocol:
  
  dp9ik is is mostly the same as p9sk1, but at the beginning there is
- the new AuthPAK (type 19) message send to the authentication server
+ the new AuthPAK (type 19) message sent to the authentication server
  to exchange curve25519 public keys YAs/YBs and YAc/YBc and derive the
  pakkeys. Ks and Kc are replaced by the pakkeys Zs and Zc. when using
  AuthPAK, aes encrypted tickets are used as described later.


sl