[Top][All Lists]
[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-----
- [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 <=
- Re: [GNU Crypto] RFC: New keystore format, Raif S. Naffah, 2003/07/16
- Re: [GNU Crypto] RFC: New keystore format, Casey Marshall, 2003/07/16
- 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