2
$\begingroup$

GCM specification defines the initial counter value $Y_0$ for encryption/decryption operations as follows: $$ Y_0=\begin{cases} IV||0^{31}1 &\text{if len}(IV)=96\\ GHASH(H,\{\},IV)& \text{otherwise} \end{cases} $$

I don't understand why hashing with $GHASH$ is used for $len(IV)<96$. Suppose I am using 64-bit deterministic IV's; it seems logical to create 128-bit deterministic initial counter value as $$ Y_0=IV||0^{63}1 $$ I believe it does not contradict GCM specification. Why the specification suggests to use pseudorandomized initial counter value?

Improve this question
$\endgroup$

1 Answer 1

Reset to default
2
$\begingroup$

If you want to use 64 bit deterministic IV's then you can. The NIST specifications call this the "deterministic construction" listed in section 8.2.1 of Special Publication 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.

The "deterministic IV" is then called the "invocation field" of the IV. That leaves you with 32 bits for the "fixed field", for which it is specified that:

Similarly, the entire fixed field may consist of arbitrary bits when there is only one context to identify, such as when a fresh key is limited to a single session of a communications protocol. In this case, if different participants in the session share a common fixed field, then the protocol shall ensure that the invocation fields are distinct for distinct data inputs.

...

The lengths and positions of the fixed field and the invocation field shall be fixed for each supported IV length for the life of the key. In order to promote interoperability for the default IV length of 96 bits, this Recommendation suggests, but does not require, that the leading (i.e., leftmost) 32 bits of the IV hold the fixed field; and that the trailing (i.e., rightmost) 64 bits hold the invocation field.

So as long as you are sure that your deterministic IV is unique, i.e. is a nonce, then you can do with the fixed field whatever you want - as long as both the encrypting party and decryption party use the same value, of course. So you can simply generate an IV consisting of a fixed field consisting of all zero's (a constant of 4 bytes set to zero) and use the nonce for the remaining part.

This way you don't need to use $\mathit{GHASH}$ for calculating $Y_0$ at all, which is more secure and more interoperable as not all GCM implementations may allow IV sizes other than 96 bit.

You would of course end up with $$Y_0=0^{32}\|nonce\|0^{31}1$$ instead of $$Y_0=nonce\|0^{63}1$$ for $Y_0$ but that doesn't matter much. In the resulting scheme, $0^{32}\|nonce$ would be called the IV and the postfixed $0^{31}1$ is generated by the GCM implementation. Of course, if you use $nonce\|0^{32}$ as IV then you would get your construction - and as you can see it is allowed but not recommended by NIST.

If your IV is smaller than 96 bits, you can always simply pad until you've got 96 bits; as long as the IV is unique, there is no problem.

Improve this answer
$\endgroup$
5
  • $\begingroup$ So your IV becomes an IF - hopefully this still answers your question :) $\endgroup$
    – Maarten Bodewes ♦
    Commented Aug 6, 2018 at 23:35
  • $\begingroup$ Some protocols use fixed field as Salt (RFC 4106). $\endgroup$
    – kludg
    Commented Aug 7, 2018 at 4:20
  • $\begingroup$ @kludg They derive that salt together with the key. The key in itself should be random enough for the session as it is derived for it and the remaining 64 bits should already make the counter unique. Besides that, a salt of 32 bits is very small. If anybody can explain the choice of a salt in that protocol I'm all ears; it feels like a rather dumb idea to me. $\endgroup$
    – Maarten Bodewes ♦
    Commented Aug 7, 2018 at 4:46
  • $\begingroup$ OK. Maybe better use for the fixed field is to have several users encrypting/decrypting with the same key, each user has unique fixed field to ensure that 96-bit IV's of different users never coincide. $\endgroup$
    – kludg
    Commented Aug 7, 2018 at 5:05
  • $\begingroup$ @kludg Yeah, that would be in sync with the NIST recommendations. Generally you'd try to have a unique identifier for both the sender and receiver, but that may be tricky to put into 32 bits. Simply identifying the sender and possibly the stream would probably do the trick; the receiver is anybody who has the key after all. $\endgroup$
    – Maarten Bodewes ♦
    Commented Aug 7, 2018 at 10:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.