Opened 5 years ago

Last modified 4 months ago

#11050 new defect

pycrypto's AES implementation is not constant time

Reported by: yawning Owned by:
Priority: Medium Milestone:
Component: Archived/Obfsproxy Version:
Severity: Normal Keywords: AES, cache timing, pycrypto
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

This is a non-issue when AES-NI is supported by the host CPU since a separate code path is taken.

https://github.com/dlitz/pycrypto/blob/master/src/AES.c

It's not too bad in the pluggable transport case since traffic is super-enciphered, the session keys are ephemeral, and actually extracting sufficiently accurate timing information is probably non-trivial, but it probably should be addressed somehow.

Child Tickets

Change History (4)

comment:1 Changed 4 years ago by lukep

We could write cache timing attack resistant version of AES for pycrypto, eg. this one:

http://academic.research.microsoft.com/Publication/4247637/a-fast-and-cache-timing-resistant-implementation-of-the-aes

It uses no table lookups so no timing attack, and 4x parallel bit slicing so is fast too.

comment:2 Changed 18 months ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

comment:3 Changed 4 months ago by teor

Owner: asn deleted
Status: newassigned

asn does not need to own any obfuscation tickets any more. Default owners are trouble.

comment:4 Changed 4 months ago by cohosh

Status: assignednew

tickets are unassigned, reverting to 'new'

Note: See TracTickets for help on using tickets.