>> I find that when I do a CIOCCRYPT, the IV is not modified.  How am I
>> supposed to get the correct IV for my next call?  Do I have to go
>> under the hood and "know" that for the cipher I'm using (3DES_CBC)
>> it's the last block of the encrypted data (output for ENCRYPT, input
>> for DECRYPT)?  Or is there something I'm missing?
> One good way to see how it all works is to look at the /dev/crypto
> engine Jonathan added to our OpenSSL --

If you mean src/crypto/dist/openssl/crypto/engine/hw_cryptodev.c (one
of only two places in the entire source tree which open /dev/crypto,
the other being src/crypto/dist/openssl/crypto/evp/openbsd_hw.c), it
does go under the hood.  (Line numbers are from the version sup fetched
for me 2005-03-26 11:17 UTC; I don't see an RCS ID line in it.)

   400          if (ctx->cipher->iv_len) {
   401                  cryp.iv = (caddr_t) ctx->iv;
   402                  if (!ctx->encrypt) {
   403                          iiv = (void *) in + inl - ctx->cipher->iv_len;
   404                          memcpy(save_iv, iiv, ctx->cipher->iv_len);
   405                  }
   406          } else
   407                  cryp.iv = NULL;
[the CIOCCRYPT ioctl, and error handling, snipped as irrelevant here]
   416          if (ctx->cipher->iv_len) {
   417                  if (ctx->encrypt)
   418                          iiv = (void *) out + inl - ctx->cipher->iv_len;
   419                  else
   420                          iiv = save_iv;
   421                  memcpy(ctx->iv, iiv, ctx->cipher->iv_len);
   422          }

It appears to assume that any cryptosystem with an IV is doing
CBC-style feedback.  This will break when someone gets around to adding
the counter modes (see draft-ietf-secsh-newmodes-03.txt), unless their
state is represented somewhere other than the IV storage....

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B