Mailing List Archive

On Sun Apr 21 2002; 13:20, Rüdiger Sonderfeld wrote:

> I don't understand how to use the gcry_cipher_setkey(h,k,l) function.
> I now h is the handle but what is k and l? I will use it for the
> AES256 encryption.

I guess you didn't watch the test files...from tests/basic.c

if (gcry_cipher_setkey (hd, key, keylen)) {
fail ("algo %d, mode %d, gcry_cipher_setkey failed: %s\n",
algo, mode, gcry_strerror (-1) );
gcry_cipher_close (hd);
return;
}


Timo

On Sun, 21 Apr 2002 13:20:23 +0200, Rüdiger Sonderfeld said:

> I don't understand how to use the gcry_cipher_setkey(h,k,l) function. I now h
> is the handle but what is k and l? I will use it for the AES256 encryption.

A pointer to the key and the length of that key. For AES256 L should
be 32.

Werner
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Am Sonntag, 21. April 2002 14:33 schrieb Timo Schulz:
> On Sun Apr 21 2002; 14:31, kingruedi wrote:
> > > I guess you didn't watch the test files...from tests/basic.c
> >
> > I have no tests directory :( I only have src/testapi.c
> >
> > I'm using the libgcrypt-1.1.3
>
> Oh sorry, when people don't mention a version they use
> I automatically think it's the newest version...

I had get the link at the gnu site.
http://www.gnu.org/directory/libgcrypt.html and they write that 1.1.3 is the
newest.

Am Sonntag, 21. April 2002 13:35 schrieb Werner Koch:
> On Sun, 21 Apr 2002 13:20:23 +0200, Rüdiger Sonderfeld said:
> > I don't understand how to use the gcry_cipher_setkey(h,k,l) function. I
> > now h is the handle but what is k and l? I will use it for the AES256
> > encryption.
>
> A pointer to the key and the length of that key. For AES256 L should
> be 32.

That is good! so I can use MD5 sums as key

On Sun, 21 Apr 2002 15:48:57 +0200, kingruedi said:

> That is good! so I can use MD5 sums as key

No you can't. An MD5 digest is just 16 bytes. The usual way to
create a key is by using a ranodm key and having some key agreement
mechanism. AES256 doesn't buy you anything when using a weak keay
(i.e. which can be easy attacked with an dictionary attack).

Am Sonntag, 21. April 2002 21:43 schrieb Werner Koch:
> On Sun, 21 Apr 2002 15:48:57 +0200, kingruedi said:
> > That is good! so I can use MD5 sums as key
>
> No you can't. An MD5 digest is just 16 bytes. The usual way to
> create a key is by using a ranodm key and having some key agreement
> mechanism. AES256 doesn't buy you anything when using a weak keay
> (i.e. which can be easy attacked with an dictionary attack).

That's bad :( I wanted to use the md5 sum of the user password as AES256 key.

I don't now what you mean with the random key's. If I create a random key the
user have to remember the 32 byte key (!!) and I don't think that a lot users
can remember it and so they will make notes and that isn't very good :(

Is there a way to get a 32 byte AES256 key from the user password?

On Mon Apr 22 2002; 17:55, kingruedi wrote:

> Is there a way to get a 32 byte AES256 key from the user password?

There is an easy way to solve your problem.

1. Generate a 256 bit random key.
2. Use the digest output of the passphrase (MD5/RMD160/SHA1).
3. Encrypt the key from step one with the digest key.
4. Encrypt the data with the key from step one.

[hopefully it is clear]


Timo

Am Montag, 22. April 2002 18:07 schrieb Timo Schulz:
> 1. Generate a 256 bit random key.

So I have the problem if I want to decrypt it I have to remember the random
key.

> 4. Encrypt the data with the key from step one.

from step one? for what is then step 2/3?

On Mon Apr 22 2002; 18:45, Rüdiger Sonderfeld wrote:


> > 1. Generate a 256 bit random key.
>
> So I have the problem if I want to decrypt it I have to
> remember the random key.

No. This key is encrypted with the digest key and this key (from the
digest) is derrived from the passphrase. So you don't need to remember
the randomly chosen key.


> 4. Encrypt the data with the key from step one.
>
> from step one? for what is then step 2/3?

You can compare this with the OpenPGP scheme:

The digest key protects the session key. This key does not encrypt
any data, it's just to encrypt the session key.


Timo

Am Montag, 22. April 2002 19:11 schrieb Timo Schulz:
> No. This key is encrypted with the digest key and this key (from the
> digest) is derrived from the passphrase. So you don't need to remember
> the randomly chosen key.

Okay I think I understand it now. But isn't there the danger of cracking the
encrypted passphrase?

On Mon Apr 22 2002; 19:52, Rüdiger Sonderfeld wrote:

> > digest) is derrived from the passphrase. So you don't need to remember
> > the randomly chosen key.
>
> Okay I think I understand it now. But isn't there the danger of
> cracking the encrypted passphrase?

