[Authentication] Fwd: Re: Session negotiation

[Michael Leupold]

On Thursday 16 July 2009 12:18:20 Brad Hards wrote:
> On Thursday 16 July 2009 18:45:16 Michael Leupold wrote:
> > I wasn't talking about reuse, I was more or less considering the secrets
> > to be passed through a stream cipher that whose state was established on
> > session start. After trying I figured it's not the right approach though
> > as while the same secret encrypted over and over produces different
> > encrypted results they have to be manually padded/unpadded as apparently
> > crypto libraries only support padding on the last block encrypted (at
> > least libqca does).
>
> I'm confused as to what you're trying to do.  Maybe you can explain again?
> If you pass the same inputs into a cipher, then you'll (obviously) get the
> same output.
> In this context, the cipher algorithm and mode (e.g. AES128-CBC) takes a
> key, an IV, and the plain text ("secret") and produces some ciphertext.
> [The padding (or lack thereof) is a function of the block mode and
> algorithm, but we might want to use additional padding to avoid disclosing
> how long the plain text is.]

I was thinking about establishing an encrypted stream similar to this one:
------------------------ zip ------------------------
  gcry_cipher_hd_t handle;
  char *key = "1234567890123456";
  char *iv = "abcdefghijklmnop";
  unsigned char outBuf1[16];
  unsigned char outBuf2[16];
  unsigned char inBuf[16];

  strncpy(inBuf, "test", 4);

  gcry_cipher_open(&handle, GCRY_CIPHER_AES128, GCRY_CIPHER_MODE_CBC, 0);
  gcry_cipher_setkey(handle, key, 16);
  gcry_cipher_setiv(handle, iv, 16);

  gcry_cipher_encrypt(handle, outBuf1, 16, inBuf, 16);
  gcry_cipher_encrypt(handle, outBuf2, 16, inBuf, 16);

  if (strncmp(outBuf1, outBuf2, 16) == 0) {
    printf("same\n");
  } else {
    printf("different\n"); <--
  }
------------------------ zip ------------------------
(Please note that I'm no longer proposing to do it like that :-))

So as long as the handle was stored (session-specific), you wouldn't need to 
reinit to get different encrypted results for the same input secret.
As I mentioned, the main problems with this approach are that the order in 
which secrets are decrypted has to be the same as the encryption order (which 
might add complexity) and that you obviously have to decrypt every secret 
received (which might not always be desireable).

> We need to generate the key from some kind of passphrase (or other source,
> but passphrase is what I expect from this). So we need to define how to
> produce the key, and we need to store the IV with the ciphertext version of
> the secret. I think each secret should be encrypted separately (and so have
> a different IV).

As I imagine it, the symkey used for secret transport will be assembled from 
random values using diffie-hellman. And yes, due to the constraints mentioned 
above we'd really have to send ivs along each of the secrets.

Regards,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/authentication/attachments/20090716/65b09083/attachment.pgp