title: Source and importance of nonce / IV for protocol using AES-GCM
body: <p>I am making a protocol that uses packets (i.e., not a stream) encrypted with AES.  I've decided on using GCM (based off CTR) because it provides integrated authentication and is part of the NSA's Suite B.  The AES keys are negotiated using ECDH, where the public keys are signed by trusted contacts as a part of a web-of-trust using something like ECDSA. <strike>I believe that I need a 128-bit nonce / initialization vector for GCM because even though I'm using a 256 bit key for AES, it's always a 128 bit block cipher (right?)</strike>  I'll be using a 96 bit IV after reading the BC code.</p>
  
  <p>I'm definitely not implementing my own algorithms (just the protocol -- my crypto provider is BouncyCastle), but I still need to know how to use this nonce without shooting myself in the foot.  The AES key used in between two people with the same DH keys will remain constant, so I know that the same nonce should not be used for more than one packet.</p>
  
  <p>Could I simply prepend a 96-bit pseudo random number to the packet and have the recipient use this as a nonce?  This is peer-to-peer software and packets can be sent by either at any time (e.g., an instant message, file transfer request, etc.) and speed is a big issue so it would be good not to have to use a secure random number source.  The nonce doesn't have to be secret at all, right?  Or necessarily as random as a "cryptographically secure" PNRG?  Wikipedia says that it should be random, or else it is susceptible to a chosen plaintext attack -- but there's a "citation needed" next to both claims and I'm not sure if that's true for block ciphers.  Could I actually use a counter that counts the number of packets sent (separate from the counter of the number of 128 bit blocks) with a given AES key, starting at 1?  Obviously this would make the nonce predictable.  Considering that GCM authenticates as well as encrypts, would this compromise its authentication functionality?</p>