[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNU Crypto] RFC: New keystore format
From: |
Casey Marshall |
Subject: |
Re: [GNU Crypto] RFC: New keystore format |
Date: |
Wed, 16 Jul 2003 14:57:28 -0700 |
User-agent: |
Mutt/1.4i |
-----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-----
- [GNU Crypto] RFC: New keystore format, Casey Marshall, 2003/07/12
- Re: [GNU Crypto] RFC: New keystore format, Raif S. Naffah, 2003/07/12
- Re: [GNU Crypto] RFC: New keystore format, Casey Marshall, 2003/07/12
- Re: [GNU Crypto] RFC: New keystore format, Raif S. Naffah, 2003/07/12
- Re: [GNU Crypto] RFC: New keystore format, Casey Marshall, 2003/07/13
- Re: [GNU Crypto] RFC: New keystore format, Raif S. Naffah, 2003/07/13
- Re: [GNU Crypto] RFC: New keystore format, Casey Marshall, 2003/07/14
- Re: [GNU Crypto] RFC: New keystore format, Raif S. Naffah, 2003/07/16
- Re: [GNU Crypto] RFC: New keystore format, Raif S. Naffah, 2003/07/16
- Re: [GNU Crypto] RFC: New keystore format,
Casey Marshall <=
- Re: [GNU Crypto] RFC: New keystore format, Raif S. Naffah, 2003/07/17
- Re: [GNU Crypto] RFC: New keystore format, Casey Marshall, 2003/07/17
- Re: [GNU Crypto] RFC: New keystore format, Raif S. Naffah, 2003/07/18
- Re: [GNU Crypto] RFC: New keystore format, Casey Marshall, 2003/07/18
- Re: [GNU Crypto] RFC: New keystore format, Raif S. Naffah, 2003/07/19