Re: [Cryptography] Key stretching

2013-10-13 Thread Ray Dillinger
On 10/11/2013 11:22 AM, Jerry Leichter wrote:

 1.  Brute force.  No public key-stretching algorithm can help, since the 
 will brute-force the k's, computing the corresponding K's as he goes.

There is a completely impractical solution for this which is applicable
in a very few ridiculously constrained situations.  Brute force can
be countered, in very limited circumstances, by brute bandwidth.

You have to use random salt sufficient to ensure that all possible
decryptions of messages transmitted using the insufficient key or
insecure cipher are equally valid.

Unfortunately, this requirement is cumulative for *ALL* messages that
you encrypt using the key, and becomes flatly impossible if the total
amount of ciphertext you're trying to protect with that key is greater
than a very few bits.

So, if you have a codebook that allows you to transmit one of 128 pre-
selected messages (7 bits each) you could use a very short key or an
insecure cipher about five times, attaching (2^35)/5 bits of salt to
each message, to achieve security against brute-force attacks.  At
that point your opponent sees all possible decryptions as equally
likely with at least one possible key that gives each of the possible
total combinations of decryptions (approximately; about 1/(2^k) of the
total number of possible decryptions will be left out, where k is the
size of your actual too-short key).

The bandwidth required is utterly ridiculous, but you can get
security on a few very short messages, assuming there's no identifiable
pattern in your salt.

Unfortunately, you cannot use this to leverage secure transmission of
keys, since whatever key larger than the initial key you transmit
using this scheme, once your opponent has ciphertext transmitted
using the longer key, the brute-force method against the possibilities
for your initial short key becomes applicable to that ciphertext.


The cryptography mailing list

[Cryptography] Broken RNG renders gov't-issued smartcards easily hackable.

2013-10-11 Thread Ray Dillinger
Saw this on Arstechnica today and thought I'd pass along the link.

More detailed version of the story available at:

Short version:  Taiwanese Government issued smartcards to citizens.
Each has a 1024 bit RSA key.  The keys were created using a borked
RNG.  It turns out many of the keys are broken, easily factored,
or have factors in common, and up to 0.4% of these cards in fact
provide no encryption whatsoever (RSA keys are flat out invalid,
and there is a fallback to unencrypted operation).

This is despite meeting (for some inscrutable definition of meeting)
FIPS 140-2 Level 2 and Common Criteria standards.  These standards
require steps that were clearly not done here.  Yet, validation
certificates were issued.

Taiwan is now in the process of issuing a new generation of
smartcards; I hope they send the clowns who were supposed to test
the first generation a bill for that.


The cryptography mailing list

Re: [Cryptography] prism-proof email in the degenerate case

2013-10-10 Thread Ray Dillinger
On 10/10/2013 12:54 PM, John Kelsey wrote:
 Having a public bulletin board of posted emails, plus a protocol 
 for anonymously finding the ones your key can decrypt, seems 
 like a pretty decent architecture for prism-proof email.  The 
 tricky bit of crypto is in making access to the bulletin board 
 both efficient and private.  

Wrong on both counts, I think.  If you make access private, you
generate metadata because nobody can get at mail other than their
own.  If you make access efficient, you generate metadata because
you're avoiding the wasted bandwidth that would otherwise prevent
the generation of metadata. Encryption is sufficient privacy, and
efficiency actively works against the purpose of privacy.

The only bow I'd make to efficiency is to split the message stream
into channels when it gets to be more than, say, 2GB per day. At
that point you would need to know both what channel your recipient
listens to *and* the appropriate encryption key before you could
send mail.


The cryptography mailing list

Re: [Cryptography] P=NP on TV

2013-10-09 Thread Ray Dillinger
On 10/07/2013 05:28 PM, David Johnston wrote:

 We are led to believe that if it is shown that P = NP, we suddenly have a 
 break for all sorts of algorithms.
 So if P really does = NP, we can just assume P = NP and the breaks will make 
 themselves evident. They do not. Hence P != NP.

As I see it, it's still possible.  Proving that a solution exists does
not necessarily show you what the solution is or how to find it.  And
just because a solution is subexponential is no reason a priori to
suspect that it's cheaper than some known exponential solution for
any useful range of values.

So, to me, this is an example of TV getting it wrong.  If someone
ever proves P=NP, I expect that there will be thunderous excitement
in the math community, leaping hopes in the hearts of investors and
technologists, and then very careful explanations by the few people
who really understand the proof that it doesn't mean we can actually
do anything we couldn't do before.

The cryptography mailing list

Re: [Cryptography] Sha3

2013-10-07 Thread Ray Dillinger
On 10/04/2013 07:38 AM, Jerry Leichter wrote:
 On Oct 1, 2013, at 5:34 AM, Ray Dillinger wrote:
 What I don't understand here is why the process of selecting a standard 
 algorithm for cryptographic primitives is so highly focused on speed. 

 If you're going to choose a single standard cryptographic algorithm, you have 
 to consider all the places it will be used.  ...

 It is worth noting that NSA seems to produce suites of algorithms optimized 
 for particular uses and targeted for different levels of security.  Maybe 
 it's time for a similar approach in public standards.

