@tomstdenis: "Ok tonight [if all goes well] at roughly 9PM [-5GMT] I will have a live 
server up.  It will be a UDP server on port 8500 [at iahu.ca].  It will 
accept 16 byte plaintexts and produce 16 byte ciphertexts.
So the program will do the following
1.  Choose a random 16 byte key and schedule it
2.  Print out the SHA-256 of the key
3.  Accept UDP packets [rejects non 16 byte packets] and reply
4.  Terminate after 24 hours.
The process will be niced down to ensure nobody DoS'es my box ;-)
The server will be turned off at 9PM Saturday or when the key is 
reported back to me.  To keep things level I will post the SHA-256 of 
the key to sci.crypt so that it's "escrowed" ;-)
So D.J B your challenge is to write a client that interfaces with my 
program and extract the key.  I will be posting the source code when I 
go live and I won't be using any timing tricks [e.g. FIFO and just 
straight calls to LTC].
This should settle any lingering doubts I have about the attack ;-)
Tom"
    @fgrieu: " Tom St Denis <email_address> hopes that he
<quote>
The context (rather than the challenge statement) makes it clear
AES-128, LibTomCrypt bleeding-edge-version, some variant of GCC,
and some unspecified x86 CPU will be used.
This challenge makes little sense IMHO, because
- A real attack is likely to obtain more precise timing information
than available thru the DJB-TSD net connection, by orders of
magnitude. Think of another process running on the same machine,
and logging the holes in the CPU performance counter; or even an
instrumented access to the machines's Ethernet interface.
- An interesting attacker has time to prepare her attack, and is
assumed to have access to an exact replica of the setup. And
she decides when and how she attacks her target.
  Francois Grieu"
    @tomstdenis: "<quote>
It will be AES-128, LTC 0.99 with patchset 001, gcc 3.4.2-r1 [gentoo 
variety] on an NewCastle AMD64 3200+
Um that requires breaking into the box and still going through the IP 
stack even if just locally.  I want DJ to show this attack from a 
realistic standpoint.
So far I have
<url>
Which has two parts.  "djchal" which will run the challenge server on 
port 8500 and "djping" which tests pinging the server.
Tom"
    @fgrieu: "<quote>
The attacker running code at the user level in another process
on the attacked machine is an entirely reasonable threat model.
And an instrumented access to the machines's IP link does
not qualify as breaking into the box, but as a passive external
tap, which is about the default model in cryptography, and a
very realistic one (e.g think wi-fi). Also think that the attacker
could manage to encipher a number of repeated blocks rather than one,
which will vastly improve her S/N ratio in timing measurements.
If you want a more scientific challenge, have your server record the
CPU performance counter before and after encrpytion, and disclose
this as well as the enrypted result.
  Francois Grieu"
    @tomstdenis: "<quote>
Hey wait a sec.  DJ is the one saying SSL is weak.  Last I checked SSL 
isn't meant for localhost connections.
If DJ can't stand behind what he is claiming that's one thing.  But as I 
see it my challenge is an appropriate response to his claims.  The 
source is even public and heck you can have multiple people run the 
challenge if you want.
Tom"
    @tomstdenis: "<quote>
How so?  The source for the challenge is public, easily accessible and 
totally appropriate for DJ's claims.  He's claiming SSL is broken [at 
least it's AES component].  I think it's not.  So I am posting a LOW 
latency server [as opposed to TCP based] that will handle AES queries in 
a trivial fashion.
As for the "criteria" I couldn't care less for what you or the FAQ 
thinks.  I'm trying to play scientist and am challenging his claims.  If 
AES is so weak w.r.t. the timing attack he should be able to pop out the 
key.
I'm going to modify my source "djchal.c" to output the key to the screen 
as well.  That way if he can only find parts of the key we can check them.
Tom"
    @nospam: "Well I think Tom St Denis challenge is just perfect and realistic..
Just because you other fuckheads can't keep your PC secure doesn't mean that
Tom can't keep his PC secure.
I will assumy Tom's PC is unhackable =D
So you people are just drawing on other vunerabilities...
If one can hack into a system then cracking encryption is pretty bullshit
one can simply look for the key or wait until the key is typed in by a user.
It's as simple as that.
In short: encryption/decryption is useless for a hacked system.
The means the contest should be held on a unhackable system. :P
This is after all an encryption *crack* attempt and not some bullshit hack
attempt :D
news:<email_address>
<quote>"
    @tomstdenis: "<quote>
The source I plan on using is now up at
<url>
I will be using that to run the challenge server.  It now outputs the 
key to the screen.  I'll copy it down and see if DJ or anyone else [all 
are welcomed to try] can get key bytes.
The server will go live at 9pm tonight [in roughly 5 hours].  ;-)
Tom"
    @tomstdenis: "<quote>
Slight change.  The reply is now the plaintext + ciphertext [32 bytes]. 
  That way it will handle out of order packets.  The source on the 
website has been updated.
Tom"
    @tomstdenis: "<quote>
I don't get it though.  You said SSL was vulnerable to this attack. 
Surely SSL over TCP has to be higher latency than my single purpose 
server over UDP.
Tom"
    @DAGwyn: "<quote>
