Re: [GNU Crypto] RFC: New keystore format

[Casey Marshall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Jul 16, 2003 at 11:26:47PM +1000, Raif S. Naffah wrote:

I went and LaTeXed my current notes:

   <http://metastatic.org/text/Documentation/gnu-keyring/>

> On Tue, 15 Jul 2003 09:32 am, Casey Marshall wrote:
> > On Sun, Jul 13, 2003 at 03:06:26PM +1000, Raif S. Naffah wrote:
> > > [...]
> >
> > Attached is my most recent revisions to the keyring format
> > description.
> 
> * 0. Data types.
> ...
> bigint: (the following is from draft-burdis-cat-sasl-sasl-08; MPI is 
> bigint --effectively a big uint)
> 
> "
>    MPIs are encoded using a scheme inspired by that used by OpenPGP -
>    [RFC-2440] (section 3.2) - for encoding such entities:
> 
>       The encoded form of an MPI SHALL consist of two pieces: a
>       two-octet scalar that represents the length of the entity, in
>       octets, followed by a sequence of octets that contain the actual
>       integer.
> 
>       These octets form a big-endian number; A big-endian number can be
>       encoded by prefixing it with the appropriate length.
> 
>       Examples: (all numbers are in hexadecimal)
> 
>          The sequence of octets [00 01 01] encodes an MPI with the value
>          1, while the sequence [00 02 01 FF] encodes an MPI with the
>          value of 511.
> 
>       Additional rule:
> 
>       *  The length field of an encoded MPI describes the octet count
>          starting from the MPI's first non-zero octet, containing the
>          most significant non-zero bit.  Thus, the encoding [00 02 01]
>          is not formed correctly; It should be [00 01 01].
> "
> 

The "RAW" codec for keys does this, but uses a 4-byte int for the
length. Do you think this should be changed, if only for uniformity of
data types?

> 2. Content-types.
> 
> * suggest we add another type for storing public keys; i.e. the public 
> part of the keypair that get generated by an IKeypPairGenerator 
> concrete implementation.
> 

Ok.

> 3.1. Password-encrypted.
> 
> * rfc-2898 states that the iteration count should be at least 1,000.  
> 10,000 may be an overkill;  how about 2,000?
> 

Sure, I was just making up numbers there. 1,000 is probably sufficient,
however.

> 5.3.
> 
> * "Since the keyrings contained... use the same password..."  there may 
> be a solution to remove this restriction.  i'll use a pseudo BNF 
> notation to describe my understanding of the structure so far; but i'll 
> also introduce a new type of entry which is a variation on the 
> GKR_TYPE_KEYRING_FILE.  also, i didnt include the mixed type because i 
> dont think it is needed; i.e.:
> 
> gkr_file =
>    keyring_params_file | 
>    public_keyring | 
>    secret_keyring | 
>    combo_keyring ;
> 
> keyring_params_file = MAGIC0 encrypted_envelope EOF ;
> 
> encrypted_envelope =
>    GKR_TYPE_PBE
>    pbe_prf_algorithm hLen dkLen
>    salt
>    iteration_count
>    cipher_algorithm
>    encrypted_data ;
> 

Should the encrypted envelopes contain a hash of the plaintext, to more
easily detect a failed decryption?

E.g.

encrypted_data = PBE_ENCRYPT(plaintext_and_hash) ;

plaintext_and_hash = plaintext HASH(plaintext) ;

And make HASH MD5, for example.

> * when decrypted, an encrypted_data field should yield a
> 
> keyring_file_params =
>    GKR_TYPE_KEYRING_FILE
>    uri
>    password
>    protection_type
>    protection_params ;
>    

I was hesitant to specify actual URIs since Classpath does not yet have
a functional URI class.

Having the password be kept encrypted along with the location of the
actual file is a better idea than forcing the same password for each
ring.

> protection_type = authenticated | encrypted_then_authenticated ;
> 
> protection_params = encryption_params? authentication_params ;
> 
> encryption_params =
>    pbe_prf_algorithm hLen dkLen salt iteration_count
>    cipher_algorithm mode_algorithm ;
> 
> authentication_params =
>    pbe_prf_algorithm hLen dkLen salt iteration_count
>    hmac_algorithm truncated_size ;
> 
> * the uri field above would point to a
> 
> keyring = public_keyring | secret_keyring ;
> 
> public_keyring = MAGIC1 compressed_data EOF ;
> secret_keyring = MAGIC2 compressed_data EOF ;
> 
> compressed_data =
>    GKR_TYPE_COMPRESSED
>    compression_algorithm
>    deflated_data ;
> 
> * after decompression, the deflated_data in a keyring should consist of 
> a protected (authenticated or encrypted-and-authenticated, depending on 
> the information in the relevant keyring_file_params record) sequence of 
> 1 or more entries (public_entry or secret_entry for a public_keyring 
> and secret_keyring respectively).
> 

Do you mean that the data should be compressed after encryption? I
thought that this was considered a bad idea (i.e. since enciphered data
looks random and is therefore very difficult to compress).

> * MAGIC0, MAGIC1, and MAGIC2 are 4-octets, 3 of which are common in the 
> 1st version of implementation; i.e.
> 
>    MAGIC0 = "GK" 0x01 0x00
>    MAGIC1 = "GK" 0x01 0x01
>    MAGIC2 = "GK" 0x01 0x02
> 

I'm not sure of the need of different magic values for different
keyrings.

> * it may be easier, without suffering a great loss of flexibility, to 
> fix lots of params in this specification; e.g.:
> 
>    pbe_prf_algorithm = PRFKDF2 based on HMAC-MD5;
>    hLen = 128 bits
>    dkLen = 128 bits
>    iteration_count = 2000
>    cipher_algorithm = AES with 128-bit key
>    mode_algorithm = OFB 8-bit
>    hmac_algorithm = HMAC-MD5
>    truncated_size = 128 bits
> 

I'd agree that the KDF and its parameters should be fixed, but probably
not the encryption/mac algorithms.

- -- 
Casey Marshall || address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/FcpBgAuWMgRGsWsRAm+XAKCLQLFMZaXY5Y0KOjsitUftQo79PwCeLmXK
SXxMXfu80hyq1c946eLJiwM=
=zxOk
-----END PGP SIGNATURE-----