I believe you are right about this.  The problem with AES (etc) really  is that 
were trying to find *ONE* cryptographic primitive for use across a very wide 
range of
clients, many of which it is inappropriate for (too light for first-class or 
protection of data, too heavy for transient realtime signals on embedded 

I probably care less than most people about the low-power devices dealing with
transient realtime signals, and more about long-term data protection than most
people.  So, yeah, I'm annoyed that the standard algorithm is insufficient to
just *STOMP* the problem and instead requires occasional replacement, when 
is well within my CPU capabilities, power budget, and timing requirements.  But
somebody else is probably annoyed that people want them to support AES when they
were barely able to do WEP on their tiny power budget fast enough to be 

These are problems that were never going to have a common solution.

The cryptography mailing list

Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?

2013-10-07 Thread Ray Dillinger
Is it just me, or does the government really have absolutely no one
with any sense of irony?  Nor, increasingly, anyone with a sense of

I have to ask, because after directly suborning the cyber security
of most of the world including the USA, and destroying the credibility
of just about every agency who could otherwise help maintain it, the
NSA kicked off National Cyber Security Awareness Month on the first
of October this year.

[Slow Clap]  Ten out of ten for audacity, wouldn't you say?

The cryptography mailing list

[Cryptography] Politics - probably off topic here.

2013-10-07 Thread Ray Dillinger

 Original message 
From: Phillip Hallam-Baker 
Date: 10/06/2013  08:18  (GMT-08:00) 
To: James A. Donald 
Subject: Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: 
NIST about to weaken SHA3? 
Phillip Hallam-Baker wrote:

But when I see politicians passing laws to stop people voting, judges deciding 
that the votes in a Presidential election cannot be counted and all the other 
right wing antics taking place in the US at the moment, the risk of a right 
wing fascist coup has to be taken seriously. 

Well, yes.  That is my main concern as well.  The recent tactics of the 
Republican party are more an attack on the process of constitutional government 
than ordinary tactics of the sort that make sense within the process.  This 
sort of issue used to get solved with simple and relatively harmless horse 
trading and pork barrel deals where the minority members would sell their 
votes for something to bring back to their constituents. Shutting down the 
whole system is mad - and horribly damaging - compared to just taking the 
chance to bring home some pork.

And this concerns me more than it otherwise might because of the recent 
economic trouble we've been having.  When economies go bad is when fascist 
parties tend to come to power. Or more to the point in our case , when existing 
parties veer further in a fascist direction.  I'm seeing the golden dawn party 
in Greece gaining popularity that it could never have gotten when its economy 
was in better shape.  I see the recent elections in a few euro zone nations 
giving seats to far-right parties, and I just can't help starting to worry.

Most of the history I'm aware of regarding genocides and the emergence of 
dictatorships is that everywhere from Rwanda to Germany to Haiti,  they have 
always followed close on the heels of a particularly severe and long sustained 
economic crisis. 

I don't want the country I live in to become another example. And I don't want 
the world I live on to suffer through more examples. 

The cryptography mailing list

Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?

2013-10-07 Thread Ray Dillinger

 Original message 
From: Jerry Leichter 
Date: 10/06/2013  15:35  (GMT-08:00) 
To: John Kelsey 
Cc: List,Christoph 
Anton Mitterer,james hughes,Dirk-Willem van Gulik 
Subject: Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was:
NIST about to weaken SHA3? 
On Oct 5, 2013, at 9:29 PM, John Kelsey wrote:
  Really, you are talking more about the ability to *remove* algorithms.  We 
still have stuff using MD5 and RC4 (and we'll probably have stuff using dual ec 
drbg years from now) because while our standards have lots of options and it's 
usually easy to add new ones, it's very hard to take any away.

Can we do anything about that? If the protocol allows correction (particularly 
remote or automated correction) of an entity using a weak crypto primitive, 
that opens up a whole new set of attacks on strong primitives.

We'd like the answer to be that people will decline to communicate with you if 
you use a weak system,  but honestly when was the last time you had that degree 
of choice in from whom you get exactly the content and services you need?

Can we even make renegotiating the cipher suite inconveniently long or heavy so 
defaulting weak becomes progressively more costly as more people default 
strong? That opens up denial of service attacks, and besides it makes it 
painful to be the first to default strong.

Can a check for a revoked signature for the cipher's security help? That makes 
the CA into a point of control.

Anybody got a practical idea?

The cryptography mailing list

Re: [Cryptography] AES-256- More NIST-y? paranoia

2013-10-05 Thread Ray Dillinger

On 10/03/2013 06:59 PM, Watson Ladd wrote:

On Thu, Oct 3, 2013 at 3:25 PM,  wrote:

On Oct 3, 2013, at 12:21 PM, Jerry  wrote:

As *practical attacks today*, these are of no interest - related key

attacks only apply in rather unrealistic scenarios, even a 2^119 strength
is way beyond any realistic attack, and no one would use a reduced-round
version of AES-256.

Expanding a bit on what I said:  Ideally, you'd like a cryptographic
algorithm let you build a pair of black boxes.  I put my data and a key
into my black box, send you the output; you put the received data and the
same key (or a paired key) into your black box; and out comes the data I
sent you, fully secure and authenticated.  Unfortunately, we have no clue
how to build such black boxes.  Even if the black boxes implement just the
secrecy transformation for a stream of blocks (i.e., they are symmetric
block ciphers), if there's a related key attack, I'm in danger if I haven't
chosen my keys carefully enough.

So, it seems that instead of AES256(key) the cipher in practice should be

Is it not the case that (assuming SHA256 is not broken) this defines a cipher
effectively immune to the related-key attack?


The cryptography mailing list

Re: [Cryptography] encoding formats should not be committee'ised

2013-10-05 Thread Ray Dillinger

On 10/04/2013 01:23 AM, James A. Donald wrote:

On 2013-10-04 09:33, Phillip Hallam-Baker wrote:

The design of WSDL and SOAP is entirely due to the need to impedance match COM 
to HTTP.

That is fairly horrifying, as COM was designed for a single threaded 
environment, and becomes and incomprehensible and extraordinarily inefficient 
security hole
in a multi threaded environment.

Well, yes, as a matter of fact DCOM was always incomprehensible
and extraordinarily inefficient.  However, it wasn't so much of
a security hole in the remotely crashable bug sense.  It made
session management into something of a difficult problem though.

The cryptography mailing list

Re: [Cryptography] AES-256- More NIST-y? paranoia

2013-10-03 Thread Ray Dillinger

On 10/02/2013 02:13 PM, Brian Gladman wrote:

The NIST specification only eliminated Rijndael options - none of the
Rijndael options included in AES were changed in any way by NIST.

Leaving aside the question of whether anyone weakened it, is it
true that AES-256 provides comparable security to AES-128?


The cryptography mailing list

Re: [Cryptography] Sha3

2013-10-01 Thread Ray Dillinger
What I don't understand here is why the process of selecting a standard 
algorithm for cryptographic primitives is so highly focused on speed. 

We have machines that are fast enough now that while speed isn't a non issue, 
it is no longer nearly as important as the process is giving it precedence for. 

Our biggest problem now is security,  not speed. I believe that it's a bit 
silly to aim for a minimum acceptable security achievable within the context of 
speed while experience shows that each new class of attacks is usually first 
seen against some limited form of the cipher or found to be effective only if 
the cipher is not carried out to a longer process.  

 Original message 
From: John Kelsey 
Date: 09/30/2013  17:24  (GMT-08:00) 
To: List 
Subject: [Cryptography] Sha3 
If you want to understand what's going on wrt SHA3, you might want to look at 
the nist website, where we have all the slide presentations we have been giving 
over the last six months detailing our plans.  There is a lively discussion 
going on at the hash forum on the topic.  

This doesn't make as good a story as the new sha3 being some hell spawn cooked 
up in a basement at Fort Meade, but it does have the advantage that it has some 
connection to reality.

You might also want to look at what the Keccak designers said about what the 
capacities should be, to us (they put their slides up) and later to various 
crypto conferences.  

Or not.  

The cryptography mailing list

The cryptography mailing list

Re: [Cryptography] Sha3

2013-10-01 Thread Ray Dillinger
Okay, I didn't express myself very well the first time I tried to say this.   
But as I see it,  we're still basing the design of crypto algorithms on 
considerations that had the importance we're treating them as having about 
twelve years ago. 

To make an analogy, it's like making tires when you need to have a ten thousand 
mile warranty.  When rubber is terribly expensive and the cars are fairly slow, 
 you make a tire that probably won't be good for twelve thousand miles. But 
it's now years later.  Rubber has gotten cheap and the cars are moving a lot 
faster and the cost of repairing or replacing crashed vehicles is now 
dominating the cost of rubber. Even if tire failure accounts for only a small 
fraction of that cost,  why shouldn't we be a lot more conservative in the 
design of our tires? A little more rubber is cheap and it would be nice to know 
that the tires will be okay even if the road turns out to be gravel. 

This is where I see crypto designers.  Compute power is cheaper than it's ever 
been but we're still treating it as though its importance hasn't changed. More 
is riding on the cost of failures and we've seen how failures tend to happen.  
Most of the attacks we've seen wouldn't have worked on the same ciphers if the 
ciphers had been implemented in a more conservative way.   A few more rounds of 
a block cipher or a wider hidden state for a PRNG, or longer RSA keys,  even 
though we didn't know at the time what we were protecting from, would have kept 
most of these things safe for years after the attacks or improved factoring 
methods were discovered.   

Engineering is about achieving the desired results using a minimal amount of 
resources.  When compute power was precious that meant minimizing compute 
power. But the cost now is mostly in redeploying and upgrading extant 
infrastructure.  And in a lot of cases we're having to do that because the 
crypto is now seen to be too weak.  When we try to minimize our use of 
resources,  we need to value them accurately. 

To me that means making systems that won't need to be replaced as often.  And 
just committing more of the increasingly cheap resource of compute power would 
have achieved that given most of the breaks we've seen in the past few years. 

To return to our road safety metaphor,  we're now asking ourselves if we're 
still confident in that ten thousand mile warranty now that we've discovered 
that the company that puts up road signs has also been contaminating our rubber 
formula, sneakily cutting brake lines,  and scattering nails on the road. Damn, 
it's enough to make you wish you'd overdesigned, isn't it?

 Original message 
From: John Kelsey 
Date: 09/30/2013  17:24  (GMT-08:00) 
To: List 
Subject: [Cryptography] Sha3 
If you want to understand what's going on wrt SHA3, you might want to look at 
the nist website, where we have all the slide presentations we have been giving 
over the last six months detailing our plans.  There is a lively discussion 
going on at the hash forum on the topic.  

This doesn't make as good a story as the new sha3 being some hell spawn cooked 
up in a basement at Fort Meade, but it does have the advantage that it has some 
connection to reality.

You might also want to look at what the Keccak designers said about what the 
capacities should be, to us (they put their slides up) and later to various 
crypto conferences.  

Or not.  

The cryptography mailing list

The cryptography mailing list

Re: [Cryptography] RSA recommends against use of its own products.

2013-09-21 Thread Ray Dillinger

*1 Anyone who attempts to generate random numbers by
 deterministic means is, of course, living in a
 state of sin. -- John Von Neumann

That said, it seems that most of these attacks on Pseudorandom
generators some of which are deliberately flawed, can be ameliorated
somewhat by using a known-good (if slow) Pseudorandom generator.

If we were to take the compromised products, rip out the PRNG's,
and replace them with Blum-Blum-Shub generators, we would have
products that work more slowly -- spending something like an
order of magnitude more time on the generation of Pseudorandom
bits -- but the security of those bits would be subject to an
actual mathematical proof that prediction of the next really is
at least equal in difficulty to a known-size factoring problem.
Factoring problems apparently aren't as hard as we used to think
but they *are* still pretty darn hard.

Slow or not, I think we do need to have at least one option
available in most PRNG-using systems which comes with a
mathematical proof that prediction is GUARANTEED to be hard.
Otherwise it's too easy for people and businesses to be caught
absolutely flatfooted and have no recourse when a flawed PRNG
is discovered or a trust issue requires them to do something
heroic in order to convince customers that the customers' data
can actually be safe.

We've been basing our notion of security on the idea that others
don't know something we don't know -- which is sort of nebulous
on its face and of course can never be provable. We can't really
change that until/unless we can say something definite about
P=NP, but we're a lot more sure that nobody else has anything
definite to say about P=NP than we are about most crypto

Do we know of anything faster than BBS that comes with a real
mathematical proof that prediction is at least as hard as

The cryptography mailing list

Re: [Cryptography] A lot to learn from Business Records FISA NSA Review

2013-09-19 Thread Ray Dillinger

On 09/16/2013 07:58 AM, Perry E. Metzger wrote:

Well, we do know they created things like the (not very usable)
seLinux MAC (Multilevel Access Control) system, so clearly they do
some hacking on security infrastructure.

SeLinux seems to be targeted mostly at organizational security,
whereas the primary need these days is not organizational, but

That is to say, we don't in practice see many situations where
different levels and departments of an organization have complex
and different rules for how and whether they can access each
other's information and complex requirements for audit trails.

What we see is simpler; we see systems used by people who have
more or less uniform requirements and don't much need routine
auditing, except for one or two administrators.

More useful than the complexity of SeLinux would be a relatively
simple system in which ordinary Unix file permissions were
cryptographically enforced.  If for example read permissions on
a file are exclusive to some user or some group, then that file
should be encrypted so that no one else, even if the bytes are
accessible to them by some means, should be able to make sense
of it, and the configuration options should include not storing
the key to it anywhere in the system -- let the user plug a
USB stick in to give the key for his session, and let the user
remove it to take that key away again whenever he's not using it,
rather than leave it around on the hard drive somewhere potentially
to be accessed by someone else at some other time.

We have spent years learning to protect the operating system from
damage by casual mistakes and even from most actual attacks,
because for years control of the computer itself was the only
notable asset that needed to be protected.  It is still true that
control of the computer is always at least as valuable as
everything else that it could be used to compromise, but with
unencrypted files it can compromise far too much.  And the value
of what is stored in individual accounts has gotten far too high
to *NOT* give protecting them at least as much thought as
protecting root's access rights. Photographs, banking records,
schedules, archived mail going back for years, browser histories,
wallets that contain many other keys, etc, etc.  This is far
different from old days when what was on a user's account
was basically a few programs the user used and some text or
code that the user had written.  We need to catch up.


The cryptography mailing list

Re: [Cryptography] Impossible trapdoor systems (was Re: Opening Discussion: Speculation on BULLRUN)

2013-09-12 Thread Ray Dillinger

On 09/08/2013 11:49 AM, Perry E. Metzger wrote:

That said, your hypothetical seems much like imagine that you can
float by the power of your mind alone. The construction of such a
cipher with a single master key that operates just like any other key
seems nearly impossible, and that should be obvious.

True.  A universal key that uses the same decryption operation as
a normal key is clearly stupid.

I guess the thing I was thinking of is that the attacker knows
a method that allows him to decrypt anything if he knows the IV,
but cannot recover the key used to encrypt it.

Which is of course a public-key system, where the decryption
method is the private key and the IV is the public key.
The thing I was thinking of as a key functions as a nonce
or subkey which allows people unrelated to the private key
holder to communicate semi-privately by shared secret, but
the private key is a backdoor on their communication.

Duh. Sorry, just wasn't thinking of the right parallel mapping
of what I described. For the cipher itself to function as a key
sort of escaped my attention.

Sorry to waste time.


The cryptography mailing list

Re: [Cryptography] Suite B after today's news

2013-09-08 Thread Ray Dillinger

On 09/05/2013 07:00 PM, Jon Callas wrote:

I don't think they're actively bad, though. For the purpose they were created 
for --
parallelizable authenticatedencryption -- it serves its purpose. You can have a
decent implementor implement them right in hardware and walk away.

Given some of the things in the Snowden files, I think it has become the case
that one ought not trust any mass-produced crypto hardware.  It is clearly on
the agenda of the NSA to weaken the communications infrastructure of American
and other business, specifically at the level of chip manufacturers.  And
chips are too much of a black-box for anyone to easily inspect and too much
subject to IP/Copyright issues for anyone who does to talk much about what
they find.  Seriously; microplaning, micrography, analysis, and then you get
sued if you talk about what you find?  It's a losing game.

Given good open-source software, an FPGA implementation would provide greater
assurance of security. An FPGA burn-in rig can be built by hand if necessary,
or at the very least manufactured in a way that is subject to visual inspection
(ie, on a one-layer circuit board with dead-simple 7400-series logic chips).
It would be a bit of a throwback these days, but we're deep into whom-can-you-
trust territory at this point and going for lower tech is worth it if it means
tech that you can still inspect and verify.


The cryptography mailing list

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-08 Thread Ray Dillinger

On 09/06/2013 05:58 PM, Jon Callas wrote:

We know as a mathematical theorem that a block cipher with a back
door *is* a public-key system. It is a very, very, very valuable
thing, and suggests other mathematical secrets about hitherto
unknown ways to make fast, secure public key systems.

I've seen this assertion several times in this thread, but I cannot
help thinking that it depends on what *kind* of backdoor you're
talking about, because there are some cases in which as a crypto
amateur I simply cannot see how the construction of an asymmetric
cipher could be accomplished.

As an example of a backdoor that doesn't obviously permit an
asymmetric-cipher construction, consider a broken cipher that
has 128-bit symmetric keys; but one of these keys (which one
depends on an IV in some non-obvious way that's known to the
attacker) can be used to decrypt any message regardless of the
key used to encrypt it.  However, it is not a valid encryption
key; no matter what you encrypt with it you get the same

There's a second key (also known to the attacker, given the IV)
which is also an invalid key; it has the property that no
matter what you encrypt or decrypt, you get the same result
(a sort of hash on the IV).

How would someone construct an asymmetric cipher from this?
Or is there some mathematical reason why such a beast as the
hypothetical broken cipher I describe, could not exist?


The cryptography mailing list

Re: [Cryptography] Why prefer symmetric crypto over public key crypto?

2013-09-08 Thread Ray Dillinger

On 09/07/2013 07:51 PM, John Kelsey wrote:

Pairwise shared secrets are just about the only thing that scales
worse than public key distribution by way of PGP key fingerprints on
business cards.  
If we want secure crypto that can be used by everyone, with minimal
trust, public key is the only way to do it.

One pretty sensible thing to do is to remember keys established in
previous sessions, and use those combined with the next session.

You've answered your own conundrum!

Of course the idea of remembering keys established in previous
sessions and using them combined with keys negotiated in the next
session is a scalable way of establishing and updating pairwise
shared secrets.

In fact I'd say it's a very good idea.  One can use a distributed
public key (infrastructure fraught with peril and mismanagement)
for introductions, and thereafter communicate using a pairwise
shared secret key (locally managed) which is updated every time
you interact, providing increasing security against anyone who
hasn't monitored and retained *ALL* previous communications. In
order to get at your stash of shared secret keys Eve and Mallory
have to mount an attack on your particular individual machine,
which sort of defeats the trawl everything by sabotaging vital
infrastructure at crucial points model that they're trying to

One thing that weakens the threat model (so far) is that storage
is not yet so cheap that Eve can store *EVERYTHING*. If Eve has
to break all previous sessions before she can hand your current
key to Mallory, first her work factor is drastically increased,
second she has to have all those previous sessions stored, and
third, if Alice and Bob have ever managed even one secure exchange
or one exchange that's off the network she controls (say by local
bluetooth link)she fails. Fourth, even if she *can* store everything
and the trawl *has* picked up every session, she still has to guess
*which* of her squintillion stored encrypted sessions were part
of which stream of communications before she knows which ones
she has to break.