As was already noted by another poster, a proper test of
a cryptosystem requires leaving the experiment design up
to the cryptanalyst.  DJB has already demonstrated the
advertised effect, which leaks an unacceptable amount of
key to the prober, and his demonstration requires a
certain amount of control over the probing process.
Although analogies can be misleading, let's try one.
Suppose an automotive engineer determined that for a
particular make and model vehicle, a safety-crucial
fastener would loosen and perhaps fall off after a
certain amount of turning the steering wheel back and
forth rather often on an upgrade in second gear.  (This
is a driving scenario that some drivers encounter from
time to time, but it is not the typical usage.)  Your
challenge is not unlike the manufacturer putting the car
in a straight, level tunnel and telling the engineer
"Now show me how you can make the fastener fall off,
otherwise I maintain that it is not a real problem and
won't bother to fix it.".
Timing attacks as a class are fairly well known and some
have been published in recent open cryptologic literature.
Power consumption fluctuation analysis is a similar method
that has received some public attention.  In the same
spirit is analysis through hardware error induction.
Just as with massive controlled-plaintext attacks, the
circumstances under which such methods are feasible vary,
but do occur in practice often enough that one at the
very least needs to consider them in conjunction with the
threat model when designing a cryptosystem."
    @fgrieu: "<quote>
I believe that the attack also works with known random plaintext,
a weaker assumption.
I do admit that attack against a real system is going to require
skill. And if I knew a deployed system, I would not tell. So here
is my try at a simple theoretical example.
Steps of an anthentication process involves the client sending
its ID (64 bits) "securely", as follows
  a) server sends challenge X (64 bits)
  b) client decrypts X#ID using AES under long-term shared key K
     and sends result C to the server
  c) server encrypts C under K, giving X'#ID'. If X!=X', server
     rejects request (else it accepts request and assume ID' is ID)
I'll assume an attacking process on the same machine (launched
thru a remote telnet connection on a guest account) communicating
with the server only thru memory, NOT southbridge, PCI bus, Ethernet.
I'm not a network guru, but I believe IP requests to the localhost
are processed in this way. It is then reasonable to assume that
only the AES decrypt code will cause data-dependant delays.
Assuming that no other processes is hogging on the machine,
querying the performance counter between sumbitting the request
(end of b) and receiving the rejection (end of c) is likely to
be related to the decryption time.
Note that the client can fully choose the input to the AES box.
I guess that most variability will come from DRAM latencies
(if the cache is overwhelmed), and interrupts. The attacker
probably can remove/average these out with many samples, and
- rejecting timing samples that are not within a preset limit
  from the minimal sampled time (or some other ad hoc samples
  reprocessing).
- having detected a main source of perturbation (if any), like
  a periodical interrupt, waiting until after this perturbation
  to submit a request.
- flushing caches before submitting a request.
Thinking about it, an attacker conceivably could get leaked
information on data-dependant cache flushes in a better way
than just timing: by examining which cache lines (that he
preloaded) have been flushed by an encipherement. Worse, the
attacker could activate this analysis by interrupt at a precise
moment relative to the encipherement... Scary.
   Francois Grieu"
    @fgrieu: "<quote>
I believe that the attack also works with known random plaintext,
a weaker assumption.
I do admit that attack against a real system is going to require
skill. And if I knew a deployed system that is vulnerable, I would
not tell. So here is my try at a simple theoretical example.
Steps of an anthentication process involves the client sending
its ID (64 bits) "securely", as follows
  a) server sends challenge X (64 bits)
  b) client decrypts X#ID using AES under long-term shared key K
     and sends result C to the server
  c) server encrypts C under K, giving X'#ID'. If X!=X', server
     rejects request (else it accepts request and assume ID' is ID)
I'll assume an attacking process on the same machine (launched
thru a remote telnet connection on a guest account) communicating
with the server only thru memory, NOT southbridge, PCI bus, Ethernet.
I'm not a network guru, but I believe IP requests to the localhost
are processed in this way. It is then reasonable to assume that
only the AES decrypt code will cause data-dependant delays.
Assuming that no other processes is hogging on the machine,
querying the performance counter between sumbitting the request
(end of b) and receiving the rejection (end of c) is likely to
be related to the decryption time.
Note that the client can fully choose the input to the AES box.
I guess that most variability will come from DRAM latencies
(if the cache is overwhelmed), and interrupts. The attacker
probably can remove/average these out with many samples, and
- rejecting timing samples that are not within a preset limit
  from the minimal sampled time (or some other ad hoc samples
  reprocessing).
- having detected a main source of perturbation (if any), like
  a periodical interrupt, waiting until after this perturbation
  to submit a request.
- flushing caches before submitting a request.
Thinking about it, an attacker conceivably could get leaked
information on data-dependant cache flushes in a better way
than just timing: by examining which cache lines (that he
preloaded) have been flushed by an encipherement. Worse, the
attacker could activate this analysis by interrupt at a precise
moment relative to the encipherement... Scary.
   Francois Grieu"
{'source': 'USENET', 'other_information': '{"reply_count": 12, "forum_name": "sci.crypt.20141022.mbox"}', 'file': 'data/output/usenet-sci.crypt.parquet'}