Skip to main content
Commonmark migration
Source Link

#This is not the Timing Attack you are looking for!

This is not the Timing Attack you are looking for!


##Introduction

Introduction

I recently was writing a piece of code to verify a HMAC signature (to verify an API request). While doing that I found the given method in the documentation to be "incredibly verbose" and as a somewhat as a somewhat active PPCG member, that's obviously something that needs to be "fixed"! However being also an active member of Crypto.SE I know that HMAC tag verification needs to expose secret independent timing (a.k.a. "needs to be constant time") because otherwise an attacker may just brute-force a valid tag with a couple of dozen / hundred queries checking each time up to which byte was correct.

The input

The input is two strings a and b which are guaranteed to be of the same length and encoding.

The output

The output is a truthy or falsey value.

What to do?

You return a truthy output if a and b have the same content and a falsey value otherwise.

That sounds too easy, where's the catch!?

Your code must exhibit secret independent timing, that is the runtime of your code may not depend on the actual values of the two strings. To be valid your answer must provide a convincing argument that the execution time is independent of the secret values. To help you, I've listed a helpful guidelines:

  • For secret-independent timing it is sufficient to use a non secret independent comparison on the HMAC of both strings under a fresh random key.
  • For secret-independent timing there must not be early (loop-) returns or operations that are not evaluated due to short circuiting semantics (assuming you operate on the actual strings).
  • For secret-independent timing the values must not be used as array indices or for similar lookups as timing variation can happen due to caching.
  • For secret-independent timing the value must not contribute to control-flow decisions, e.g. as a condition for a while or if or as an operand to a short-circuiting &&.
  • For secret-independent timing the value must not contribute to operands to multplication or division instructions.

##Who wins?

Who wins?

This is so the shortest code in bytes per language that satisfies the I/O and the runtime behavior wins!

#This is not the Timing Attack you are looking for!


##Introduction

I recently was writing a piece of code to verify a HMAC signature (to verify an API request). While doing that I found the given method in the documentation to be "incredibly verbose" and as a somewhat as a somewhat active PPCG member, that's obviously something that needs to be "fixed"! However being also an active member of Crypto.SE I know that HMAC tag verification needs to expose secret independent timing (a.k.a. "needs to be constant time") because otherwise an attacker may just brute-force a valid tag with a couple of dozen / hundred queries checking each time up to which byte was correct.

The input

The input is two strings a and b which are guaranteed to be of the same length and encoding.

The output

The output is a truthy or falsey value.

What to do?

You return a truthy output if a and b have the same content and a falsey value otherwise.

That sounds too easy, where's the catch!?

Your code must exhibit secret independent timing, that is the runtime of your code may not depend on the actual values of the two strings. To be valid your answer must provide a convincing argument that the execution time is independent of the secret values. To help you, I've listed a helpful guidelines:

  • For secret-independent timing it is sufficient to use a non secret independent comparison on the HMAC of both strings under a fresh random key.
  • For secret-independent timing there must not be early (loop-) returns or operations that are not evaluated due to short circuiting semantics (assuming you operate on the actual strings).
  • For secret-independent timing the values must not be used as array indices or for similar lookups as timing variation can happen due to caching.
  • For secret-independent timing the value must not contribute to control-flow decisions, e.g. as a condition for a while or if or as an operand to a short-circuiting &&.
  • For secret-independent timing the value must not contribute to operands to multplication or division instructions.

##Who wins?

This is so the shortest code in bytes per language that satisfies the I/O and the runtime behavior wins!

This is not the Timing Attack you are looking for!


Introduction

I recently was writing a piece of code to verify a HMAC signature (to verify an API request). While doing that I found the given method in the documentation to be "incredibly verbose" and as a somewhat as a somewhat active PPCG member, that's obviously something that needs to be "fixed"! However being also an active member of Crypto.SE I know that HMAC tag verification needs to expose secret independent timing (a.k.a. "needs to be constant time") because otherwise an attacker may just brute-force a valid tag with a couple of dozen / hundred queries checking each time up to which byte was correct.

The input

The input is two strings a and b which are guaranteed to be of the same length and encoding.

The output

The output is a truthy or falsey value.

What to do?

You return a truthy output if a and b have the same content and a falsey value otherwise.

That sounds too easy, where's the catch!?

Your code must exhibit secret independent timing, that is the runtime of your code may not depend on the actual values of the two strings. To be valid your answer must provide a convincing argument that the execution time is independent of the secret values. To help you, I've listed a helpful guidelines:

  • For secret-independent timing it is sufficient to use a non secret independent comparison on the HMAC of both strings under a fresh random key.
  • For secret-independent timing there must not be early (loop-) returns or operations that are not evaluated due to short circuiting semantics (assuming you operate on the actual strings).
  • For secret-independent timing the values must not be used as array indices or for similar lookups as timing variation can happen due to caching.
  • For secret-independent timing the value must not contribute to control-flow decisions, e.g. as a condition for a while or if or as an operand to a short-circuiting &&.
  • For secret-independent timing the value must not contribute to operands to multplication or division instructions.

Who wins?

This is so the shortest code in bytes per language that satisfies the I/O and the runtime behavior wins!

Source Link
SEJPM
  • 3.4k
  • 8
  • 8

#This is not the Timing Attack you are looking for!


##Introduction

I recently was writing a piece of code to verify a HMAC signature (to verify an API request). While doing that I found the given method in the documentation to be "incredibly verbose" and as a somewhat as a somewhat active PPCG member, that's obviously something that needs to be "fixed"! However being also an active member of Crypto.SE I know that HMAC tag verification needs to expose secret independent timing (a.k.a. "needs to be constant time") because otherwise an attacker may just brute-force a valid tag with a couple of dozen / hundred queries checking each time up to which byte was correct.

The input

The input is two strings a and b which are guaranteed to be of the same length and encoding.

The output

The output is a truthy or falsey value.

What to do?

You return a truthy output if a and b have the same content and a falsey value otherwise.

That sounds too easy, where's the catch!?

Your code must exhibit secret independent timing, that is the runtime of your code may not depend on the actual values of the two strings. To be valid your answer must provide a convincing argument that the execution time is independent of the secret values. To help you, I've listed a helpful guidelines:

  • For secret-independent timing it is sufficient to use a non secret independent comparison on the HMAC of both strings under a fresh random key.
  • For secret-independent timing there must not be early (loop-) returns or operations that are not evaluated due to short circuiting semantics (assuming you operate on the actual strings).
  • For secret-independent timing the values must not be used as array indices or for similar lookups as timing variation can happen due to caching.
  • For secret-independent timing the value must not contribute to control-flow decisions, e.g. as a condition for a while or if or as an operand to a short-circuiting &&.
  • For secret-independent timing the value must not contribute to operands to multplication or division instructions.

##Who wins?

This is so the shortest code in bytes per language that satisfies the I/O and the runtime behavior wins!