The cryptography mailing list

Re: [Cryptography] MITM source patching [was Schneier got spooked]

2013-09-08 Thread Ray Dillinger

On 09/08/2013 05:28 AM, Phillip Hallam-Baker wrote:

every code update to the repository should be signed and
recorded in an append only log and the log should be public and enable any
party to audit the set of updates at any time.

This would be 'Code Transparency'.

Problem is we would need to modify GIT to implement.

Why is that a problem?  GIT is open-source.  I think even *I* might be
good enough to patch that.


The cryptography mailing list

Re: [Cryptography] Suite B after today's news

2013-09-08 Thread Ray Dillinger

On 09/08/2013 10:13 AM, Thor Lancelot Simon wrote:

On Sat, Sep 07, 2013 at 07:19:09PM -0700, Ray Dillinger wrote:

Given good open-source software, an FPGA implementation would provide greater
assurance of security.

How sure are you that an FPGA would actually be faster than you can already
achieve in software?


Depends on the operation.  If it's linear, somewhat certain.  If it's
parallizable or streamable, then very certain indeed.

But that's not even the main point.  It's the 'assurance of security' part
that's important, not the speed.  After you've burned something into an
FPGA (by toggle board if necessary) you can trust that FPGA to run the same
algorithm unmodified unless someone has swapped out the physical device.

Given the insecurity of most net-attached operating systems, the same is
simply not true of most software.  Given the insecurity of chip fabs and
their management, the same is not true of special-purpose ASICs.


The cryptography mailing list

Re: [Cryptography] [cryptography] Random number generation influenced, HW RNG

2013-09-08 Thread Ray Dillinger

On 09/08/2013 04:27 AM, Eugen Leitl wrote:

On 2013-09-08 3:48 AM, David Johnston wrote:

Claiming the NSA colluded with intel to backdoor RdRand is also to
accuse me personally of having colluded with the NSA in producing a
subverted design. I did not.

Well, since you personally did this, would you care to explain the
very strange design decision to whiten the numbers on chip, and not
provide direct access to the raw unwhitened output.

Y'know what?  Nobody has to accuse anyone of anything.  The result,
no matter how it came about, is that we have a chip whose output
cannot be checked.  That isn't as good as a chip whose output can
be checked.

A well-described physical process does in fact usually have some
off-white characteristics (bias, normal distribution, etc). Being
able to see those characteristics means being able to verify that
the process is as described.  Being able to see also the whitened
output means being able to verify that the whitening is working

OTOH, it's going to be more expensive due to the additional pins of
output required, or not as good because whitening will have to be
provided in separate hardware.

The cryptography mailing list

Re: [Cryptography] Bruce Schneier has gotten seriously spooked

2013-09-07 Thread Ray Dillinger

On 09/06/2013 01:25 PM, Jerry Leichter wrote:

A response he wrote as part of a discussion at

Q: Could the NSA be intercepting downloads of open-source encryption software and 
silently replacing these with their own versions?

A: (Schneier) Yes, I believe so.
 -- Jerry

Here is another interesting comment, on the same discussion.

Schneier states of discrete logs over ECC: I no longer trust the constants.
I believe the NSA has manipulated them through their relationships with 

Is he referring to the standard set of ECC curves in use?  Is it possible
to select ECC curves specifically so that there's a backdoor in cryptography
based on those curves?

I know that hardly anybody using ECC bothers to find their own curve; they
tend to use the standard ones because finding their own involves counting all
the integral points and would be sort of compute expensive, in addition to
being involved and possibly error prone if there's a flaw in the implementation.

But are the standard ECC curves really secure? Schneier sounds like he's got
some innovative math in his next paper if he thinks he can show that they


The cryptography mailing list

[Cryptography] Three kinds of hash: Two are still under ITAR.

2013-09-03 Thread Ray Dillinger

On 09/03/2013 09:54 AM, wrote:

--Alexander Kilmov wrote:

--David Mercer wrote:

2) Is anyone aware of ITAR changes for SHA hashes in recent years
that require more than the requisite notification email to NSA for
download URL and authorship information? Figuring this one out last
time around took ltttss of reading.

I used to believe that hashing (unlike encryption) was not considered

If I recall the most recent revision, the above requirement is true
for keyed hashes whether they are signatures with public-key crypto
or secret hashes with private-key crypto) but not for fingerprint
or unkeyed hashes like FIPS or SHA-XXX.

The distinction among the three types:

Signature hashes:  Alice produces a signature hash using her
private key.  Because her public key is common knowledge, everybody
can tell that Alice (or at least someone with her private key)
really did sign it.

Secret hashes:  MIB or some similar group share knowledge of a
secret key.  A, a member of the group, produces a secret hash
using that key, and when they check, every member from Bea to Zed
knows know that some member of the organization (or at least
someone who has the secret key) did sign it. But even if the
message and hash are public or in an insecure channel like email,
nobody who doesn't have the key can prove a thing about the
signer. Or at least, not from the signature itself.  Server logs
and security video surveillence of public terminals etc, are
an entirely different thing. A would be worried about those
if she had an official identity for someone to find.

Fingerprint hashes:  Anybody can apply a fingerprint hash to
something, and it proves nothing about who signed it because
the hash is completely public knowledge and has no particular
key. Anyone who applies a fingerprint hash to something will get
exactly the same hash code for the same thing. The point of a
fingerprint hash is that it is a fixed-length probably-unique
identifier that can be checked in constant time.  If the
fingerprint of two documents are not equal, the documents are
guaranteed to be dissimilar.  If the documents are dissimilar,
the signatures are *almost* guaranteed to be dissimilar.  This
is very useful for looking up documents in a hash table or
tree, for example, using the fingerprint hash as a key.
Usually when cryptographers use the word hash they are
talking about a fingerprint hash.


The cryptography mailing list

Re: [Cryptography] Functional specification for email client?

2013-09-01 Thread Ray Dillinger

On 08/31/2013 02:53 PM, John Kelsey wrote:

I think it makes sense to separate out the user-level view of what happens.

True.  I shouldn't have muddied up user-side view with notes about
packet forwarding, mixing, cover traffic, and domain lookup, etc.
Some users (I think) will want to know that much in general terms,
in order to have some basis to evaluate/understand the security
promises, but it's not part of the interface. Only the serious crypto
wonks will want to know in more detail.

{note: how strange! my spell checker thinks crypto is a typo, but
has no problem with wonks!}

If something arrives in my inbox with a from address of,
then I need to know that this means that's who it came from.  If I mail
something to, then I need to know that only the owner
of that address will be able to read it.

As I consider it, I'm thinking even that promise needs to be amended
to include the possibility of leaking from the recipient.  For example
email forwarding, unencrypted mail archives found by hackers, etc.

My intuition is that binding the security promises to email addresses
instead of identities is the right way to proceed.  I think this is
something most people can understand, and more importantly it's
somethingwe can do with existing technology and no One True Name
Authority In The Sky handing out certs.

Eggs Ackley.  I believe every user in the world is familiar at this point
with the idea of an email alias, and that the concept maps reasonably
well to holder of a key for crypto purposes.  To promise any more
than that about identity requires centralized infrastructure that
cannot really exist in a pure P2P system.

One side issue here is that this system's email address space needs
to somehow coexist with the big wide internet's address space.  It
will really suck if someone else can get my gmail address n the
secure system, but it will also be confusing if my inbox has a
random assortment of secure and insecure emails, and I have to do
some extra step to know which is which.

If you want to gateway secure mail into the same bucket with
insecure mail, I guess you can do that; I would far rather have
separate instances of mail clients that do not mix types. eg,
this is Icedove/P2P, and this is Icedove/SMTP, and they are not
expected to be able to interchange messages without some gateway.

That said, all you need to gateway secure mail into an SMTP system
is easy to construct.  Consider if the peer mail system has an
address structure like name**domain:

You have a machine with DNS/SMTP address like secure.peermail.
com to reserve the name and provide bounce messages that prompt
people to get a peer mail client and send a message in that
client to name**domain for whatever address someone tried to
reply to. Mail imported from the peer mail client with a
name*domain mail format, could show in an SMTP client as

Alternatively, or additionally, you could have a machine with
an address like that actually does
protocol translation and forwards SMTP mail onto the secure
network and vice versa, and allow peer mail users to choose
which machine handles their SMTP-translated address. But
this has the same problems as Lavabit and Silent Circle,
which recently shut down under duress.

Dual-protocol mail clients could use name**domain on the
peer network directly.  Mail imported from the SMTP network
on a dual-protocol client or on a peer mail client could
appear as**INSECURE-SMTP or similar, and on
the dual-protocol client a direct reply would prompt use of
the insecure protocol after a warning prompt.  On a secure-
protocol client it would simply prompt the user to use an
insecure mail client, same as the bounce message on the
other side.

I see the Big Wide Internet's address space as a simple tool to
implement it, not as a conflicting thing that needs reconciled.

The domain lookup as I envision it would associate mail peer email
addresses with a tuple of IPv6 address and public key.  The public
keys are stable; the IPv6 address may appear and disappear (and may
be different each time) as the user connects and disconnects from the
system.  The presumption is that the mail peer daemon on the local
machine sends a routing update message when starting up, and
possibly another (deleting routing information) in an orderly

As stated earlier, the system makes no effort to actively hide the
machine where an email address is located.  It could be a machine
designated to receive and keep mail for that address until it gets
a private address update that tells it where to send the messages
but which is not propagated; even in that case, the designated
maildrop machine if not controlled by the holder of the address
cannot be considered to hold any real secrets.

Routing update messages propagate across the network of relevant domain
servers, which check the sig on the update against the 

Re: [Cryptography] NSA and cryptanalysis

2013-08-31 Thread Ray Dillinger

On 08/30/2013 08:10 PM, Aaron Zauner wrote:

I read that WP report too. IMHO this can only be related to RSA (factorization, 
side-channel attacks).

I have been hearing rumors lately that factoring may not in fact be as hard
as we have heretofore supposed.  Algorithmic advances keep eating into RSA
keys, as fast as hardware advances do.  A breakthrough allowing most RSA keys
to be factored could be just one or two more jumps of algorithmic leverage
away (from academics; possibly not from the NSA).  It could also be the case
that special-purpose ASICs that accelerate the process substantially may
have been designed and built.

We know about Shor's algorithm for factoring in NlogN time.  It requires a
quantum computer to run though.  We have heard rumors of quantum computers
being built, and I recall a group of academics who actually built one nearly
eight years ago.

That seems to be the sort of thing that would attract attention from a lot
of three-letter agencies, and efforts to scale it up would be intensely
supported with all the resources and brainpower that such an organization
could bring to bear.  How far have they come in eight years?  It is both
interesting and peculiar that so little news of quantum computing has been
published since.


The cryptography mailing list

[Cryptography] Functional specification for email client?

2013-08-30 Thread Ray Dillinger


User-side spec:

1.  An email address is a short string freely chosen by the email user.
It is subject to the constraint that it must not match anyone else's
email address, but may (and should) be pronounceable in ordinary language
and writable with the same character set that the user uses for writing.
They require extension with a domain as current email addresses do,
but not a domain name in the IETF sense; just a chosen disambiguator
(from a finite set of a million or so) to make name collisions less of
a problem.

2.  An email user may have more than one email address.  In fact s/he can
make up more email addresses at any time.  He or she may choose to associate
a tagline -- name, handle, slogan or whatever -- with the address.

