Re: the skein hash function

2008-11-01 Thread Peter Gutmann
Bill Stewart [EMAIL PROTECTED] writes:

A quick google-look at ASICs showed a number in the range of 300K-20M gates,
so hash-trees could probably get speedups of up to 20-100x if you can keep
from becoming input-speed-bound. The 300K chips were about $6, 5M at $50 and
350MHz, which is somewhat faster than the Skein team estimate, and some of
the denser chips didn't mention price but were starting to use 45nm

I don't know about ASICs but for FPGAs you can pay in the thousands of dollars
for a single high-end device (forget Xeons, that's the market to be in), so
you don't want to set your sights too high.  My guess is they were designing
down to a price rather than up to a performance figure.


The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Bitcoin P2P e-cash paper

2008-11-01 Thread Satoshi Nakamoto
I've been working on a new electronic cash system that's fully
peer-to-peer, with no trusted third party.

The paper is available at:

The main properties:
 Double-spending is prevented with a peer-to-peer network.
 No mint or other trusted parties.
 Participants can be anonymous.
 New coins are made from Hashcash style proof-of-work.
 The proof-of-work for new coin generation also powers the
network to prevent double-spending.

Bitcoin: A Peer-to-Peer Electronic Cash System

Abstract.  A purely peer-to-peer version of electronic cash would
allow online payments to be sent directly from one party to another
without the burdens of going through a financial institution.
Digital signatures provide part of the solution, but the main
benefits are lost if a trusted party is still required to prevent
double-spending.  We propose a solution to the double-spending
problem using a peer-to-peer network.  The network timestamps
transactions by hashing them into an ongoing chain of hash-based
proof-of-work, forming a record that cannot be changed without
redoing the proof-of-work.  The longest chain not only serves as
proof of the sequence of events witnessed, but proof that it came
from the largest pool of CPU power.  As long as honest nodes control
the most CPU power on the network, they can generate the longest
chain and outpace any attackers.  The network itself requires
minimal structure.  Messages are broadcasted on a best effort basis,
and nodes can leave and rejoin the network at will, accepting the
longest proof-of-work chain as proof of what happened while they
were gone.

Full paper at:

Satoshi Nakamoto

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: Who cares about side-channel attacks?

2008-11-01 Thread Ray Dillinger
On Thu, 2008-10-30 at 16:32 +1300, Peter Gutmann wrote:
 Look at the XBox
 attacks for example, there's everything from security 101 lack of
 checking/validation and 1980s MSDOS-era A20# issues through to Bunnie Huang's
 FPGA-based homebrew logic analyser and use of timing attacks to recover device
 keys (oh, and there's an example of a real-world side-channel attack for you),
 there's no rhyme or reason to them, it's just hammer away at everything with
 anything you've got and exploit the first bit that fails.

But isn't that the attacker's job?  We will never arrive at anything
secure - or even *learn* anything about how to build real security - 
if attackers leave any part of it untested or consistently fail to 
try particular approaches.  As far as I can see the acid tests of 
the real world, hammering away with anything they've got, are exactly
the kind of environment that security pros have to design for in the 
long run.  

We should be trying to identify products and implementations that 
hold up under this kind of assault, and then publishing books about 
the design processes and best practices that produced them.  Knowing 
full well that Kerchoff's Principle is alive and well, and that 
the people doing the attacks will be first in line to buy the 
books.  The point is that if the material in the books is any 
good, then having the books shouldn't help them. 

Cipher suites and protocols and proofs and advanced mathematics 
are well and good, but we have to recognize that they are only a 
small part of actually building a secure implementation.  Holding up 
under diverse assault *is* the desired property that we are all 
supposed to be working toward, and this kind of diverse assault 
is exactly the sort of test we need to validate security design 


The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]