[email protected] (Niels Möller) writes:

> Nikos Mavrogiannopoulos have been looking into support for Galois
> Counter Mode (GCM), see http://www.cryptobarn.com/papers/gcm-spec.pdf

I've checked in a first version, based on Nikos' code. Tentative
interface as follows:

  #define GCM_BLOCK_SIZE 16
  #define GCM_IV_SIZE (GCM_BLOCK_SIZE - 4)
  
  #define GCM_TABLE_BITS 0
  
  struct gcm_ctx {
    /* Key-dependent state. */
    /* Hashing subkey */
    uint8_t h[GCM_BLOCK_SIZE];
  #if GCM_TABLE_BITS
    uint8_t h_table[1 << GCM_TABLE_BITS][GCM_BLOCK_SIZE];
  #endif
    /* Per-message state, depending on the iv */
    /* Original counter block */
    uint8_t iv[GCM_BLOCK_SIZE];
    /* Updated for each block. */
    uint8_t ctr[GCM_BLOCK_SIZE];
    /* Hashing state */
    uint8_t x[GCM_BLOCK_SIZE];
    uint64_t auth_size;
    uint64_t data_size;
  };
  
  /* FIXME: Should use const for the cipher context. Then needs const for
     nettle_crypt_func, which also rules out using that abstraction for
     arcfour. */
  void
  gcm_set_key(struct gcm_ctx *ctx,
            void *cipher, nettle_crypt_func *f);
  
  void
  gcm_set_iv(struct gcm_ctx *ctx, unsigned length, const uint8_t *iv);
  
  void
  gcm_auth(struct gcm_ctx *ctx, unsigned length, const uint8_t *data);
  
  void
  gcm_encrypt(struct gcm_ctx *ctx, void *cipher, nettle_crypt_func *f,
            unsigned length, uint8_t *dst, const uint8_t *src);
  
  void
  gcm_decrypt(struct gcm_ctx *ctx, void *cipher, nettle_crypt_func *f,
            unsigned length, uint8_t *dst, const uint8_t *src);
  
  void
  gcm_digest(struct gcm_ctx *ctx, void *cipher, nettle_crypt_func *f,
           unsigned length, uint8_t *digest);

Comments on both structure and naming are welcome.

> My understanding of GCM is that the main point is a new MAC function
> which allows efficient hardware implementation.

The unoptimized GF(2^128) multiply function really is awfully slow. On
x86_64, gmac takes 830 cycles/byte! We can compare to the sha functions,
where sha1, sha256 and sha512 take respectively 8, 18 and 12
cycles/byte, so the current code is two orders of magnitude slower than
hmac-sha1.

It remains to see how much table space and/or assembly hacking is needed
to get reasonable performance.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Reply via email to