3.  When an email user gets an email, s/he is absolutely sure that it comes
from the person who holds the email address listed in its from line.
S/he may or may not have any clue who that person is.  S/he is also
sure that no one else has seen the contents of the email.  The tagline
and email address are listed in the from: line.

4.  A user has an address book. The address book can be viewed as a whole or
as seen by just one of the user's email addresses.  IOW, if you have an
email address that you use for your secret society and a different email
address that you use for your job, you can choose to be one or the other
and your address book will reflect only the contacts that you have seen
from that address or have been visible to under that address.

5.  A mail client observes all email addresses that go through it.  When a
user receives mail from someone who has not directly sent them mail before,
the client opens a visible entry in the address book and makes available
a record of previous less-direct contacts with that address, for example
from posts to mailing lists, from CC: lists on emails, etc.  The client
also makes visible a list of possible contact sources; places where the
correspondent may have seen the address s/he's writing to.  However, often
enough, especially with cases where it's a scribbled on a napkin address,
the client just won't know.

6.  When a user sends mail, s/he knows that no one other than the holder of
the address/es s/he's sending it to will see the body of the mail, and also
that the recipient will be able to verify absolutely that the mail did in
fact come from the holder of the user's address.

7.  Routing information once obtained for a given domain is maintained locally.
This means routing information for each email address is public knowledge,
but also means that no one can tell from your address queries who 
your correspondents are more precisely than knowing which domains they are 
This also means that other users may obtain routing information for that
domain from you. You can update your routing information (ie, set the system
to route messages for your address to the network location where you 
are) at any time, via a message propagated across all peers serving the 
of that address.  Also, your client keeps your addresses alive by 
sending out a message that is propagated across all server peers for that 
This happens at intervals you set (a few months to ten years) when you 
the email address.  If that interval goes by without a keep-alive or a 
information update, the servers will drop the address.

8.  Emails are mixed on your machine locally, then sent out onto the network.
The mixing means creating packets of a uniform size, planning a route for
each, encrypting them once for each 'hop' on the route, and sending them.
Routing is constrained to average less than ten 'hops'.  The packet size
should be selected so most text emails are one packet or less.  Larger 
will be sent as a set of packets and reassembled at destination.  Packets 
be released at a rate of one every few seconds; very large file attachments
may take days to send and are discouraged.

9.  Your machine, while connected, is collecting your email.  It is also in the
business of packet forwarding:  ie, it gets a packet, decrypts it, reads the
next hop, waits some random number of seconds, and sends it to the next hop.

10. Finally, your mail client will occasionally create one or more packets and
send them via some randomly selected route to another point on the network,
where they will be received and ignored.  It will do this just about as
often as it sends original content-bearing packets, and about five percent
as often as it forwards packets.  This generates 'cover traffic' equal to
about three quarters of the total network volume. Generation and receipt
of cover traffic is completely invisible to the user.

Re: [Cryptography] Functional specification for email client?

2013-08-30 Thread Ray Dillinger

On 08/30/2013 01:52 PM, Jonathan Thornburg wrote:

On Fri, 30 Aug 2013, Ray Dillinger wrote:

3.  When an email user gets an email, s/he is absolutely sure that it comes
 from the person who holds the email address listed in its from line.
 S/he may or may not have any clue who that person is.  S/he is also
 sure that no one else has seen the contents of the email.

This probably needs amending to deal with messages addressed to multiple
recipients (either cc:, bcc:, or simply multiple to: addresses).


More generally, I was hoping for feedback as to whether this is a design
useful to and usable by ordinary people.

It's fairly straightforwardly implementable as a fully distributed system,
given the notion that routing information includes public key.  The only
slightly tricky issue is maintaining the coherence of the per-domain
routing databases among mutually suspicious clients, and there are existing
techniques for that.

It's also compatible with current standards for email payloads, so existing
infrastructure can easily be adapted; in the protocol stack, it looks like
any other MTA.

It can also fairly easily gateway to SMTP, but is not dependent on it.


The cryptography mailing list

Re: [Cryptography] Good private email

2013-08-26 Thread Ray Dillinger

On 08/26/2013 04:12 AM, Richard Salz wrote:

 You need the client to be

able to generate a keypair, upload the public half, and pull down
(seamlessly) recipient public keys.  You need a server to store and
return those keys. You need an installed base to kickstart the network

Who has that?

I know who has that - in spades!

The bitcoin network is a public transaction record of bitcoin transfers.
The individual accounts are not quite fully anonymous to a determined
observer, but nothing we've discussed here would be more anonymous.

Anyway, a bitcoin client already generates key pairs, and every transaction
stores them in the database.  The database is distributed to all full node
clients, and kept (reasonably) secure using Nakamoto's proof-of-work protocol
for the byzantine-generals problem.  The maintainers of the database have a
vested (monetary) interest in keeping the database secure.

Anyway, each address is a relatively short high-entropy string (ECC
crypto) -- and each client already has an address book of public
addresses (public keys where people can be sent bitcoin payments --
or private messages) and accounts (private keys which represent
bitcoin that can be sent).  In addition, you can ask the client to
generate a new address (keypair) for you at any moment.  The private
key goes into your accounts as an account with zero balance (and no
message history) and a new public key for you goes into your addresses
as a place where you can receive payments (and messages).

There are smartphone clients that don't maintain the full database, but
which do maintain the address book, accounts, and address-generation bits
for you.  There are already solutions for transferring public keys
directly between smartphones via bluetooth, which is a convenient channel
outside the sphere of Internet eavesdropping.  And there is already
software that can preprint N business cards (with or without your name/etc
on them) that all have different addresses on them, so you can hand them
out to anyone whom you think may have a reason to send you money (or
messages), one address per person.

In practice, people need to key in an address for someone once if they
are handed a card.  Keying it is about the same difficulty as a VIN
number on an auto insurance form.  Subsequent new addresses for the same
person can be sent in a message encrypted, along with any bitcoin
transaction, and automatically replace the address you already have
associated with that account for your next payment (or message).  If
Alice doesn't have preprinted cards, she has her smartphone and it can
generate an address for her on demand -- She will have to read it off
her smartphone screen if she wants to scribble it on a napkin.

