4
$\begingroup$

Since a nonce must be unique and that time only goes forward, is it safe to use the Unix epoch as nonce ?

My use case is be AES w/ GCM which recommends a nonce length of 12B. Current Unix time can be represented using 4B, so that leaves the upper 8B free for future timestamps (plenty of space).

One possible security implication is the forgery of NTP replies, which would cause the client to use a Unix timestamp in the past (i.e. breaks the stream cipher). Secure channels should prevent this from happening, but a bad operator could always force bad NTP replies.

| improve this question | |
$\endgroup$
  • 2
    $\begingroup$ time doesn't "only goes forward" on computers: once a year it goes backwards on most of them. While the unix stamp doesn't care about DST adjustments, a real-system could return the same unix timestamp on two different occasions. A nonce should ideally be unpredictable... $\endgroup$ – dandavis Jul 22 '16 at 17:31
  • 2
    $\begingroup$ @dandavis while the time zone thing is a good note, a nonce has no expectation of being unpredictable. An IV is supposed to be unpredictable, a nonce is supposed to be unique (hence why a counter is often used - completely predictable, but unique) $\endgroup$ – Ella Rose Jul 22 '16 at 19:34
  • $\begingroup$ @EllaRose: doh! reading comprehension anyone? thanks for the head-up! $\endgroup$ – dandavis Jul 22 '16 at 19:37
6
$\begingroup$

Using a Unix Timestamp as the sole source for the nonce would make me nervous.

In addition to forged NTP replies (and legitimate operators deliberately resetting the clock for some reason, and I'm not sure whether leap seconds would pose a risk), you also would need to worry about "what if I send two messages within the same second"

On the other hand, you have 12 bytes to play with; if you use four of the bytes to hold the Unix timestamp, and use another four as a counter (which you increment every time you send a message), and the other four as something else, that'd be a system which would be more resilient against nonce repeats.

| improve this answer | |
$\endgroup$
  • 1
    $\begingroup$ Using the remaining 8 bytes is indeed clever, thanks for pointing it out. $\endgroup$ – Dreadlockyx Jul 23 '16 at 13:15
  • $\begingroup$ This is effectively the same scheme as employed by time-based GUIDs. Your OS or programming language likely has a type-1 GUID/UUID function, and you can simply lip off a few of the unneeded time stamp or node ID bits to get yourself a solid 96-bit nonce for use with AES-GCM. Getting the state management right can be tricky so I suggest using well-tested OS or standard library facilities if available. See tools.ietf.org/html/rfc4122#section-4.2 $\endgroup$ – rmalayter Jul 25 '16 at 2:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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