gnu-crypto-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNU Crypto] RFC: New keystore format


From: Raif S. Naffah
Subject: Re: [GNU Crypto] RFC: New keystore format
Date: Wed, 16 Jul 2003 23:26:47 +1000
User-agent: KMail/1.5.1

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

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].
"

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.

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?


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 ;

* when decrypted, an encrypted_data field should yield a

keyring_file_params =
   GKR_TYPE_KEYRING_FILE
   uri
   password
   protection_type
   protection_params ;
   
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).

* 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

* 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


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

iD8DBQE/FVKh+e1AKnsTRiERA1xuAKCnv3/SJ8Tne4wF4grZFV4HldvV1ACeOWO6
/zo0dvYt9RSP7hq3F3xouIM=
=j5fw
-----END PGP SIGNATURE-----





reply via email to

[Prev in Thread] Current Thread [Next in Thread]