If we build further email infrastructure on top of this, A side effect of
this is that every user has a choice about whether or not s/he will accept
messages without payments.  You can require someone to make a bitcoin
payment to send you an email.  Even a tiny one-percent-of-a-penny payment
that is negligible between established correspondents or even on most email
lists would break a spammer.  Also, you can set your client to automatically
return the payment (when you read a message and don't mark it as spam) or
just leave it as a balance that you'll return when you reply.

In short, a private email client can be built directly on top of the
bitcoin network.  In practice, I think it would be useful mainly for
maintaining the distribution and updating of keys, rather than for
messages per se, because the amount of extra data you can send along
with a bitcoin transaction is quite small (3k?  I think?).  Anyway, it
couldn't handle file attachments etc.


The cryptography mailing list

Re: [Cryptography] Email and IM are ideal candidates for mix networks

2013-08-26 Thread Ray Dillinger

On 08/25/2013 03:28 PM, Perry E. Metzger wrote:

So, imagine that we have the situation described by part 1 (some
universal system for mapping name@domain type identifiers into keys
with reasonable trust) and part 2 (most users having some sort of
long lived $40 device attached to their home network to act as a
home server.)

My main issue with this proposal is that somebody identifiable is going
to manufacture these boxes.  Maybe several somebodies, but IMO, that's
an identifiable central point of control/failure.  If this is deployed,
what could an attacker gain by compromising the manufacturers, via sabotage,
component modification/substitution at a supplier's chip fab, or via
secret court order from a secret court operating according to a secret
interpretation of the law?


The cryptography mailing list

Re: [Cryptography] Email and IM are ideal candidates for mix networks

2013-08-26 Thread Ray Dillinger

On 08/25/2013 08:32 PM, Jerry Leichter wrote:

mail servers have gotten into trouble is when they've tried to provide
additional services - e.g., virus scanners, which then try to look
inside of complex formats like zip files.  This is exactly the kind
of thing you want to avoid - another part of the mission creep that
we tend to see in anything that runs on a general-purpose computer.

Absolutely agreed; the most reliable things are the least complex.

 That's 20th century thinking:  The computer is expensive, keep

it busy.  Twenty first century thinking should be:  The computer
is cheap - leave it alone to do its job securely.

My thinking is more like: The computer has a multitasking OS.  Whatever
else it needs to be doing will be in another process.  So you lose nothing
if you keep each process simple.  Or if it's a single-purpose box intended
to provide security; don't dilute its purpose.  Keep it simple enough that
even installations of it in the wild, after unknown handling and in all
possible configurations, can be unambiguously, easily, and exhaustively
tested so you know they're doing exactly what they should be and no more.

Realistically, it will be impossible to get little appliances like
this patched on a regular basis - how many people patch their WiFi
routers today? - so better to design on the assumption there won't
be any patches.

Also agreed; online patches are the number one distribution vector of
malware that such a device would need to be worried about. Firstly
because whoever can issue such a patch is a central point of control/
failure and can be coerced.  So send it out with an absolutely sealed


The cryptography mailing list

Re: [Cryptography] Good private email

2013-08-26 Thread Ray Dillinger

On 08/26/2013 10:39 AM, Jerry Leichter wrote:

On Aug 26, 2013, at 1:16 PM, Ray Dillinger wrote:

Even a tiny one-percent-of-a-penny payment
that is negligible between established correspondents or even on most email
lists would break a spammer.

This (and variants, like a direct proof-of-work requirement) has been proposed
time and again in the past.  It's never worked, and it can't work, because the
spammers don't use their own identities or infrastructure - they use botnets.
They don't care what it costs (in work or dollars or Bitcoins) to send their
message, because they aren't going to pay it - the machine they've taken over
is going to pay.

Possible, but Doubtful.  The bitcoin wallet is extraordinarily secure
as software goes. Once you've chosen a keyphrase, It NEVER gets saved in
decrypted form to the disk, and even in the client software, cannot be
decrypted except by explicit command and will not remain in memory for more
than a few seconds in decrypted form. Furthermore, the client software
does not invoke other programs (like Word or other scriptable attack
vectors) under any circumstances.  Furthermore any extensions like
clickable URLs in messages or javascript execution etc or other methods
by which external possibly non-secure applications could start up with
information from inside the client would be soundly rejected as
untrustworthy extensions.  People design for and demand an altogether
different level of security when you're talking about their own money,
and handle the complexities of key management with no difficulty.

In short, no possibly naive user could convince the developers to do
the stupid things that email clients do for coolness or convenience in
the context of a financial client.

If there were a vulnerability or exploit discovered that allowed a spammer
to take control of a bitcoin account, it would be regarded as a MAJOR
DISASTER by the community and prompt a fix within minutes, not hours
days or months as is the case with mere email clients.

Consider that *every* *last* *developer* stands to lose at least
thousands or tens of thousands of dollars of real, personally owned
money if confidence in the network falters.  In some cases literally
millions.  This is not some hypothetical loss to the company that
they can be ordered to do by some boss even though they think it's
a bad idea, nor some hobby that they can allow to fall by the wayside;
these people are deeply and very literally invested in the security
of the code, and flatly will refuse to do anything that might
compromise it.

If some company did issue a client with security holes, the usual
shrink-wrap not liable crap would be completely unacceptable, the
lawsuit exposure would be somewhere in the trillions of dollars,
and the legal costs to even try to defend a mealymouthed claim of
not liable because of our shrink wrap license from the resulting
firestorm would probably break the company.  There are *dozens*
of serious, litigous, investors who hold millions of dollars in
bitcoin these days, including, among others, the Winkelvoss
brothers who spent ten years or more pursuing their infamous
Facebook lawsuit.  Even if you win that legal fight you're going
to lose.

The fact that the client is also highly usable is an excellent example
of interface design.


The cryptography mailing list

Re: [Cryptography] PRISM PROOF Email

2013-08-25 Thread Ray Dillinger

On 08/22/2013 02:36 AM, Phillip Hallam-Baker wrote:

Thanks to Snowden we now have a new term of art 'Prism-Proof', i.e. a
security scheme that is proof against state interception. Having had

 an attack by the Iranians, I am not just worried about US interception.
 Chinese and Russian intercepts should also be a concern.

We have two end to end security solutions yet Snowden used neither. If
PGP and S/MIME are too hard to use for the likes of Snowden, they are
too hard to use. The problem Snowden faced was that even if he could
grok PGP, the people sending him emails probably couldn't.

Observation:  Silent Circle and Lavabit both ran encrypted email services.
Lavabit shut down a few days ago rather than become complicit in crimes
against the American People.  I would say that's about as close as you can
skate to We're facing a court order that we're not allowed to tell you
about.  Maybe even closer; we'll be forbidden to know whether anyone
prosecutes them for violating the presumed gag order.  Silent Circle shut
down soon after, saying, We always knew the USG would come after us.
Which perhaps a little less clearly indicates a court oder they can't talk
about, but that's certainly one interpretation.

Egypt, Oman, and India refused to allow Blackberry to operate with their
end-to-end encrypted devices.  In cases where Blackberry is now allowed to
operate in those jurisdictions it is not at all clear that they are not
doing so using compromised devices whose keys shared with those governments.

Chinese military teams spent so much effort hacking at gmail and facebook
accounts, in order to ferret out dissidents, that Google was eventually
forced to cease doing business in China, and now gmail and facebook both
have some end-to-end encrypted clients.

My point I guess is that we have some evidence that Governments across the
world are directly hostile to email privacy.  Therefore any centralized server,
CA, or company providing same may expect persecution, prosecution or subversion
depending on the jurisdiction.

And it can never, ever, not in a billion years, be clear to users which if
any of those centralized servers or companies are trustworthy.  Google now
implements some end-to-end encryption for gmail but we also know that google
is among those specifically mentioned as providing metadata access to the
US government.  The exact details of Blackberry's keys in Oman, UAE,  India
are now subject to largely unknown deals and settlements.

Therefore, IMO, any possible solution to email privacy, if it is to be trusted
at all, must be pure P2P with no centralized points of failure/control and no
specialized routers etc.  And it can have no built-in gateways to SMTP.  Sure,
someone will set one up, but there simply cannot be any dependence on SMTP or
the whole thing is borked before it begins.  It is time to simply walk away
from that flaming wreckage and consider how to do email properly. S/Mime and
PGP email-body encryption both fail to protect from traffic analysis because
of underlying dependence on SMTP.  Onion routing fails to protect due to timing

So I say you must design your easy-to-use client completely replacing the
protocol layer.  No additional effort to install because this is the only
protocol it handles.

The traditional approach to making a system intercept proof is to eliminate
the intermediaries. PGP attempts to eliminate the CA but it has the unfortunate
effect on scalability. Due to the Moore bound on a minimum diameter graph, it is
only possible to have large graphs with a small diameter if you have nodes of
high degree. If every PGP key signer signs ten other people then we have to 
key chains of 6 steps to support even a million users and nine to support a
global solution of a billion users.

 My solution is to combine my 'Omnibroker' proposal currently an internet 
draft and Ben Laurie's Certificate Transparency concept.

I would start from a design in which mail is a global distributed database, with
globs that can be decrypted by use of one or more of each user's set of keys, 
all globs have expiry dates after which they cease to exist.  Routing becomes a
nonissue because routing, like old USENET, is global.  Except instead of 
message ID's, we just use dates (because timestamps are too precise) and message
hashes (because message IDs contain too much originating information).

No certificate, no broker, no routing information unless the node that first 
about the new glob has been compromised.  Each message (decrypted glob) 
contains one or more replyable addresses (public keys).

If we need more 'scalability' we could set up channels discriminated by some
nine bit or so substring of the message hash, and require senders to solve 
until they get a hash with the right nine bits to put it in the desired 
Still no routing information as such. Now Eve can tell what channel/s a user is
listening to, but the user has 

Re: [Cryptography] Snowden fabricated digital keys to get access to NSA servers?

2013-06-29 Thread Ray Dillinger

On 06/28/2013 09:36 PM, Udhay Shankar N wrote:

On Sat, Jun 29, 2013 at 4:30 AM, John  wrote:

[John here.  Let's try some speculation about what this phrase,
fabricating digital keys, might mean.]

Perhaps something conceptually similar to PGP's Additional Decryption
Key [1]? If the infrastructure is in place for this, perhaps one might
be able to generate a key on demand, with the appropriate access

I read it to mean that the NSA is using some sort of defeatable
cryptography in its own communications with contractors, presumably
to enable internal snooping for purposes of monitoring contractors.
If a contractor then discovers this system, and manages to cryptanalyze
it (or somehow obtain a copy of the snooping software, though that's
not strictly necessary to cryptanalysis) to figure out the corresponding
method of how the snoopers from the NSA generate keys out of thin
air for it, then he might use that method himself to get access to
all the material that other contractors on that system are working

It would be a ridiculously stupid methodology for the NSA to manage
its security affairs this way, but if fabricated keys isn't a flat
out lie, then it's the only thing I can think of that makes sense.
And if it is a flat out lie, then lying to congress is fairly serious.
'Tho it wouldn't be the first time that's happened, either.

The cryptography mailing list

Computer health certificate plan indistinguishable from Denial Of Service attack.

2010-10-06 Thread Ray Dillinger
Microsoft is sending up a test balloon on a plan to 'quarantine' 
computers from accessing the Internet unless they produce a 'health
certificate'  to ensure that software patches are applied, a firewall
is installed and configured correctly, an antivirus program with current
signatures is running, and the machine is not currently infected with
known malware.

Apparently in a nod to the fact that on technical grounds this is
effectively impossible, the representative goes on to say 

Relevant legal frameworks would also be needed.

as though that would make lawbreakers stop spoofing it.  Existing 
malware already spoofs antivirus software to display current patches,
in order to prevent itself from being uninstalled.

It is hard to count the number of untestable and/or flat out wrong
assumptions built into this idea, and harder still to enumerate all the
ways it could go wrong.

The article is available at:


The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

English 19-year-old jailed for refusal to disclose decryption key

2010-10-06 Thread Ray Dillinger
a 19-year-old just got a 16-month jail sentence for his refusal to 
disclose the password that would have allowed investigators to see 
what was on his hard drive.  

I suppose that, if the authorities could not read his stuff 
without the key, it may mean that the software he was using may 
have had no links weaker than the encryption itself -- and that 
is extraordinarily unusual - an encouraging sign of progress in 
the field, if of mixed value in the current case.

Really serious data recovery tools can get data that's been 
erased and overwritten several times (secure deletion being quite
unexpectedly difficult), so if it's ever been in your filesystem
unencrypted, it's usually available to well-funded investigators 
without recourse to the key.  I find it astonishing that they 
would actually need his key to get it. 

Rampant speculation: do you suppose he was using a solid-state 
drive instead of a magnetic-media hard disk?


The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

RE: Has there been a change in US banking regulations recently?

2010-08-15 Thread Ray Dillinger
On Fri, 2010-08-13 at 14:55 -0500, wrote:

 Moore's law helped immensely here. In the last 5 years systems have gotten 
 about 8 times faster, reducing the processing cost of crypto a lot. 

 The big drawback is that those who want to follow NIST's recommendations 
 to migrate to 2048-bit keys will be returning to the 2005-era overhead. 
 Either way, that's back in line with the above stated 90-95% overhead. 
 Meaning, in Dan's words 2048 ain't happening. 

I'm under the impression that 2048 keys are now insecure mostly due 
to advances in factoring algorithms that make the attack and the
encryption effort closer to, but by no means identical to, scaling 
with the same function of key length.  This makes the asymmetric 
cipher have a lower ratio of attack cost to encryption cost at any given
key length, but larger key lengths still yield *much* higher ratios of 
attack cost to encryption cost.  

At 2048 bits, I think that with Moore's law over the next decade or two
dropping attack costs and encryption costs by the same factor, attack
costs should remain comfortably out of reach while encryption costs
return to current levels now practical for shorter keys. 

Of course, this reckons without the potential for unforseen advances 
in factoring or Quantum computing.

 There are some possibilities, my co-workers and I have discussed. For 
 purely internal systems TLS-PSK (RFC 4279) provides symmetric
 encryption through pre-shared keys which provides us with whitelisting
 as well as removing asymmetric crypto. 

That's probably a good idea. We've placed a lot of stock in public-
key systems because of some neat mathematical properties that seemed to 
conform to someone's needs for an online business model involving the
introduction of strangers who want to do business with each other.  But
if you can handle key distribution internally by walking down the hall
or mailing a CD-ROM preloaded with keys instead of by trusting the
network the keys are supposed to secure, you really don't need
Public-key crypto's neat mathematical properties.  


The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

About that Mighty Fortress... What's it look like?

2010-07-31 Thread Ray Dillinger

Assume, contra facto, that in some future iteration of PKI, it 
works, and works very well.  

What the heck does it look like?

At a guess  Anybody can create a key (or key pair).  They 
get one clearly marked private, which they're supposed to keep, 
and one clearly marked public, which they can give out to anybody
they want to correspond with. 

Gaurantors and certifying authorities can endorse the public key
for specific purposes relating to their particular application.
Your landlord can endorse your keycard to allow you to get into 
the apartment you rent, the state government can endorse your 
key when you get a contractor's license or private investigator's 
license or register a business to sell to consumers and pay taxes,

There are no certifying agencies other than interested parties 
and people who issue licenses/guarantees for specific reasons. 

You can use your private key to endorse somebody else's key 
to allow them to do some particular thing (you have to write a 
short note that says what) that involves you, or check someone 
else's key to see if it's one that you've endorsed.  If you've 
endorsed it, you get back the short note that you wrote, telling 
you what purpose you've endorsed it for. 

Anybody who's endorsed a key can prove that they've endorsed it 
by publishing their endorsement.  You can read and verify public 
endorsements using the public keys of the involved parties.

And you can revoke your endorsement of any particular key, at any
time, for any reason.  The action won't affect other endorsements
of the same key, nor other endorsements you've made.

Finally, you can use your private key to prepare a revocation, 
which can be held indefinitely in some backup storage, insurance
database, or safe-deposit box. If you ever lose your private key, 
you send the revocation and everybody who has endorsed your 
public key gets notified that it's no good anymore.

I think this model is simple enough to be understood by 
ordinary people.  It's also clear enough in its semantics to 
be implemented in a straightforward way.  Is it applicable 
to the things we want to use a PKI for?


The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

Re: Crypto dongles to secure online transactions

2009-11-25 Thread Ray Dillinger
On Fri, 2009-11-20 at 20:13 +1300, Peter Gutmann wrote:

 Because (apart from the reasons given above) with business use specifically
 you run into insurmountable PC - device communications problems.  Many
 companies who handle large financial transactions are also ones who, due to
 concern over legal liability, block all access to USB ports to prevent
 external data from finding its way onto their corporate networks (they are
 really, *really* concerned about this).  If you wanted this to work, you'd
 need to build a device with a small CMOS video sensor to read data from the
 browser via QR codes and return little more than a 4-6 digit code that the
 user can type in (a MAC of the transaction details or something).  It's
 feasible, but not quite what you were thinking of.

So the model of interaction is: 
Software displays transaction on the screen (in some
 predetermined form)
Device reads the screen, MACs the transaction, and 
 displays MAC to user
User enters MAC to confirm transaction
Transaction, with MAC, is submitted to user's bank.
Bank checks MAC to make sure it matches transaction
   and performs transaction if there's a match.

Malware that finds the user account details lying around 
on the hard drive cannot form valid MACs for the transactions
it wants to use those details for, so the user and the bank 
are protected from credit card harvesting by botnets. 
Malware that attempts to get a user authorization by displaying
a different transaction on the screen is foiled by not being 
able to MAC the transaction it's really trying to do.  etc.

But a four or six digit MAC isn't nearly enough. 

You see, there's still the problem of how you handle fraudulent 
transactions.  If the black hats start submitting transactions
with random MACs in the certain knowledge that one out of ten 
thousand four-digit MACs will be right, all that happens is 
that they have to invest some bandwidth when they want to drain
your account.  They will do it, because it's more profitable 
than sending spam.  

If there is some reasonable control like freezing an account 
after a thousand attempts to make fraudulent transactions or 
not accepting transaction requests within twenty seconds after 
an attempt to make a fraudulent transaction on the same account, 
then you have created an easy denial-of-service attack that can 
be used to deny a particular person access to his or her bank 
account at a particular time of the attacker's choosing.  

Denying someone access to their money makes them vulnerable at 
an unexpected time - they can't get a hotel room, they can't get 
a cab, they can't get a plane home, they can't buy gas for their 
car and get stranded somewhere, and they become easy pickings 
for physical crimes like assault, rape, theft of vehicle, etc. 
That's not acceptable.

In order to be effective the MAC has to make success so unlikely
that submitting a fraudulent transaction has a higher cost than 
its amortized benefit.  Since the botnets are stealing their 
electricity and bandwidth anyway, the absolute cost to black 
hats of submitting a fraudulent transaction is very very close 
to zero.  What we have to look at then is their opportunity cost.  

Consider the things a botted machine could do with a couple 
kilobytes of bandwidth and a couple milliseconds of compute time.  
It could send a spam or it could send a fraudulent transaction 
to a bank with a random MAC.  It will do whichever is considered 
most profitable by the operator of the botnet.  

Note: with spamming there's almost no chance of arrest.  Receiving
money via a fraudulent transaction submitted to a bank *MIGHT* be 
made more risky, so if that actually happens then there's an 
additional risk or cost associated with successful fraud attempts, 
which I don't account for here. But ignoring that because I don't 
know how to quantify it: 

In late 2008, ITwire estimated that 7.8 billion spam emails were 
generated per hour. (
Consumer reports estimates consumer losses due to phishing at a 
quarter-billion dollars per year. 

Check my math, but If we believe those sources, then that puts 
the return on sending one spam email at 1/546624 of a dollar, 
or about one point eight ten-thousandths of a penny. If we can 
make submitting a fraudulent transaction return less than that, 
then the botnets go on sending spams instead of submitting 
fraudulent transactions and our banking infrastructure is 
relatively safe. For now.  (Just don't think about our email 
infrastructure - it's depressing). 

If a fraud attack seeks to drain the account, it'll go 
for about the maximum amount it expects the bank to honor, 
which means, maybe, a couple thousand dollars (most checking
accounts have overdraft 

Re: Client Certificate UI for Chrome? [OT anonymous-transaction bull***t]

2009-08-21 Thread Ray Dillinger
[Moderator's note: this is getting a bit off topic, and I'd prefer to
limit followups. --Perry]

On Wed, 2009-08-19 at 06:23 +1000, James A. Donald wrote:
 Ray Dillinger wrote:

  If there is not an existing relationship (first time someone 
  uses an e-tailer) then there has to be a key depository that 
  both can authenticate to, with a token authorizing their 
  authentication to authenticate them to the other, which then 
  vouches to each for the identity of the other.  
 Actually not.
 What the seller wants to know is that the buyer's money is good, not 
 what the true name of the buyer is - a service provided by Visa, or 
 Web-money, or some such.

No.  This juvenile fantasy is complete and utter nonsense, and 
I've heard people repeating it to each other far too often.  If 
you repeat it to each other too often you run the risk of starting
to believe it, and it will only get you in trouble.  This is a 
world that has not just cryptographic protocols but also laws 
and rules and a society into which those protocols must fit.  That 
stuff doesn't all go away just because some fantasy-world 
conception of the future of commerce as unlinkable anonymous
transactions says it should.  

In any transaction involving physical goods, the seller also wants 
to know to whom to ship the product.  Since the laws in most nations 
do not require the recipient of an erroneous shipment to return 
the goods and *do* require the seller to give back the buyer's money
if the shipment doesn't go where the buyer wants it, sellers really 
care that the correct recipient will receive the package and really 
need some way to contact the buyer in case there's a mistake about 
the recipient address or identity.  Otherwise you'd get people 
playing silly buggers with the shipping address to get out of paying 
for million-dollar equipment.

The law usually requires that the recipient of defective goods 
or services has the ability to return those goods for a refund 
or obtain a refund in the event of seller nonperformance of 
services or nonshipment of goods.  Since such returns can be 
used to launder money from illegal enterprises, laws usually 
restrict anonymous returns. Therefore the seller needs the 
buyer's (or client's) identity in order to comply with the law.

In information-based transactions involving IP that's subject 
to copyright or trade secret protection (which is effectively 
all of them since other IP can be had for free) the seller also 
wants to know who is the licensee that's bound by the terms 
of the license and who now poses a risk of copyright breakage.  
In both cases this is a liability taken on by the buyer, and 
not something that his money being good for just the 
transaction price can ameliorate.

In financial transactions The seller also wants to know that s/he 
can comply with, eg, know your customer laws and avoid liability
for gross negligence in, eg, money laundering cases.  

In many transactions the seller wants the buyer's identity and a 
liability waiver signed by the buyer so as to keep track of or 
avoid liability for what the customer is going to do with his/her

Most sellers want the ability to offer the buyer credit terms,
especially when large sums are involved.  And even where money 
is supposedly firm (like the money Bernie Madoff's clients had 
in their accounts) it is subject to catastrophic vanishment in
extraordinary circumstances.  The seller needs to know whom to 
sue or at least whose name to put on the forms for their insurance 
claim if contrary to expectations the buyer's money turns out not 
to be good.

If the cert authority does not provide the identity of the buyer 
but asserts that the buyer's money is good, and this turns out not 
to be true (as in the case of Madoff's clients), then in most 
legal systems the cert authority is either liable, or can expect 
to be sued in a very expensive empirical test of liability.  So 
the cert authority doesn't want to be in the business of vouching 
for the ability of anonymous people to pay.  

The only way for the money to be truly firm for these purposes 
is that the cert authority has it in escrow.  This makes the 
cert authority a financial institution and therefore subject to 
know your customer mandatory reporting, data retention laws,
subpeonas, and so on.  Also, it introduces a needless delay 
and complication to the transaction that legitimate buyers and 
sellers would mostly rather not have. 

Also, in any large transaction the seller or cert authority or both 
must retain buyer identity information in order to be able to 
comply with subpeonas, inquests, or equivalent writs, for 
periods ranging from zero in a few undeveloped african nations to 
five years in much of the rest of the world. 

In most of the nations on earth, there is such a thing as sales 
tax or use tax on goods or services, and any transaction involving
more than a tiny sum must be reported (with the names of buyer and

Re: MD6 withdrawn from SHA-3 competition

2009-07-06 Thread Ray Dillinger
On Sat, 2009-07-04 at 10:39 -0700, Hal Finney wrote:
  Thus, while MD6 appears to be a robust and secure cryptographic
  hash algorithm, and has much merit for multi-core processors,
  our inability to provide a proof of security for a
  reduced-round (and possibly tweaked) version of MD6 against
  differential attacks suggests that MD6 is not ready for
  consideration for the next SHA-3 round.
 But how many other hash function candidates would also be excluded if
 such a stringent criterion were applied? Or turning it around, if NIST
 demanded a proof of immunity to differential attacks as Rivest proposed,
 how many candidates have offered such a proof, in variants fast enough
 to beat SHA-2?

I think resistance to attacks (note absence of any restrictive
adjective such as differential) is a very important property 
(indeed, one of the basic defining criteria) to demonstrate 
in a hash algorithm.  If someone can demonstrate an attack, 
differential or otherwise, or show reason to believe that such
an attack may exist, then that should be sufficient grounds 
to eliminate a vulnerable candidate from any standardization 

In other words, the fact that MD6 can demonstrate resistance to 
a class of attacks, if other candidates cannot, should stand in 
its favor regardless of whether the competition administrators 
say anything about proving resistance to any particular *kind* 
of attacks.  If that does not stand in its favor then the 
competition is exposed as no more than a misguided effort to 
standardize on one of the many Wrong Solutions.  


The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

Re: consulting question.... (DRM)

2009-05-27 Thread Ray Dillinger
On Tue, 2009-05-26 at 18:49 -0700, John Gilmore wrote:
 It's a little hard to help without knowing more about the situation.
 I.e. is this a software company?  Hardware?  Music?  Movies?
 Documents?  E-Books?  

It's a software company. 

 Is it trying to prevent access to something, or
 the copying of something?  What's the something?  What's the threat
 model?  Why is the company trying to do that?  Trying to restrain

Its customers would be other software companies that want to produce 
monitored applications.  Their product inserts program code into 
existing applications to make those applications monitor and report
their own usage and enforce the terms of their own licenses, for 
example disabling themselves if the central database indicates that 
their licensee's subscription has expired or if they've been used 
for more hours/keystrokes/clicks/users/machines/whatever in the 
current month than licensed for.

The idea is that software developers could use their product instead
of spending time and programming effort developing their own license-
enforcement mechanisms, using it to directly transform on the
executables as the last stage of the build process.

The threat model is that the users and sysadmins of the machines 
where the monitored applications are running have a financial 
motive to prevent those applications from reporting their usage.

 What country or countries does the company
 operate in?  What jurisdictions hold its main customer bases?  

They are in the US.  Their potential customers are international.
And their customers' potential clients (the end users of the 
monitored applications) are of course everywhere. 

 Why should we bother?  Isn't it a great idea for DRM fanatics to
 throw away their money?  More, more, please!  Bankrupt yourselves
 and drive your customers away.  Please!

You're taking a very polarized view.  These aren't DRM fanatics; 
they're business people doing due diligence on a new project, and
likely never to produce any DRM stuff at all if I can successfully
convince them that they are unlikely to profit from it.


The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

Re: consulting question....

2009-05-27 Thread Ray Dillinger
On Wed, 2009-05-27 at 10:31 -0400, Roland Dowdeswell wrote:

 I have noticed in my years as a security practitioner, that in my
 experience non-security people seem to assume that a system is
 perfectly secure until it is demonstrated that it is not with an
 example of an exploit.  Until an exploit is generated, any discussion
 of insecurity is filed in their minds as ``academic'', ``theoretical''
 or ``not real world''.  

This matches my experience as well.  Have any exploits of this 
particular scheme been found in the wild? is always one of the 
first three questions, and the answer is one of the best predictors
of whether the questioner actually does anything.  For best results 
one must be able to say something like, Yes, six times in the 
last year and start naming companies, products, dates, and 
independent sources that can be used to verify the incidents.  To 
really make the point one should also be able to cite financial 
costs and losses incurred.

Because companies don't like talking about cracks and exploits 
involving their own products, nor support third parties who attempt
systematic documentation of same, it is frequently very hard to 
produce sufficient evidence to convince and deter new reinventors 
of the same technology. This failure to track and document exploits
and cracks is a cultural failure that, IMO, is currently one of the
biggest nontechnical obstacles to software security. 


The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

consulting question....

2009-05-26 Thread Ray Dillinger

At a dinner party recently, I found myself discussing the difficulties 
of DRM (and software that is intended to implement it) with a rather 
intense and inquisitive woman who was very knowledgeable about what 
such software is supposed to do, but simultaneously very innocent of 
the broad experience of such things that security people have had.  
She was eager to learn, and asked me to summarize what I said to her 
in an email. So I did 

And it turns out that she is an executive in a small company which is 
now considering the development of a DRM product.  I just got email
from her boss (the CEO) offering to hire me, for a day or two 
anyway, as a consultant.  If I understand correctly, my job as
consultant will be to make a case to their board about what hurdles 
of technology and credibility that small company will find in its 
path if it pursues this course.

So now I need to go from Dinner party conversation mode to
consultant mode and that means I need to be able to cite specific
examples and if possible, research for the generalities I explained 
over dinner.  I'll be combing Schneier's blog and using Google to 
fill in details of examples I've already cited to get ready for 
this, but any help that folks could throw me to help illustrate 
and demonstrate my points (the paragraphs below) will be much

I explained to her that the typical experience of monitored or
protected software (software modified for DRM enforcement) is that
some guy in a randomly selected nation far outside the jurisdiction 
of your laws, using widely available tools like debuggers and hex 
editors, makes a cracked copy and distributes it widely, and 
that current efforts in the field seem more focused on legislation 
and international prosecutions than on software technology.  Software-
only solutions, aside from those involving a Trusted Computing Module
(which their proposed project does not - She seemed unaware of both 
the Trusted Computing Platform and the controversy over it) are no
longer considered credible.  I cited the example of DeCSS, whose 
crack of players for DRM'd movies used techniques generally 
applicable to any form of DRM'd software. 

I explained that in the worst case, such software works by making 
unacceptable compromises of security or autonomy on the machines where
it is installed, citing the infamous and widespread Sony Rootkit, (and 
IMO also the TCM system, but I didn't go into that messa worms at
dinner) and that these compromises usually become public and do 
serious damage to both the credibility of DRM systems generally and
the cash flow of the companies that perpetrate them (ISTR Sony wound
up losing something over 6 million in the US judgement alone on that 
one, and spent considerably more than that on legal fees in the US 
and several other nations). 

Finally, I explained the cheap attacks available to a sysadmin who 
does not want his DRM'd software reporting its usage statistics; for 
example having a firewall that filters outgoing packets. 

Does anyone feel that I have said anything untrue?

Can anyone point me at good information uses I can use to help prove 
the case to a bunch of skeptics who are considering throwing away 
their hard-earned money on a scheme that, in light of security
experience, seems foolish?

Ray Dillinger

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

Re: [tahoe-dev] SHA-1 broken! (was: Request for hash-dependency in Tahoe security.)

2009-05-01 Thread Ray Dillinger
On Thu, 2009-04-30 at 13:56 +0200, Eugen Leitl wrote:

 Wow!  These slides say that they discovered a way to find collisions  
 in SHA-1 at a cost of only 2^52 computations.  If this turns out to  
 be right (and the authors are respected cryptographers -- the kind of  
 people who really hate to be wrong about something like this) then it  
 is very exciting! 

I cannot derive a realistic threat model from the very general
statements in the slides. 

In the case of, for example, the Debian organization, which uses SHA-1 
keys to check in code so that it's always clear with a distributed 
network of developers who made what changes, What threats must they 
now guard against and what corrective measures ought they take?

Can a third-party attacker now forge someone's signature and check in 
code containing a backdoor under someone else's key?  Such code could 
be loaded on a poisoned server, downloaded, and executed on millions
of target machines with devastating effect and no way to catch the 

Can a rogue developer now construct a valid code vector B, having 
the same signature as some of his own (other) code A, thus bypassing
the signature check and inserting a backdoor?  The scenario is the 
same with a poisoned server but, once detected, the attacker would 
be identifiable.

Is it the case that a constructed hash collision between A and B 
can be done by a third party but would be highly unlikely to contain 
any executable or sensible code at all?  In this case the threat 
is serious, but mainly limited to vandalism rather than exploits.

Is it the case that a constructed hash collision between A and B 
can only be done by the developer of both A and B, but would be 
highly unlikely to contain any executable or sensible code at all?  
In this case the threat is very minor, because the identity of the 
vandal would be instantly apparent.


The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

Re: Judge orders defendant to decrypt PGP-protected laptop

2009-03-05 Thread Ray Dillinger
On Tue, 2009-03-03 at 21:33 -0500, Ivan Krsti? wrote:

 If you give me the benefit of the doubt for having a reasonable  
 general grasp of the legal system and not thinking the judge is an  
 automaton or an idiot, can you explain to me how you think the judge  
 can meet the burden of proof for contempt in this instance? Surely you  
 don't wish to say that anyone using encryption can be held in contempt  
 on the _chance_ they're not divulging all the information; what, then,  
 is the other explanation?

The law is not administered by idiots.  

In particular, the law is not administered by people who are more 
idiotic than you.  You may disagree with them, or with the law, 
but that does not make them stupid.

On the one hand there are (inevitable) differences in profile
between a partition that sees daily use and a partition that 
doesn't.  If a forensics squad had a good look at my laptop, 
they'd see that my (unencrypted) Windows partition has not been 
booted or used in three years, whereas file dates, times, and 
contents indicate that one of the other partitions is used daily.

If he decrypts a partition that clearly does not get used 
frequently, and more to the point shows no signs of having been 
used on a day when it is known that the laptop was booted up,
then he is clearly in violation of the order.

More to the point, you're arguing about a case where they 
have testimony from multiple officers who have *SEEN* that 
the images are on the computer, where both defense and 
prosecution agree that they do not enjoy fifth-amendment 
priveleges, and where the testomony of multiple officers 
gives the partition name (Z drive) in which the images 
were found.  If the decrypted partition does not match in 
these particulars, and especially if it does not show any 
evidence of usage while the laptop is known to have been 
powered up during the initial search, then the defendant 
is clearly in violation of the order. 

Now, I think there is a legitimate argument to be made about 
whether the defendant can be compelled to *use* a key which 
he has not got written down or otherwise stored anywhere 
outside his own head.  It's generally agreed that people can't 
be compelled to produce or disclose the existence of memorized 
keys, but can be compelled to produce or disclose the existence 
of any paper or device on which a key is recorded.  But 
regardless, if the order to use the key is considered legit, 
then failure to comply with the order (by using a different or 
wrong key, unlocking a different volume) is direct violation 
of a court order.  People go to jail for that.

Keep in mind that the right to be secure from search and seizure 
of one's documents has always been subject to due process and 
court orders in the form of search warrants.  The right to privacy 
is not an absolute right and never has been, and obstructing the 
execution of a lawfully served warrant is not a viable strategy
for staying out of jail.

(neither a lawyer, nor, usually, an idiot)

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

Re: Security through kittens, was Solving password problems

2009-02-25 Thread Ray Dillinger
On Wed, 2009-02-25 at 14:53 +, John Levine wrote:

 You're right, but it's not obvious to me how a site can tell an evil
 MITM proxy from a benign shared web cache.  The sequence of page
 accesses would be pretty similar.

There is no such thing as a benign web cache for secure pages.
If you detect something doing caching of secure pages, you need 
to shut them off just as much as you need to shut off any other 


The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

UCE - a simpler approach using just digital signing?

2009-01-30 Thread Ray Dillinger
I have a disgustingly simple proposal.  It seems to me that one 
of the primary reasons why UCE-limiting systems fail is the 
astonishing complexity of having a trust infrastructure 
maintained by trusted third parties or shared by more than 
one user.  Indeed, trusted third party and trust shared by 
multiple users may be oxymorons here. Trust, by nature, is 
not really knowable by any third party, not the same for any 
set of more than one user, and in fact the people most willing 
to pay for it at least where UCE is concerned, experience shows 
to be usually the _least_ trustworthy parties.  

So why hasn't anybody tried direct implementation of user-
managed digital signatures yet?

A key list maintained by individual recipients for themselves 
alone could be astonishingly simpler in practice, probably 
to the point of actually being practical.  

In fact, it is _necessary_ to eliminate third parties and 
shared infrastructure almost entirely in order to allow mail 
recipients to have the kind of fine-grained control that 
they actually need to address the problem by creating 
social and business feedback loops that promote good security.

As matters stand today, there is no protection from UCE. 
If I know there is a user account named 'fred' on the host
'', then I have an email address and I can send 
all the UCE I want.  And poor fred has the same email address 
he gives everybody, so he gets spam from people who've gotten 
his address and he has no idea where they got it.  All his 
legitimate correspondents are using the same email address, 
so he can't abandon it without abandoning *all* of them, 
and he doesn't know which of them gave his address to the 
spammers.  What if email accounts weren't that simple?  

Consider the implications of a third field, or trust token, 
which works like a password to fred's mail box.  Your 
mailer's copy of fred's email address would look like where token was a field that 
was your own personal password to fred's mailbox.  Your 
system would still send mail to but 
it would include a Trust: header based on the token.

The simplest solution I can think of would be a direct 
application of digital signatures;  the trust token would 
be (used as) a cryptographic key, and the headers of any 
message would have to include a Trust field containing a 
digital signature (a keyed cryptographic hash of the message, 
generated by that key).  Messages to multiple recipients 
would need to contain one Trust field per recipient. 

Its use would follow simple rules:  

Each time Fred gives out his email address to a new sender, 
he creates a trust token for that sender.  They must use it 
when they send him mail.  So fred gives his bank a key when 
he gives them his email address.  If fred were willing to 
recieve mail from strangers, he could publish a trust token 
on his webpage or on usenet or whatever - it would be painless 
to revoke it later, so why not?  If fred trusted someone to 
give out his email address, he could give that person multiple 
trust tokens to pass along to others.  Again, an error in 
judgement would be painless to revoke later.

Fred can revoke any trust token from his system at any time, 
and does so whenever he gets spam with a trust token he issued.  
In UI terms there'd be a button in his mail reader that works 
as, this message is spam, so revoke this trust token because 
now a spammer has it.  Other messages sent with the same 
trust token would disappear from his mailbox instantly. Fred 
might not push this button every time, but at least he'd know 
what spam he was getting due to (say) his published trust token
on his webpage or usenet, and what spam he was getting due to 
his relationship with a bank, and he'd have the option of 
turning any source of spam off instantly. 

In the short run the .aliases file on the mail host would need 
a line so it would know to deliver mail to
to fred.  This is not because a legitimate email would ever include
the literal key, but for purposes of alerting fred's MUA to protocol
breaches, so it could do key management.  Fred's MUA could then 
be upgraded to use tokens without affecting other users on the
system.In later MDA's that handle trust tokens directly, 
this forwarding would be automatic. 

Whenever Fred gets email sent by someone using a trust token, 
his system tells him which token - ie, what sender he gave 
that trust token to.  So email sent to fred using the trust 
token he gave his bank will show up in his mailbox under a 
heading that says this was sent by someone using the trust 
token you gave your bank.

Whenever fred gets email for and that's 
still a legitimate token, his system revokes the token, sends him 
an automatic note that says which trust token was revoked, and 
bounces the email with a message that says, 
Your mailer is not using trust tokens.  Your mail has not been

Re: Bitcoin P2P e-cash paper

2008-11-17 Thread Ray Dillinger
Okay I'm going to summarize this protocol as I understand it. 

I'm filling in some operational details that aren't in the paper 
by supplementing what you wrote with what my own design sense 
tells me are critical missing bits or obvious methodologies for 

First, people spend computer power creating a pool of coins to use 
as money.  Each coin is a proof-of-work meeting whatever criteria 
were in effect for money at the time it was created.  The time of 
creation (and therefore the criteria) is checkable later because 
people can see the emergence of this particular coin in the 
transaction chain and track it through all its consensus view 
spends.  (more later on coin creation tied to adding a link). 

When a coin is spent, the buyer and seller digitally sign a (blinded) 
transaction record, and broadcast it to a bunch of nodes whose purpose 
is keeping track of consensus regarding coin ownership.  If someone 
double spends, then the transaction record can be unblinded revealing 
the identity of the cheater.  This is done via a fairly standard cut-
and-choose algorithm where the buyer responds to several challenges 
with secret shares, and the seller then asks him to unblind and 
checks all but one, verifying that they do contain secret shares any 
two of which are sufficient to identify the buyer.  In this case the 
seller accepts the unblinded spend record as probably containing 
a valid secret share. 

The nodes keeping track of consensus regarding coin ownership are in 
a loop where they are all trying to add a link to the longest chain 
they've so far recieved.  They have a pool of reported transactions 
which they've not yet seen in a consensus signed chain.  I'm going 
to call this pool A.  They attempt to add a link to the chain by
moving everything from pool A into a pool L and using a CPU-
intensive digital signature algorithm to sign the chain including 
the new block L.  This results in a chain extended by a block 
containing all the transaction records they had in pool L, plus 
the node's digital signature.  While they do this, new 
transaction records continue to arrive and go into pool A again 
for the next cycle of work. 

They may also recieve chains as long as the one they're trying to 
extend while they work, in which the last few links are links 
that are *not* in common with the chain on which they're working.
These they ignore.  (?  Do they ignore them?  Under what 
circumstances would these become necessary to ever look at again, 
bearing in mind that any longer chain based on them will include 

But if they recieve a _longer_ chain while working, they 
immediately check all the transactions in the new links to make 
sure it contains no double spends and that the work factors of 
all new links are appropriate.  If it contains a double spend, 
then they create a transaction which is a proof of double 
spending, add it to their pool A, broadcast it, and continue work.  
If one of the new links has an inappropriate work factor (ie, 
someone didn't put enough CPU into it for it to be licit 
according to the rules) a new transaction which is a proof 
of the protocol violation by the link-creating node is created, 
broadcast, and added to pool A, and the chain is rejected.  In 
the case of no double spends and appropriate work factors for 
all links not yet seen, they accept the new chain as consensus. 

If the new chain is accepted, then they give up on adding their
current link, dump all the transactions from pool L back into pool 
A (along with transactions they've recieved or created since 
starting work), eliminate from pool A those transaction records 
which are already part of a link in the new chain, and start work 
again trying to extend the new chain. 

If they complete work on a chain extended with their new link, they 
broadcast it and immediately start work on another new link with 
all the transactions that have accumulated in pool A since they 
began work.  

Do I understand it correctly?

Biggest Technical Problem: 

Is there a mechanism to make sure that the chain does not consist 
solely of links added by just the 3 or 4 fastest nodes?  'Cause a 
broadcast transaction record could easily miss those 3 or 4 nodes 
and if it does, and those nodes continue to dominate the chain, the 
transaction might never get added.  

To remedy this, you need to either ensure provable propagation of
transactions, or vary the work factor for a node depending on how 
many links have been added since that node's most recent link.   

Unfortunately, both measures can be defeated by sock puppets.  
This is probably the worst problem with your protocol as it 
stands right now; you need some central point to control the 
identities (keys) of the nodes and prevent people from making 
new sock puppets. 

Provable propagation would mean that When Bob accepts a new chain 
from Alice, he needs to make sure that Alice has (or gets) all
transactions in his A and L pools.  He 

Re: Bitcoin P2P e-cash paper

2008-11-17 Thread Ray Dillinger
On Sat, 2008-11-15 at 12:43 +0800, Satoshi Nakamoto wrote:

 I'll try and hurry up and release the sourcecode as soon as possible 
 to serve as a reference to help clear up all these implementation 

 Ray Dillinger (Bear) wrote:
  When a coin is spent, the buyer and seller digitally sign a (blinded)
  transaction record.
 Only the buyer signs, and there's no blinding. 
  If someone double spends, then the transaction record 
  can be unblinded revealing the identity of the cheater. 
 Identities are not used, and there's no reliance on recourse.  It's all 

Okay, that's surprising.  If you're not using buyer/seller 
identities, then you are not checking that a spend is being made 
by someone who actually is the owner of (on record as having 
recieved) the coin being spent.  

There are three categories of identity that are useful to 
think about.  Category one: public.  Real-world identities 
are a matter of record and attached to every transaction.  
Category two: Pseudonymous.  There are persistent identities 
within the system and people can see if something was done by 
the same nym that did something else, but there's not necessarily 
any way of linking the nyms with real-world identities.  Category 
three: unlinkably anonymous.  There is no concept of identity,
persistent or otherwise.  No one can say or prove whether the 
agents involved in any transaction are the same agents as involved 
in any other transaction. 

Are you claiming category 3 as you seem to be, or category 2?
Lots of people don't distinguish between anonymous and 
pseudonymous protocols, so it's worth asking exactly what 
you mean here.  

Anyway:  I'll proceed on the assumption that you meant very 
nearly (as nearly as I can imagine, anyway) what you said, 
unlinkably anonymous.  That means that instead of an identity, 
a spender has to demonstrate knowledge of a secret known only 
to the real owner of the coin.  One way to do this would be 
to have the person recieving the coin generate an asymmetric 
key pair, and then have half of it published with the 
transaction.  In order to spend the coin later, s/he must 
demonstrate posession of the other half of the asymmetric 
key pair, probably by using it to sign the key provided by 
the new seller.  So we cannot prove anything about identity, 
but we can prove that the spender of the coin is someone who 
knows a secret that the person who recieved the coin knows. 

And what you say next seems to confirm this: 

 No challenges or secret shares.  A basic transaction is just 
 what you see in the figure in section 2.  A signature (of the 
 buyer) satisfying the public key of the previous transaction, 
 and a new public key (of the seller) that must be satisfied to 
 spend it the next time.

Note, even though this doesn't involve identity per se, it still 
makes the agent doing the spend linkable to the agent who 
earlier recieved the coin, so these transactions are linkable.  
In order to counteract this, the owner of the coin needs to 
make a transaction, indistinguishable to others from any 
normal transaction, in which he creates a new key pair and 
transfers the coin to its posessor (ie, has one sock puppet 
spend it to another). No change in real-world identity of 
the owner, but the transaction linkable to the agent who spent 
the coin is unlinked.  For category-three unlinkability, this 
has to be done a random number of times - maybe one to six 

BTW, could you please learn to use carriage returns??  Your 
lines are scrolling stupidly off to the right and I have to 
scroll to see what the heck you're saying, then edit to add 
carriage returns before I respond. 

  If it contains a double spend, then they create a transaction 
  which is a proof of double spending, add it to their pool A, 
  broadcast it, and continue work.

 There's no need for reporting of proof of double spending like 
 that.  If the same chain contains both spends, then the block is 
 invalid and rejected.  

 Same if a block didn't have enough proof-of-work.  That block is 
 invalid and rejected.  There's no need to circulate a report 
 about it.  Every node could see that and reject it before relaying it.

Mmmm.  I don't know if I'm comfortable with that.  You're saying 
there's no effort to identify and exclude nodes that don't 
cooperate?  I suspect this will lead to trouble and possible DOS 

 If there are two competing chains, each containing a different 
 version of the same transaction, with one trying to give money 
 to one person and the other trying to give the same money to 
 someone else, resolving which of the spends is valid is what 
 the whole proof-of-work chain is about.

Okay, when you say same transaction, and you're talking about 
transactions that are obviously different, you mean a double 
spend, right?  Two transactions signed with the same key?

 We're not on the lookout for double spends to sound the alarm 
 and catch

Re: Bitcoin P2P e-cash paper

2008-11-07 Thread Ray Dillinger
On Tue, 2008-11-04 at 06:20 +1000, James A. Donald wrote:

 If I understand Simplified Payment Verification
 New coin issuers need to store all coins and all recent
 coin transfers.
 There are many new coin issuers, as many as want to be
 issuers, but far more coin users.
 Ordinary entities merely transfer coins.  To see if a
 coin transfer is OK, they report it to one or more new
 coin issuers and see if the new coin issuer accepts it.
 New coin issuers check transfers of old coins so that
 their new coins have valid form, and they report the
 outcome of this check so that people will report their
 transfers to the new coin issuer.

I think the real issue with this system is the market 
for bitcoins.  

Computing proofs-of-work have no intrinsic value.  We 
can have a limited supply curve (although the currency 
is inflationary at about 35% as that's how much faster 
computers get annually) but there is no demand curve 
that intersects it at a positive price point.

I know the same (lack of intrinsic value) can be said of 
fiat currencies, but an artificial demand for fiat 
currencies is created by (among other things) taxation 
and legal-tender laws.  Also, even a fiat currency can 
be an inflation hedge against another fiat currency's 
higher rate of inflation.   But in the case of bitcoins 
the inflation rate of 35% is almost guaranteed by the 
technology, there are no supporting mechanisms for 
taxation, and no legal-tender laws.  People will not 
hold assets in this highly-inflationary currency if 
they can help it.  


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]

Re: User interface, security, and simplicity

2008-05-04 Thread Ray Dillinger
On Sat, 2008-05-03 at 23:35 +, Steven M. Bellovin wrote:

 There's a technical/philosophical issue lurking here.  We tried to
 solve it in IPsec; not only do I think we didn't succeed, I'm not at
 all clear we could or should have succeeded.
 IPsec operates at layer 3, where there are (generally) no user
 contexts.  This makes it difficult to bind IPsec credentials to a user,
 which means that it inherently can't be as simple to configure as ssh.

Let me restate things just to make sure I understand the problem.
You're talking about binding IPsec credentials to a user, but 
I want to look at it from the point of view of exactly what 
problems this causes, so is the following an accurate position?

The problem is that we're trying to have entities with different 
security needs share a common set of authentications.  When user 'pat' 
and user 'sandy' have different security needs (different authorized
or trustable communication partners, to start with) we can't give 
them IPSEC because IPSEC operates on channels between machines 
rather than on channels between trusting/trusted entities.   Even 
if 'pat' and 'sandy' both have a trusted/trusting entity on a given
remote machine from theirs, IPSEC fails them because it cannot
differentiate between the various entities (users, agents, services)
using that remote machine, when 'pat' and 'sandy' need it to.  
Similarly, it fails the entities on that remote machine because it 
cannot differentiate between 'pat', 'sandy' and any other entities 
using the local machine, when trust relationships might exist only
for some subset of those entities.


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

Re: Death of antivirus software imminent

2008-01-18 Thread Ray Dillinger
On Fri, 2008-01-18 at 02:31 -0800, Alex Alten wrote:
 At 07:35 PM 1/18/2008 +1000, James A. Donald wrote:
 And all the criminals will of course obey the law.
 Why not just require them to set an evil flag on all
 their packets?
 These are trite responses.  Of course not.  My point is
 that if the criminals are lazy enough to use a standard
 security protocol then they can't expect us not to put
 something in place to decrypt that traffic at will if necessary.

I see your point, but I can't help feeling that it's a 
lot like requiring all houses to be designed and built with 
a backdoor that the police have a key to, in order to 
guarantee that the police can come in to investigate crimes. 

The problem is that the existence of that extra door, and 
the inability of people to control their own keys to lock 
it, makes crimes drastically easier to commit.  You think 
police don't use DMV records to harass ex-girlfriends or 
make life hard for people they don't like?  You think 
Private investigators and other randoms who somehow finesse 
access to that data all have the best interests of the public 
at heart?  You think the contractor who builds the house 
will somehow forget where the door is, or will turn over 
*all* copies of the keys? 

And stepping away from quasi-legit access used for illegitimate
purposes, you think there're no locksmiths whose services the 
outright criminals can't buy?  You think the existence of a 
backdoor won't inspire criminal efforts to get the key (by 
reading a binary dump if need be) and go through it?

 I guarantee I can make any payload look like any other
 payload.  If the only permitted communications are
 prayers to Allah, I can encode key exchange in prayers
 to Allah.

 Look, the criminals have to design their security system with
 severe disadvantages; they don't own the machines they
 attack/take over so they can't control its software/hardware
 contents easily, they can't screw around too much with the IP
 protocol headers or they lose communications with them, and
 they don't have physical access to the slave/owned machines.

That is a very petty class of criminal.  While the aggregate 
thefts (of computer power, bandwidth, etc) are impressive, 
they're stealing nothing that isn't a cheap commodity anyway 
and the threat to lives and real property that would justify 
the kind of backdoors we're talking about just isn't there. 
Being subject to botnets and their ilk is more like the 
additional cost of doing business in bad weather, than it 
is like being the victim of a planned and premeditated 
crime with a particular high-value target.  

Moreover, we know how to weatherproof our systems.  
Seriously.  We know where the vulnerabilities are and we 
know how to create systems that don't have them.  And we 
don't need to install backdoors or allocate law enforcement 
budget to do it.  More than half the servers on the Internet - 
the very most desirable machines for botnet operators, 
because they have huge storage and huge bandwidth - run 
some form of Unix, and yet, since 1981 and the Morris Worm, 
you've never heard of a botnet composed of Unix machines!  
Think about that!  They do business in the same bad weather 
as everyone else, but it costs them very little, because 
they have ROOFS!

I submit that the sole reason Botnet operation even exists 
is because so many people are continuing to use an operating 
system and software whose security is known to be inferior. 
A(nother) backdoor in that system won't help.

The criminals whose activities do justify the sort of backdoors 
you're talking about - the bombers, the kidnappers, the 
extortionists, even the kiddie porn producers and that ilk - 
won't be much affected by them, because they *do* take the 
effort to get hard crypto working in addition to standard 
protocols, they *do* own their own machines and get to pick 
and choose what software goes on them, and if they're 
technically bent they can roll their own protocols. 


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