There is no encrypted passphrase. But it's possible that somebody
crack the passphrase with a dictionary attack. Then he could decrypt
the encrypted session key...


Timo

On Mon, 22 Apr 2002 17:55:03 +0200, kingruedi said:

> That's bad :( I wanted to use the md5 sum of the user password as AES256 key.

It doesn't buy you any security if you as 256 bit key with not enough
key material. So use AES128 and lookup a decent string to key
algorithm - rfc2440 salted and iterated is probably a good choice and
code can be found in gnupg/g10/passphrase.c - basically it is this:

/* Transform a passphrase into a suitable key of length KEYLEN and
store this key in the caller provided buffer KEY. The caller must
provide an HASHALGO, a valid S2KMODE (see rfc-2440) and depending on
that mode an S2KSALT of 8 random bytes and an S2KCOUNT (a suitable
value is 96).

Returns an error code on failure. */
static int
hash_passphrase (const char *passphrase, int hashalgo,
int s2kmode,
const unsigned char *s2ksalt,
unsigned long s2kcount,
unsigned char *key, size_t keylen)
{
GCRY_MD_HD md;
int pass, i;
int used = 0;
int pwlen = strlen (passphrase);

if ( (s2kmode != 0 && s2kmode != 1 && s2kmode != 3)
|| !hashalgo || !keylen || !key || !passphrase)
return GNUPG_Invalid_Value;
if ((s2kmode == 1 ||s2kmode == 3) && !s2ksalt)
return GNUPG_Invalid_Value;

md = gcry_md_open (hashalgo, GCRY_MD_FLAG_SECURE);
if (!md)
return map_gcry_err (gcry_errno());

for (pass=0; used < keylen; pass++)
{
if (pass)
{
gcry_md_reset (md);
for (i=0; i < pass; i++) /* preset the hash context */
gcry_md_putc (md, 0);
}

if (s2kmode == 1 || s2kmode == 3)
{
int len2 = pwlen + 8;
unsigned long count = len2;

if (s2kmode == 3)
{
count = (16ul + (s2kcount & 15)) << ((s2kcount >> 4) + 6);
if (count < len2)
count = len2;
}

while (count > len2)
{
gcry_md_write (md, s2ksalt, 8);
gcry_md_write (md, passphrase, pwlen);
count -= len2;
}
if (count < 8)
gcry_md_write (md, s2ksalt, count);
else
{
gcry_md_write (md, s2ksalt, 8);
count -= 8;
gcry_md_write (md, passphrase, count);
}
}
else
gcry_md_write (md, passphrase, pwlen);

gcry_md_final (md);
i = gcry_md_get_algo_dlen (hashalgo);
if (i > keylen - used)
i = keylen - used;
memcpy (key+used, gcry_md_read (md, hashalgo), i);
used += i;
}
gcry_md_close(md);
return 0;
}


Use 3 for s2kmode and 96 for the count.

Werner

Am Montag, 22. April 2002 21:17 schrieb Timo Schulz:
> On Mon Apr 22 2002; 19:52, Rüdiger Sonderfeld wrote:
> > > digest) is derrived from the passphrase. So you don't need to remember
> > > the randomly chosen key.
> >
> > Okay I think I understand it now. But isn't there the danger of
> > cracking the encrypted passphrase?
>
> There is no encrypted passphrase. But it's possible that somebody
> crack the passphrase with a dictionary attack. Then he could decrypt
> the encrypted session key...

I meant the encrypted session key because it is crypted with a too short key
(the MD5 sum)

On Mon Apr 22 2002; 21:36, Rüdiger Sonderfeld wrote:

> > crack the passphrase with a dictionary attack. Then he could decrypt
> > the encrypted session key...
>
> I meant the encrypted session key because it is crypted with a too
> short key (the MD5 sum)

That's right, the secret (256 bits) would be protected by a {160,128}-bit
SHA/RMD160/MD5 key. But if you read some protocol specifications, for
example RFC2440, you'll see they use the same procedure for symmetric
encryption.


Timo