Re: [GNU Crypto] RFC: New keystore format

[Raif S. Naffah]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

On Thu, 17 Jul 2003 07:57 am, Casey Marshall wrote:
> 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:
> > ...
> > bigint: ...
> 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?

1 format is enough. RAW codec it is.


> > 5.3.
> >
> > ...
> > 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.

i dont think they need to.  if a decryption fails, the plaintext 
obtained is unlikely to still be well formed according to the syntax 
rules we're discussing.


> > * 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.

ok.  a workaround that would still keep this version 1 format valid when 
such an implementation becomes available would be to precede the uri 
field with a 1-byte type.  allow 2 values (a) one to mean "file" 
protocol, and the other to mean "implicit" specification of the 
protocol in the next field string, and (b) when "file" protocol, the 
uri field would contain the path to the keyring, and when "implicit" 
the full string of the uri would be considered.


> > ...
> > * 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).

you're right.  we should reverse the order.


> > * MAGIC0, MAGIC1, and MAGIC2 are 4-octets...
>
> I'm not sure of the need of different magic values for different
> keyrings.

the keyring files contain different types of data; the distinct MAGIC 
helps (a) instantiate the appropriate scanner, and (b) decide which 
types are illegal if/when they are included.


> > * 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.

why?


cheers;
rsn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Que du magnifique

iD8DBQE/FvpN+e1AKnsTRiERA9SLAJ0dtkkp3Ih7xgaPHT2heMZ1ft2hVwCeLeIz
wSdk8IMHJVNbuFi7OdBrVVo=
=C58M
-----END PGP SIGNATURE-----