### Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

```I don't see what problem would actually be solved by dropping public key crypto
in favor of symmetric only designs.  I mean, if the problem is that all public
key systems are broken, then yeah, we will have to do something else.  But if
the problem is bad key generation or bad implementations, those will be with us
even after we abandon all the public key stuff.  And as Jon said, the trust
problems get harder, not easier.  With only symmetric crypto, whoever acts as
the introducer between Alice and Bob can read their traffic passively and
undetectably.  With public key crypto, the introducer can do a man in the
middle attack (an active attack) and risks detection, as Alice and Bob now have
things signed by the introducer associating the wrong keys with Bob and Alice,
respectively.

--John
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] FIPS, NIST and ITAR questions

```

On Sep 3, 2013, at 6:06 PM, Jerry Leichter leich...@lrw.com wrote:

On Sep 3, 2013, at 3:16 PM, Faré fah...@gmail.com wrote:
Can't you trivially transform a hash into a PRNG, a PRNG into a
cypher, and vice versa?
No.

hash-PRNG: append blocks that are digest (seed ++ counter ++ seed)
Let H(X) = SHA-512(X) || SHA-512(X)
where '||' is concatenation.  Assuming SHA-512 is a cryptographically secure
hash H trivially is as well.  (Nothing in the definition of a cryptographic
hash function says anything about minimality.)  But H(X) is clearly not
useful for producing a PRNG.

If you think this is obviously wrong, consider instead:

H1(X) = SHA-512(X) || SHA-512(SHA-512(X))

as a PRNG?  (You could certainly do it with about 2^256 calls to H1 with
distinct inputs - by then you have a .5 chance of a duplicated top half of
the output, almost certainly with a distinct bottom half.  But that's a
pretty serious bit of testing)

I don't actually know if there exists a construction of a PRNG from a
cryptographically secure hash function.  (You can build a MAC, but even
that's not trivial; people tried all kinds of things that failed until the
HMAC construction was proven correct.)
-- Jerry

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
```

### Re: [Cryptography] FIPS, NIST and ITAR questions

```
...
Let H(X) = SHA-512(X) || SHA-512(X)
where '||' is concatenation.  Assuming SHA-512 is a cryptographically secure
hash H trivially is as well.  (Nothing in the definition of a cryptographic
hash function says anything about minimality.)  But H(X) is clearly not
useful for producing a PRNG.

You won't get a prf or stream cipher or prng or block cipher just out of
collision resistance--you need some kind of pseudorandomness assumption.  We
expect general purpose hash functions like Keccak to provide that, but it
doesn't follow from the collision resistance assumption, for exactly the reason
you gave there--it's possible to design collision-resistant functions that leak
input or are predictable in some bits.

I don't actually know if there exists a construction of a PRNG from a
cryptographically secure hash function.  (You can build a MAC, but even
that's not trivial; people tried all kinds of things that failed until the
HMAC construction was proven correct.)

The HMAC construction wouldn't give a PRF for your example of

h(x) = sha512(x) || sha512(x)

A single output would be trivial to distinguish from a 1024 bit random number.

-- Jerry

--John
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] Can you backdoor a symmetric cipher

```On Thu, 5 Sep 2013 21:42:29 -0700 Jon Callas j...@callas.org wrote:
On Sep 5, 2013, at 9:33 PM, Perry E. Metzger pe...@piermont.com
wrote:

It is probably very difficult, possibly impossible in practice, to
backdoor a symmetric cipher. For evidence, I direct you to this
old paper by Blaze, Feigenbaum and Leighton:

http://www.crypto.com/papers/mkcs.pdf

There is also a theorem somewhere (I am forgetting where)

See the URL quoted above. That is the implication of their paper.

that says that if you have a block cipher with a back door, then it
is also a public key cipher.

Perry
--
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### [Cryptography] Aside on random numbers (was Re: Opening Discussion: Speculation on BULLRUN)

```On Fri, 6 Sep 2013 01:04:31 -0400 John Kelsey crypto@gmail.com
wrote:
I'm starting to think that I'd probably rather type in the
results of a few dozen die rolls every month in to my critical
servers and let AES or something similar in counter mode do the
rest.

A d20 has a bit more than 4 bits of entropy. I can get 256 bits
with 64 die rolls, or, if I have eight dice, 16 rolls of the
group. If I mistype when entering the info, no harm is caused.
The generator can be easily tested for correct behavior if it is
simply a block cipher.

If you're trying to solve the problem of not trusting your entropy
source, this is reasonable, but it doesn't exactly scale to normal
users.

No, clearly not, but it works fine for a key generation ceremony for
a valuable key or the like. It might also be fine in other limited
contexts.

That said, I came up with a fine way to automate this in the shower,
which I'm documenting here in case it inspires someone.

Naively, one could take a picture of the dice and OCR it. However,
one doesn't actually need to OCR the dice -- simply hashing the
pixels from the image will have at least as much entropy if the
position of the dice is recognizable from the image. (You have to
assume your hash function is reasonable but the rest of your
infrastructure needs to assume that anyway in all likelihood.) So,
simply take pictures of each of N rolls of multiple dice and hash
them all together.

One could write an  app to do this, but of course the phone is
not exactly a secure platform to begin with...

Perry
--
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### [Cryptography] Sabotaged hardware (was Re: Opening Discussion: Speculation on BULLRUN)

```On Thu, 5 Sep 2013 22:31:50 -0400 Jerry Leichter leich...@lrw.com
wrote:
For example, at
http://www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html?ref=uspagewanted=all,
the following goal appears for FY 2013 appears:  Complete enabling
for [redacted] encryption chips used in Virtual Public Network and
Web encryption devices.  The Times adds the following note:
Large Internet companies use dedicated hardware to scramble
traffic before it is sent. In 2013, the agency planned to be able
to decode traffic that was encoded by one of these two encryption
chips, either by working with the manufacturers of the chips to
insert back doors or by exploiting a security flaw in the chips'
design.

This is troubling. It implies that there are widely used crypto
accelerators in use at large organizations that intentionally harm
the security of users. Random number generator flaws would seem like
an obvious possibility here.

This is especially disturbing because other actors can now start
doing teardowns on a wide variety of such devices looking to find the
flaws so they can themselves attack the traffic in question.

Perry
--
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)

```  One solution, preventing passive attacks, is for major browsers
and websites to switch to using PFS ciphersuites (i.e. those
based on ephemeral Diffie-Hellmann key exchange).

It occurred to me yesterday that this seems like something all major
service providers should be doing. I'm sure that some voices will say
additional delay harms user experience. Such voices should be
ruthlessly ignored.

Perry
--
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] Is ECC suspicious?

```
Op 6 sep. 2013, om 01:09 heeft Perry E. Metzger pe...@piermont.com het
volgende geschreven:

http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance
….
The Suite B curves were picked some time ago. Maybe they have problems.
….
Now, this certainly was a problem for the random number generator
standard, but is it an actual worry in other contexts? I tend not to
believe that but I'm curious about opinions.

Given the use, including that of the wider security/intelligence community, I'd
expect any issues to be more with very specific curves (either tweaked to be
that way; or through soft means promoted/pushed/suggested those who by
happenstance have an issue) that with the ECC as an algorithm/technology class.
As anything deeper than a curve would assume very aligned/top-down control and
little political entropy. Not something which 'just the' signal intelligence
community could easily enforce on the other cats.

Dw
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

```On Thu, Sep 05, 2013 at 04:11:57PM -0400, Phillip Hallam-Baker wrote:

Snowden didn't have clearance for that information. He's being described
as 'brilliant' and purportedly was able to access documents far beyond his
level by impersonating (using stolen/falsified secrets) higher level officials.

more than it will accomplish anything.

We're still missing the information which cyphers are now legacy, and
which are still considered useful. I keep seeing PFS being touted,
but there is no evidence yet we can trust PFS to be yet unbroken
though it appears plausible.

Others are suggesting that public key encryption methods are suspect,
while symmetric encryption has a better story. I'm personally becoming
quite interested in a reliable way to produce secure one-time pads,
using physical entropy sources which have been validated. It would
be interesting to physically/securely exchanging large one-time
pads in one's social network, and reaching farther recipients in
a Retroshare-like (turtle router) model.

It might be useful to combine one-time pads with symmetric encryption,
automatically rekeying every large block of data for high-volume
transfers (e.g. mesh routers) to stretch a one-time pad without
completely losing its properties. The question is how large a block
can be before it leaks enough information about the key.

that indicated the existence of any program which involved the successful
cryptanalysis of any cipher regarded as 'strong' by this community then the
Director of National Intelligence, the Director of the NSA and everyone
involved in those decisions should be fired immediately and lose their
pensions.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)

```-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 9/6/13 8:36 AM, Perry E. Metzger wrote:
One solution, preventing passive attacks, is for major
browsers and websites to switch to using PFS ciphersuites (i.e.
those based on ephemeral Diffie-Hellmann key exchange).

It occurred to me yesterday that this seems like something all
major service providers should be doing. I'm sure that some voices
will say additional delay harms user experience. Such voices should
be ruthlessly ignored.

+1

In practice, how do we make that happen? On the XMPP network we're
pushing to make sure that all client-to-server and server-to-server
hops are encrypted (yes, I know, per-hop encryption is not enough, we
need end-to-end encryption too). Is there a handy list of PFS-friendly
ciphersuites that I can communicate to XMPP developers and admins so
they can start upgrading their software and deployments?

Thanks!

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSKgDaAAoJEOoGpJErxa2pMssQAKVjwZZqy0q2ogIk13rGZkym
8PnXm6H9qsw08q4w3NEXPOU41rEh/GpS4agcgVxA+huYo5hU+qeA8YuhrVXt2xS7
Jt/fUgpJup297W4ErUpzMDQegVfP8ckNizI2AXBfr631PKUs7U3ije6wdxK30Hyx
262V/SLP0uVnJpbmepWUMCfzTGMY0SAvq2blVAPJjqjulC6lshj/aiKP6RBi9hCF
CW8yWO4L7Uot1mAa7j87Ywlyg9V8j6nKNEsKu81rjhSLpGvmed0GncK7U3GxLmsM
z2VzZKRJ+NxwJ3MKicmEy2bNnPjSJUd8itUWKru2vYMZftGImljWv1cUsLjXkxI7
DvQQ0lrjl3W8tisN7aqmGPi2734j8AN6ilHAUCbWniJfaarfC6rU/fDuk6fGnFss
N/zq9+NhYdvegmJiLvwVm42d1XdCxgoKzb27g/d8CsUWqWWXtQhxTeLL+OcKXiqh
kXLDDTv9uqBgdqWDZ/uhhlFGd/PFfeakeW7QWDjAvRMyF3XWaHA+OBJpg+nE/Dsl
kSfLmiCzOj4FN8aPQoM39T9IHbASpp+KYgnCl0nDweYXXBH/v5B/bCwsqz5Sy0ut
SET7zglbKm6oVf9hWoXsv01Kqsrxw6xj2bdnMU6YSUQoDvDHdXlilRZ6dTP5G63v
8XfdEe3k0aa+7uPpWQ5t
=SiIp
-END PGP SIGNATURE-
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

```On Fri, 6 Sep 2013 01:19:10 -0400
John Kelsey crypto@gmail.com wrote:

I don't see what problem would actually be solved by dropping public
key crypto in favor of symmetric only designs.  I mean, if the
problem is that all public key systems are broken, then yeah, we will
have to do something else.  But if the problem is bad key generation
or bad implementations, those will be with us even after we abandon
all the public key stuff.

Not necessarily.  A bad implementation of a block cipher will be
probably spotted quickly if you need it to interoperate with a good
implementation; a bad implementation of a public key cipher might
interoperate just fine with good implementations.  Public key systems
often have parameters or requirements that affect security without
affecting the correctness of encryption or decryption.  ElGamal
encryption might appear to work even though you are using a group where
the DDH assumption does not hold.  Elliptic curve systems have even more
parameters that need to be set correctly for security.

I am not saying that we should abandon public key cryptography, I am
just saying that there a number of ways for public key systems to go
wrong that do not apply to symmetric ciphers.

Just my 2 cents,
Ben

--
Benjamin R Kreuter
UVA Computer Science
brk...@virginia.edu
KK4FJZ

--

If large numbers of people are interested in freedom of speech, there
will be freedom of speech, even if the law forbids it; if public
opinion is sluggish, inconvenient minorities will be persecuted, even
if laws exist to protect them. - George Orwell

signature.asc
Description: PGP signature
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
```

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

```Hi,

Same here.  AES is, as far as we know, pretty secure, so any problems are
going to arise in how AES is used.  AES-CBC wrapped in HMAC is about as solid
as you can get.  AES-GCM is a design or coding accident waiting to happen.

But for right now, what options do we have that are actually implemented
somewhere?

Take SSL. CBC mode has come under pressure for SSL (CRIME, BEAST, etc.),
and I don't see any move towards TLS  1.0.

RC4 was good enough for a while, but with djb's new work - it's just
waiting to be improved and made practical by someone. FWIW, we still use
RC4 on our servers, but I'd be happy to see something else that is
practical.

Of course, the above attacks are probably not one of your worries when
you're up against the NSA - your own system is probably much more
endangered.

Ralph
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] Aside on random numbers (was Re: Opening Discussion: Speculation on BULLRUN)

```
On Sep 6, 2013, at 10:03 AM, Perry E. Metzger pe...@piermont.com wrote:
Naively, one could take a picture of the dice and OCR it. However,
one doesn't actually need to OCR the dice -- simply hashing the
pixels from the image will have at least as much entropy if the
position of the dice is recognizable from the image.

[...]

One could write an  app to do this, but of course the phone is
not exactly a secure platform to begin with...

http://gamesbyemail.com/News/DiceOMatic

-wps

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

```
5. sep. 2013 kl. 23:14 skrev Tim Dierks t...@dierks.org:

I believe it is Dual_EC_DRBG. The ProPublica story says:
Classified N.S.A. memos appear to confirm that the fatal weakness, discovered
by two Microsoft cryptographers in 2007, was engineered by the agency. The
N.S.A. wrote the standard and aggressively pushed it on the international
group, privately calling the effort “a challenge in finesse.”
This appears to describe the NIST SP 800-90 situation pretty precisely. I
found Schneier's contemporaneous article to be good at refreshing my memory:
http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115

As a co-author of an analysis of Dual-EC-DRBG that did not emphasize this
problem (we only stated that Q had to be chosen at random, Ferguson co were
right to emphasize this point), I would like to ask:

Has anyone, anywhere ever seen someone use Dual-EC-DRBG?

I mean, who on earth would be daft enough to use the slowest possible DRBG? If
this is the best NSA can do, they are over-hyped.

(If you really do want to use Dual-EC-DRBG: truncate more than 16 bits, and
don't use NSA's points, choose your own - at random.)

--
Kristian Gjøsteen

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] People should turn on PFS in TLS

```On Fri, 6 Sep 2013 18:18:05 +0100 Ben Laurie b...@links.org wrote:
On 6 September 2013 18:13, Perry E. Metzger pe...@piermont.com
wrote:

Google is also now (I believe) using PFS on their connections, and
they handle more traffic than anyone. A connection I just made to
https://www.google.com/ came out as, TLS 1.2, RC4_128, SHA1,
ECDHE_RSA.

It would be good to see them abandon RC4 of course, and soon.

In favour of what, exactly? We're out of good ciphersuites.

I thought AES was okay for TLS 1.2? Isn't the issue simply that
Firefox etc. still use TLS 1.0? Note that this was a TLS 1.2
connection.

--
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] Can you backdoor a symmetric cipher (was Re: Opening Discussion: Speculation on BULLRUN)

```
It is probably very difficult, possibly impossible in practice, to
backdoor a symmetric cipher. For evidence, I direct you to this old
paper by Blaze, Feigenbaum and Leighton:

http://www.crypto.com/papers/mkcs.pdf

There is also a theorem somewhere (I am forgetting where) that says that if
you have a block cipher with a back door, then it is also a public key
cipher  The real question there is whether someone who had such a thing
would want to be remembered by history as the inventor of the most
significant PK system the world has ever seen, or a backdoored cipher.
Well, if that someone were the NSA, they might well be very happy to be
remembered as the guy who made it possible break in to much of the world's
communication!

However, I find this argument unconvincing.  It has the feel of a standard
reduction, but isn't, because the reduction is to a known problem that's widely
thought to be difficult - it's to a vaguely defined, broad class of problems,
designing a much faster public key system.  Just because the construction
gives you something like a public key system, doesn't mean if gives you
anything practical for use that way.  For example, suppose the master key works
- but only for 1/2^k possible cleartext blocks, or even 1/2^k possible keys.
This makes it useless as a public-key system even for very small k, but quite
useful to an attacker even for larger k.

Or suppose the master key works on all messages and keys, but is inefficient,
requiring large amounts of time or memory, or the pre-computation of large
lookup tables.  Here's a thought experiment:  Suppose differential
cryptanalysis were known only to you, and you were in a position to influence
the choice of S-boxes for a cryptosystem.  Your master key would be the
knowledge that DC would work very effectively against the system - but it would
still require a lot of time and memory to do so.  You'd even have a leg up on
everyone else because you'd know the differentials to use up front - though
that's a trivial advantage, since once you know to look for them, finding them
is easy enough.  In fact, as far as I know, no one has had any reason to pose
questions like:  Could you choose S-boxes that allow some kind of
pre-computation step to make application of DC to messages much faster?  DC
requires gathering up a large number of plaintext/cyphertext pairs; eventually,
you f
ind examples of you can use.  But could there be some way of producing pairs
so that success is more likely to come earlier?  Could it be that there's some
pre-secret that allows computation both of those tables and and of the S-boxes,
such that given only the S-boxes, finding the pre-secret and the tables isn't
practical?  Once DC was known and it was found the NSA had actually
strengthened DES's S-boxes to protect against it, no one really looked into
such issues - basically, who cared?

If you really want to think in tin-hat terms, consider linear cryptanalysis.
While DES was strong against DC, it was quite weak against LC.  People
interpreted this as meaning that NSA didn't know about LC.  But ... maybe out
in Area 51, or wherever Langley does work with alien technologies, they knew
about LC *all along*, and *deliberately* made DES weak against it!  (Why LC and
not DC?  Because as we subsequently learned from Don Coppersmith, DC was
already known in the non-NSA community, and the NSA knew that it was known.)

Please keep in mind that I'm not proposing that NSA actually did anything like
this for any widely-used cryptosystem.  I don't even see how they could have
with respect to, say, AES, since they had no hand in the design of the
algorithm or the choice of constants.  The only thing I'm arguing here is that
the theorems that say such a thing could never happen prove nothing of the
sort.
-- Jerry

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

``` Perhaps it's time to move away from public-key entirely!  We have a classic
paper - Needham and Schroeder, maybe? - showing that private key can do
anything public key can; it's just more complicated and less efficient.

Not really. The Needham-Schroeder you're thinking of is the essence of
Kerberos, and while Kerberos is a very nice thing, it's hardly a replacement
for public key.

If you use a Needham-Schroeder/Kerberos style system with symmetric key
systems, you end up with all of the trust problems, but on steroids
I don't think we're really in disagreement here.  Much of what you say later in
the message is that the way we are using symmetric-key systems (CA's and such),
and the way browsers work, are fundamentally wrong, and need to be changed.
And that's really the point:  The system we have is all of a piece, and
incremental changes, sadly, can only go so far.  We need to re-think things
from the ground up.  And I'll stand by my contention that we need to re-examine
things we think we know, based on analyses done 30 years ago.  Good theorems
are forever, but design choices apply those theorems to real-world
circumstances.  So much has changed, both on the technical front and on
non-technical fronts, that the basis for those design choices has fundamentally
changed.

Getting major changes fielded in the Internet is extremely difficult - see
IPv6.  If it can be done at all, it will take years.  But the alternative of
continuing on the path we're on seems less desirable every day.

-- Jerry

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

```On Sep 6, 2013, at 7:28 AM, Jerry Leichter wrote:
...Much of what you say later in the message is that the way we are using
symmetric-key systems (CA's and such)...
Argh!  And this is why I dislike using symmetric and asymmetric to describe
cryptosystems:  In English, the distinction is way too brittle.  Just a
one-letter difference - and in including or not the letter physically right
next to the s.
-- Jerry :-)

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

```On Fri, Sep 6, 2013 at 3:03 AM, Kristian Gjøsteen
kristian.gjost...@math.ntnu.no wrote:

Has anyone, anywhere ever seen someone use Dual-EC-DRBG?

I mean, who on earth would be daft enough to use the slowest possible
DRBG? If this is the best NSA can do, they are over-hyped.

It's implemented in Windows and in a number of other libraries*; I can't
find any documentation on which points these implementations use. But I
agree that there's little technical reason to use it—however, who is to
know that a vendor couldn't be influenced to choose it?

In pursuing the list NIST validations, there's aa number of cases where
Dual_EC_DRBG is the only listed mode, but all of them (with one exception)
are issued to companies where they have other validations, generally on
similar products, so it just looks like they got multiple validations for
different modes. The one exception is Lancope, validation #288, which
validated their use of Dual_EC_DRBG, but no other modes. So it looks like
there's at least one implementation at use in the wild.

- Tim

* - The implementors that NIST
listshttp://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval.html
are:
RSA, Certicom, Cisco, Juniper, BlackBerry, OpenPeak, OpenSSL, Microsoft,
Mocana, ARX, Cummings Engineering Consultants, Catbird, Thales e-Security,
SafeLogic, Panzura, SafeNet, Kony, Riverbed, and Symantec. (I excluded
validations where the implementation clearly appears to be licensed, but
people can name it anything they want, and some of the above are probably
just OpenSSL forks, etc.)
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
```

### Re: [Cryptography] IA side subverted by SIGINT side

``` I have a small amount of raised eyebrow because the greatest bulwark
we have against the SIGINT capabilities of any intelligence agency are
that agency's IA cousins. I don't think that the Suite B curves would
have been intentionally weak. That would be a shock.

Then be shocked, shocked that the muscular exploitation side of an
intelligence agency would overrule the weak Information Assurance
side.  It happens over and over.

It even happens in companies that have no SIGINT side, like Crypto AG,
when somebody near the top is corrupted or blackmailed into submission.

As late as 1996, the National Academy of Sciences CRISIS panel was
tasked by the US Congress with coming up with a US crypto policy that
would be good for the whole nation, updating the previous policy that
was driven by spy agency and law enforcement excesses to sacrifice the
privacy and security of both people and companies.  After taking a
large variety of classified and unclassified input, the panel's
unanimous consensus suggested that everybody standardize on 56-bit
DES, which they KNEW was breakable.

Diffie, Hellman and Baran persuasively argued in the 1970s when DES
was up for standardization that a brute force DES cracker was
practical; they recommended longer keys than 56 bits.  See for example
this contemporaneous 1976 cassette recording / transcript:

Subsequent papers in 1993 (Weiner, Efficient DES Key Search) and in
1996 (Goldberg  Wagner, Architectural Considerations for
Cryptanalytic Hardware) provided solid designs for brute-force DES
key crackers.  Numerous cryptographers and cypherpunks provided input
to the CRISIS panel as well.  They even cited these papers and input
on page 288 of their report.

I have never seen a subsequent accounting by the CRISIS panel members
for this obviously flawed recommendation.  It was rapidly obsoleted by
subsequent developments when in June 1997 Rocke Verser coordinated a
team to publicly crack DES by brute force in months; when in 1998 EFF
revealed its DES Cracker hardware that cost \$250K and could crack DES
in a week; and when in 2000 the export regs were effectively removed
on any strength encryption in mass market and free software, a change
forced upon them by EFF's success in Dan Bernstein's First Amendment
case.

The panel members included substantial information-assurance folks
like Marty Hellman and Peter Neumann, Lotus Notes creator Ray Ozzie,
and Willis Ware (an engineer on WW2 radars and the Johnniac, who later
spread computers throughout aviation design and the Air Force, ended
up at RAND, and served on the 1974 Privacy Act's Privacy Protection
Study Commission).  But several of those people (and others on the
panel such as Ann Caracristi, long-term NSA employee and 2-year deputy
director of NSA) also have a long history involved with classified
military work, which makes their publicly-uttered statements unlikely
to reflect their actual beliefs.

John

PS: The CRISIS panel also recommended that encryption of any strength
be exportable if the proposed product user is willing to provide
They assumed the ongoing existence of a democratic civilian government
and a functioning independent court system in the United States -- an
assumption that is currently questionable.  I don't think the panel
foresaw that a single legally authorized request would come with a
gag order from a secret court, would purport to target a single
unnamed individual, but would nevertheless require that information
about every person making a phone call in the United States be turned
over to a classified government agency for permanent storage and
exploitation.  Nor did they see that the government they were part of
would be committing serious international war crimes including political
assassination, torture, indefinite detention without trial, and wars
of aggression, on an ongoing basis.  Either that, or maybe NSA
blackmailed the committee members into these recommendations, just as
J. Edgar Hoover blackmailed his way through 40 years of unchecked
power.  Trouble is, Hoover eventually had to die; NSA, not being
human, does not have that natural limit.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] People should turn on PFS in TLS

```Hi,

It would be good to see them abandon RC4 of course, and soon.

In favour of what, exactly? We're out of good ciphersuites.

I thought AES was okay for TLS 1.2? Isn't the issue simply that
Firefox etc. still use TLS 1.0? Note that this was a TLS 1.2
connection.

Firefox has added TLS 1.2 two or three weeks ago, and TLS 1.2 does
indeed protect against BEAST, CRIME, Lucky 13 (but not against BREACH, I
recall).

However, my guess would be that too many Apaches out there are linked to
older openssl versions that do not yet support TLS 1.1 or TLS 1.2.

I have found this a good write-up:
https://www.isecpartners.com/media/106031/ssl_attacks_survey.pdf

Ralph

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] Aside on random numbers (was Re: Opening Discussion: Speculation on BULLRUN)

```On Sep 6, 2013, at 10:03 AM, Perry E. Metzger wrote:

Naively, one could take a picture of the dice and OCR it. However,
one doesn't actually need to OCR the dice -- simply hashing the
pixels from the image will have at least as much entropy if the
position of the dice is recognizable from the image

One could write an  app to do this, but of course the phone is
not exactly a secure platform to begin with...
Ah, but that highlights an essential difference between OCR'ing the image and
just hashing it:  I can easily check, with my own eyes, that the OCR app is
really doing what it claims to be doing.  I have no hope of checking the
hash-based app.  A whole class of attacks is closed off by the OCR technique.

It's not that there aren't other attacks.  The phone could, for example, leak
the generated values, sending them off to Big Brother.  That kind of attack
would, if done correctly, be virtually impossible to detect.  On the other
hand, it's not nearly as valuable as a biased generation attack - Big Brother
would receive streams of random die tosses with little context about what the
resulting values would be used for or how they would be used.  Appropriately
targeted attacks might work - I know Metzger regenerates his keys on the 3rd
of every month at about 8:00 AM, so let's use the values he scans at around
that time as guesses for his base random values - but we're talking quite a
bit of difficulty here - and the more people use the app, and the more often
they make it a habit to toss and scan dice and just discard the results, the
more difficult it becomes.
-- Jerry

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)

```
On 06.09.2013 18:20, Peter Saint-Andre wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 9/6/13 8:36 AM, Perry E. Metzger wrote:

One solution, preventing passive attacks, is for major
browsers and websites to switch to using PFS ciphersuites (i.e.
those based on ephemeral Diffie-Hellmann key exchange).

It occurred to me yesterday that this seems like something all
major service providers should be doing. I'm sure that some voices
will say additional delay harms user experience. Such voices should
be ruthlessly ignored.

+1

In practice, how do we make that happen? On the XMPP network we're
pushing to make sure that all client-to-server and server-to-server
hops are encrypted (yes, I know, per-hop encryption is not enough, we
need end-to-end encryption too). Is there a handy list of PFS-friendly
ciphersuites that I can communicate to XMPP developers and admins so
they can start upgrading their software and deployments?

Thanks!

Peter

yet, one can find this sort of thing in 3rd position when searching
nginx crypto :

http://www.hybridforge.com/blog/nginx-ssl-ciphers-and-pci-compliance

quote :

The developers of Nginx have recently changed the default SSL ciphers to
include the very strong Diffie-Hellman Ephemeral (DHE) cipher. DHE is
used to provide perfect forward secrecy in TLS.

Further reading on Ephermal Diffie-Hellman, PFS and TLS at Wikipedia.org

While I applaud this move on the part of the Nginx dev team there is a
tradeoff and that is slower performance. DHE provides stronger
encryption which in turn requires more computation but here’s where it
gets interesting. To meet today’s PCI DSS crypto standards DHE is not
required. Like many things in life there’s a balance to be struck
between the risk of compromised encryption and the additional expense or
rather the relative loss of connections per second. I’m not a lawyer nor
should this be considered legal advice but I prefer things that go fast
while meeting the necessary PCI compliance criteria.

In order to disable DHE in the server context of the Nginx configuration

ssl_ciphers RC4:HIGH:!aNULL:!MD5:!kEDH;

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
```

### Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)

```On 9/6/2013 9:52 AM, Raphaël Jacquot wrote:
To meet today’s PCI DSS crypto standards DHE is not required.

PCI is about credit card fraud. Mastercard/Visa aren't worried that
criminals are storing all your internet purchase transactions with the
hope they can crack it later; if the FBI/NSA want your CC number they

-Dan Veditz

smime.p7s
Description: S/MIME Cryptographic Signature
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
```

### Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

```
On 6/09/13 04:50 AM, Peter Gutmann wrote:

Perry E. Metzger pe...@piermont.com writes:

At the very least, anyone whining at a standards meeting from now on that
they don't want to implement a security fix because it isn't important to
the user experience or adds minuscule delays to an initial connection or
whatever should be viewed with enormous suspicion.

It isn't the whiners that are the NSA plants, but the people behind
them, egging them on, while also mounting attacks on the competent
honest ones to confuse and bewilder them.

I think you're ascribing way too much of the usual standards committee
crapification effect to enemy action.

The general process is first to push the group into crap, and then to
influence it with competence.  In order to influence, the group's own
competence must be neutralised first.

For example I've had an RFC draft for a
trivial (half a dozen lines of code) fix for a decade of oracle attacks and
whatnot on TLS sitting there for ages now and can't get the TLS WG chairs to
move on it (it's already present in several implementations because it's so
simple, but without a published RFC no-one wants to come out and commit to
it).  Does that make them NSA plants?  There's drafts for one or two more
fairly basic fixes to significant problems from other people that get stalled
forever, while the draft for adding sound effects to the TLS key exchange gets
fast-tracked.  It's just what standards committees do.

And, controlling processes is just what the NSA does.

https://svn.cacert.org/CAcert/CAcert_Inc/Board/oss/oss_sabotage.html

The process of an inside takeover is well known in *certain* circles.
It only takes one or two very smart competent people to take down an
entire organisation.  The mechanisms might well be described as
crapification then exploitation.

This is not to say that the IETF WG chairs are NSA plants, nor that all
or any particular IETF committee is sunk.  Rather, it is to say that it
is very difficult to stop a committee being hopeless, and it's rather
easy to tip a good committee into it.

(If anyone knows of a way of breaking the logjam with TLS, let me know).

In contrast, it is not well known how to repair the damage once done.
The normal method is to abandon ship, swim away, build another ship with
1 or 2 others.

Peter.

iang

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] Sabotaged hardware (was Re: Opening Discussion: Speculation on BULLRUN)

```On Sep 6, 2013, at 11:37 AM, John Ioannidis wrote:
I'm a lot more worried about FDE (full disk encryption) features on modern
disk drives, for all the obvious reasons.

If you're talking about the FDE features built into disk drives - I don't know
anyone who seriously trusts it.  Every secure disk that's been analyzed has
been found to be secured with amateur-level crypto.  I seem to recall one
did something like:  Encrypt the key with AES, then XOR with the result to
encrypt all the data.  Yes, it does indeed use AES

There's very little to be gained, and a huge amount to be lost, be leaving the
crypto to the drive, and whatever proprietary, hacked-up code the bit-twiddlers
who do driver firmware decide to toss in to meet the marketing requirement of
being able to say they are secure.  Maybe when they rely on a published
standard, *and* provide a test mode so I can check to see that what they wrote
to the surface is what the standard says should be there, I might change my
mind.  At least them, I'd be worrying about deliberate attacks (which, if you
can get into the supply chain are trivial - there's tons of space to hide away
a copy of the key), rather than the nonsense we have today.

And if I wanted to be truly paranoid, I'd worry about HSMs to

Now, wouldn't compromising HSM's be sweet.  Not that many vendors make HSM's,
and they are exactly the guys who already have a close relationship with the CI
(crypto-industrial) complex
-- Jerry

/ji

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
```

### Re: [Cryptography] People should turn on PFS in TLS

```On 6 September 2013 18:24, Perry E. Metzger pe...@piermont.com wrote:

On Fri, 6 Sep 2013 18:18:05 +0100 Ben Laurie b...@links.org wrote:
On 6 September 2013 18:13, Perry E. Metzger pe...@piermont.com
wrote:

Google is also now (I believe) using PFS on their connections, and
they handle more traffic than anyone. A connection I just made to
https://www.google.com/ came out as, TLS 1.2, RC4_128, SHA1,
ECDHE_RSA.

It would be good to see them abandon RC4 of course, and soon.

In favour of what, exactly? We're out of good ciphersuites.

I thought AES was okay for TLS 1.2? Isn't the issue simply that
Firefox etc. still use TLS 1.0? Note that this was a TLS 1.2
connection.

Apart from its fragility, AES-GCM is still OK, yes. The problem is that
there's nothing good left for TLS  1.2.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
```

### Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

```
On 2013-09-06 12:31 PM, Jerry Leichter wrote:

Another interesting goal:  Shape worldwide commercial cryptography marketplace to make it more tractable to advanced
cryptanalytic capabilities being developed by NSA/CSS.  Elsewhere, enabling access and exploiting systems
of interest and inserting vulnerabilities.  These are all side-channel attacks.  I see no other reference to
cryptanalysis, so I would take this statement at face value:  NSA has techniques for doing cryptanalysis on certain
algorithms/protocols out there, but not all, and they would like to steer public cryptography into whatever areas they have
attacks against.  This makes any NSA recommendation *extremely* suspect.  As far as I can see, the bit push NSA is making these
days is toward ECC with some particular curves.

The mathematics of ECC is such that one would expect that curves with
backdoors that are difficult to find, or impossible to find except
through construction, exist.

Therefore, one should never employ a particular curve recommended by
NSA, but rather a random or arbitrary curve.

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### [Cryptography] 1024 bit DH still common in Tor network

```Summary: blog posting claims most of the Tor network is still running
older software that uses 1024 bit Diffie-Hellman.

http://blog.erratasec.com/2013/09/tor-is-still-dhe-1024-nsa-crackable.html

I'm not sure how cheap it actually would be to routinely crack DH key
exchanges, but it does seem like it would be valuable for
most Tor nodes to be running newer software anyway.

--
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

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

```
I think that any of OCB, CCM, or EAX are preferable from a security
standpoint, but none of them parallelize as well. If you want to do
a lot of encrypted and authenticated high-speed link encryption,
well, there is likely no other answer. It's GCM or nothing.

OCB parallelizes very well in software and I see no reason it would
not also do so in hardware; each block of both the plaintext and
associated data can be processed independently of the others, and all
of OCB's operations (xor, GF(2^128) doubling, Grey codes) seem like
they would be well suited to a fast hardware implementation. And
actually McGrew and Viega's original 2003 paper on GCM specifically
mentions that OCB scales to high speeds in hardware, though they do
not provide references to specific results.

Jack
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)

```
On 06/09/13 15:36, Perry E. Metzger wrote:

One solution, preventing passive attacks, is for major browsers
and websites to switch to using PFS ciphersuites (i.e. those
based on ephemeral Diffie-Hellmann key exchange).

It occurred to me yesterday that this seems like something all major
service providers should be doing. I'm sure that some voices will say
additional delay harms user experience. Such voices should be
ruthlessly ignored.

Any additional delay will be short - after all, if forward secrecy by
ephemeral key setup (I hate the term PFS, there is nothing perfect about
it) is not used then you have to use something else - usually RSA -

For a desktop, laptop, or even a decent mobile the difference is not
noticeable in practice if the server is fast enough.

However, while the case for forward secrecy is easy to make,
implementing it may be a little dangerous - if NSA have broken ECDH then

using it only gives them plaintext they maybe didn't have before.

Personally, operating on the assumption that NSA have not made a crypto
break is something I'm not prepared to do. I just don't know what that
break is is. I think it's most likely RSA/DH or ECC, but could easily be
wrong.

I don't really care if the break is non-existent, irrelevant or
disinformation - beefing up today's crypto is only hard in terms of
getting people to choose a new updated crypto, and then getting people
to implement it. This happens every so often anyway.

One point which has been mentioned, but perhaps not emphasised enough -
if NSA have a secret backdoor into the main NIST ECC curves, then even
if the fact of the backdoor was exposed - the method is pretty well
known - without the secret constants no-one _else_ could break ECC.

So NSA could advocate the widespread use of ECC while still fulfilling
their mission of protecting US gubbmint communications from enemies
foreign and domestic. Just not from themselves.

Looking at timing, the FIPS 186-3 curves were introduced in July 2009 -
the first hints that NSA had made a cryptanalytic break came in early to
mid 2010.

I'm still leaning towards RSA, but ...

-- Peter Fairbrother
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### [Cryptography] Why prefer symmetric crypto over public key crypto?

```In this oped in the Guardian

http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance

Bruce Schneier writes: Prefer symmetric cryptography over public-key
cryptography. The only reason I can think of is that for public key crypto you
typically use an American (and thus subverted) CA to get the recipients public
key.

What other reasons could there be for this advice?

Best,
Jaap-Henk

(I apologise for typos and being terse; this mail was written on an iPad)

--
Jaap-Henk Hoepman
TNO, Groningen
Dept. of Computer Science
(m) j...@cs.ru.nl
(w) www.cs.ru.nl/~jhh
(m) jaap-henk.hoep...@tno.nl
(t) +31 6 20619554
(t) @xotoxot___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
```

### Re: [Cryptography] Bruce Schneier has gotten seriously spooked

```On Fri, Sep 06, 2013 at 04:25:12PM -0400, Jerry Leichter wrote:
A response he wrote as part of a discussion at
http://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html:

software and silently replacing these with their own versions?

A: (Schneier) Yes, I believe so.

out of band fingerprints of signing key.

Just because active attacks are more expensive than passive attacks
and are fundamentally detectable, don't assume they're not being
used in highly targeted cases.

If you have ever been under telco surveillance, that's enough
effort already spent to warrant slipping you some custom malware with
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

```
On 6/09/13 11:32 AM, ianG wrote:

And, controlling processes is just what the NSA does.

https://svn.cacert.org/CAcert/CAcert_Inc/Board/oss/oss_sabotage.html

Oops, for those unfamiliar with CAcert's peculiar use of secure
browsing, drop the 's' in the above URL.  Then it will securely load.

(thanks Joe!)

iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

```On Fri, 6 Sep 2013 09:03:27 +0200 Kristian Gjøsteen
kristian.gjost...@math.ntnu.no wrote:
As a co-author of an analysis of Dual-EC-DRBG that did not
emphasize this problem (we only stated that Q had to be chosen at
random, Ferguson co were right to emphasize this point), I would

Has anyone, anywhere ever seen someone use Dual-EC-DRBG?

I mean, who on earth would be daft enough to use the slowest
possible DRBG? If this is the best NSA can do, they are over-hyped.

(If you really do want to use Dual-EC-DRBG: truncate more than 16
bits, and don't use NSA's points, choose your own - at random.)

I have re-read the NY Times article. It appears to only indicate that
this was *a* standard that was sabotaged, not that it was the only
one. In particular, the Times merely indicates that they can now
confirm that this particular standard was sabotaged, but presumably
it was far from the only target.

--
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] People should turn on PFS in TLS

```On Fri, 6 Sep 2013 18:56:51 +0100 Ben Laurie b...@links.org wrote:
The problem is that there's nothing good [in the way of ciphers]
left for TLS  1.2.

So, lets say in public that the browser vendors have no excuse left
for not going to 1.2.

I hate to be a conspiracy nutter, but it is that kind of week. Anyone
at a browser vendor resisting the move to 1.2 should be viewed with
deep suspicion.

(Heck, if they're not on the government's payroll, then shame on them
for retarding progress for free. They should at least be charging. And
yes, I'm aware many of the people resisting are probably doing so
without realizing they're harming internet security, but we can no
longer presume that is the motive.)

Chrome handles 1.2, there is no longer any real excuse for the others
not to do the same.

Perry
--
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### [Cryptography] Bruce Schneier has gotten seriously spooked

```A response he wrote as part of a discussion at
http://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html:

and silently replacing these with their own versions?

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

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### [Cryptography] Bruce Schneier calls for independent prosecutor to investigate NSA

```Quoting:

All of this denying and lying results in us not trusting anything
the NSA says, anything the president says about the NSA, or
anything companies say about their involvement with the NSA. We
know secrecy corrupts, and we see that corruption. There's simply
no credibility, and -- the real problem -- no way for us to
verify anything these people might say.

https://www.schneier.com/blog/archives/2013/09/conspiracy_theo_1.html

--
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

```ianG i...@iang.org writes:

And, controlling processes is just what the NSA does.

https://svn.cacert.org/CAcert/CAcert_Inc/Board/oss/oss_sabotage.html

How does '(a) Organizations and Conferences' differ from SOP for these sorts
of things?

Peter.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

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

```Ralph Holz ralph-cryptometz...@ralphholz.de writes:

But for right now, what options do we have that are actually implemented
somewhere? Take SSL. CBC mode has come under pressure for SSL (CRIME, BEAST,
etc.), and I don't see any move towards TLS  1.0.

http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-02 fixes all of
these, I just can't get any traction on it from the TLS WG chairs.  Maybe
they're following
http://svn.cacert.org/CAcert/CAcert_Inc/Board/oss/oss_sabotage.html :-).

Peter.

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### [Cryptography] Washington Post: Google racing to encrypt links between data centers

```Quoting:

Google is racing to encrypt the torrents of information that flow
among its data centers around the world, in a bid to thwart
snooping by the NSA as well as the intelligence agencies of foreign
governments, company officials said on Friday.

The move by Google is among the most concrete signs yet that recent
revelations about the National Security Agency’s sweeping
surveillance efforts have provoked significant backlash within an
American technology industry that U.S. government officials long
courted as a potential partner in spying programs.

--
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
```

### Re: [Cryptography] People should turn on PFS in TLS

```On 6 September 2013 18:13, Perry E. Metzger pe...@piermont.com wrote:

Google is also now (I believe) using PFS on their connections, and
they handle more traffic than anyone. A connection I just made to
https://www.google.com/ came out as, TLS 1.2, RC4_128, SHA1,
ECDHE_RSA.

It would be good to see them abandon RC4 of course, and soon.

In favour of what, exactly? We're out of good ciphersuites.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
```

### Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)

```
On 6/09/13 20:15 PM, Daniel Veditz wrote:

On 9/6/2013 9:52 AM, Raphaël Jacquot wrote:

To meet today’s PCI DSS crypto standards DHE is not required.

PCI is about credit card fraud.

So was SSL ;-)  Sorry, couldn't resist...

Mastercard/Visa aren't worried that
criminals are storing all your internet purchase transactions with the
hope they can crack it later; if the FBI/NSA want your CC number they

That's what the crims do to, they ask for all the numbers, they don't
bother much with SSL.

iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] tamper-evident crypto?

```-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/05/2013 06:48 PM, Richard Clayton wrote:
so you'd probably fail to observe any background activity that tested
whether this information was plausible or not  and then some chance
event would occur that caused someone from Law Enforcement (or even a
furnace maintenance technician) to have to look in the basement.

Well, I'm sure /somebody/ on this list is clever enough to
arrange countersurveillance and counterintrusion measures...
a) especially given that detecting surveillance and/or
intrusion is the whole point of the exercise;
b) especially given that we have all the time in the world
to arrange boatloads of nanny-cams and silent alarms etc.,
arranging everything in advance, before provoking the
opponent;
c) especially given that we know it's a trap, and the
opponent probably isn't expecting a trap;
d) especially given that the opponent has a track record
of being sometimes lazy ... for instance by swearing that
the fruits of illegal wiretaps came from a confidential
informant who has been reliable in the past and using that
as the basis for a search warrant, at which point you've
got them for perjury as well as illegal wiretapping,
*and* you know your information security is broken;
e) especially given that we get to run this operation
more than once.

(assuming that the NSA considered this [kiddie porn]
important enough to pursue)
*) If they don't like that flavor of bait, we can give
them something else.  For example, it is known that
there is a large-diameter pipeline from the NSA to the
DEA.

http://www.washingtonpost.com/blogs/the-switch/wp/2013/08/05/the-nsa-is-giving-your-phone-records-to-the-dea-and-the-dea-is-covering-it-up/
*) Again:  We get to run this operation more than once.

I repeat the question from the very beginning of this thread:
Shouldn't this be part of the /ongoing/ validation of any
data security scheme?

There's a rule that says that you shouldn't claim a crypto
system is secure unless it has been subjected to serious
cryptanalysis.  I'm just taking the next step in this
direction.  If you want to know whether or not the system
is broken, /measure/ whether or not it is broken.

One of the rules in science, business, military planning,
et cetera is to consider /all/ the plausible hypotheses.
Once you consider the possibility that your data security
is broken, the obvious next step is to design an experiment
to /measure/ how much breakage there is.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iD8DBQFSKi2j2FOSJqrRXAoRAtJAAJ9zUubRz66YdcdRM3G3Wpx70TcDtgCgm9tE
xiI/Ikqt4PbbTDZeC0sK9vI=
=UYAV
-END PGP SIGNATURE-
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)

```On 6 September 2013 17:20, Peter Saint-Andre stpe...@stpeter.im wrote:

Is there a handy list of PFS-friendly
ciphersuites that I can communicate to XMPP developers and admins so
they can start upgrading their software and deployments?

Anything with EDH, DHE or ECDHE in the name...
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
```

### Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

```Following up on my own posting:
[The NSA] want to buy COTS because it's much cheap, and COTS is based on
standards.  So they have two contradictory constraints:  They want the stuff
they buy secure, but they want to be able to break in to exactly the same
stuff when anyone else buys it.  [Y]ou have to explain how the goal in NSA's
budget [of influencing the commercial crypto community to move in directions
NSA can attack] could be carried out in a way consistent with the two
constraints.
So here's a thought experiment for a particular approach:  Imagine that it's
the case that half of all possible AES keys are actually pseudo-weak, in the
sense that if you use one of them, some NSA cryptanalytic technique can recover
the rest of your key with acceptable (to NSA) effort.  Their attack fails for
the other half of all possible keys.  Further, imagine that NSA has a
recognizer for pseudo-weak keys.  Then their next step is simple:  Get the
crypto industry to use AES with good, randomizing key generation techniques.
Make sure that there is more than one approved key generation technique,
ideally even a way for new techniques to be added in later versions of the
standard, so that approved implementations have to allow for a choice, leading
them to separate key generation from key usage.  For the stuff *they* use, add
another choice, which starts with one of the others and simply rejects
pseudo-weak keys (or modifies them in some way to produce strong keys.)  T
hen:

- Half of all messages the world sends are open to attack by NSA until the COTS
producers learn of the attack and modify their fielded systems;
- All messages NSA is responsible for are secure, even if the attack becomes
known to other cryptanalytic services.

I would think NSA would be very happy with such a state of affairs.  (If they
could arrange it that 255/256 keys are pseudo-weak - well, so much the better.)

Is such an attack against AES *plausible*?  I'd have to say no.  But if you
were on the stand as an expert witness and were asked under cross-examination
Is this *possible*?, I contend the only answer you could give is I suppose
so (with tone and body language trying to signal to the jury that you're being
forced to give an answer that's true but you don't in your gut believe it).

Could an encryption algorithm be explicitly designed to have properties like
this?  I don't know of any, but it seems possible.  I've long suspected that
NSA might want this kind of property for some of its own systems:  In some
cases, it completely controls key generation and distribution, so can make sure
the system as fielded only uses good keys.  If the algorithm leaks without
the key generation tricks leaking, it's not just useless to whoever grabs onto
it - it's positively hazardous.  The gun that always blows up when the bad guy
tries to shoot it
-- Jerry

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

```
On 6/09/13 08:04 AM, John Kelsey wrote:

It is possible Dual EC DRBG had its P and Q values generated to insert a
trapdoor, though I don't think anyone really knows that (except the people who
generated it, but they probably can't prove anything to us at this point).
It's also immensely slower than the other DRBGs, and I have a hard time seeing
why anyone would use it.  (But if you do, you should generate your own P and Q.)

Think bigger picture, think about the intervention possibilities.

E.g., when the NSA goes to a major commercial supplier who is about to
ship some product that is SP 800-90, they can agree to indeed do that,
but switch around to the Dual EC DBRG.  And still maintain their
standards compliance.  As it is likely a closed source, hush-hush area,
it can even be done without the adversary (who was once called the
customer) knowing.

...

Where do the world's crypto random numbers come from?  My guess is
some version of the Windows crypto api and /dev/random
or /dev/urandom account for most of them.

I'm starting to think that I'd probably rather type in the results of
a few dozen die rolls every month in to my critical servers and let
AES or something similar in counter mode do the rest.

A d20 has a bit more than 4 bits of entropy. I can get 256 bits with
64 die rolls, or, if I have eight dice, 16 rolls of the group. If I
mistype when entering the info, no harm is caused. The generator can
be easily tested for correct behavior if it is simply a block cipher.

If you're trying to solve the problem of not trusting your entropy source, this
is reasonable, but it doesn't exactly scale to normal users.  Entropy
collection in software is a pain in the ass, and my guess is that the
overwhelming majority of developers are happy to punt and just use the OS'
random numbers.

Right.  If you don't care, just use what the OS provides.  /dev/urandom
or CAPI or whatever.  If you do care, you should implement a
collector-mixer-DRBG design yourself.

iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)

```
we were brought in as consultants to a small client/server startup that wanted to do payment transactions on
their server, they had this technology they called SSL they wanted to use, the result is now
frequently called electronic commerce. The two people at the startup responsible for the
commerce server we had worked with in prior life on parallel Oracle cluster scaleup.

As part of mapping SSL technology to payment transactions we had to audit operations
selling SSL digital certificates and also came up with recommendations on how browsers
and servers would deploy and use the technology. Almost immediately several of the recommendations
were violated, resulting in some number of the exploits that continue to this day.

We were then tangentially involved in the Cal. data breach notification legislation,
having been brought in to help wordsmith the Cal. electronic signature legislation. Many
of the parties were heavily involved in privacy issues and had done numerous, indepth,
public surveys. The number one issue was identity theft of the form involving
fraudulent financial transactions ... frequently as result of data breach. The issue was
nothing was being done about the problems and so it was hoped that the publicity from the
notifications might motivate corrective action. Part of the issue is normally
institutions take security measures in self-interests ... however, the institutions
having breaches weren't at risk, it was the account holders.

PCI DSS shows up some time after Cal. data breach notification and frequently the joke is
that if you have a breach ... you loose your PCI DSS certification. It turns out that
there was a number of Federal data breach notification bills introduced,
preempting state legislation and effectively eliminating notification requirements ...
citing PCI DSS industry effort as justification for no longer needing notification.

Another problem we've frequently pointed out is current paradigm with dual
use paradigm and even if the planet was covered in miles of information hiding
encryption, it wouldn't stop data leakage. Account information is used for authenticating
new transactions and so has a requirement that it be kept totally confidential and never
divulged to anybody ... but at the same time, account information is needed in dozens of
business processes at millions of locations around the planet.

disclaimer: we were co-authors of the x9.59 financial transaction standard that
slightly tweaked the current payment paradigm and eliminated the dual-use
characteristic  which then also eliminated the need to hide account
information and as a result it also eliminated the need for SSL to hide account
information in electronic commerce transactions  eliminating the major
requirement for SSL in the world today.

--
virtualization experience starting Jan1968, online at home since Mar1970
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### [Cryptography] Matthew Green on BULLRUN

```Some interesting nuggets here, including the fact that he explicitly
calls out the existence of NSA's new HUMINT division that infiltrates
corporations for a living.

http://blog.cryptographyengineering.com/2013/09/on-nsa.html

--
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] NSA and cryptanalysis

```
On 6/09/13 04:44 AM, Peter Gutmann wrote:

John Kelsey crypto@gmail.com writes:

If I had to bet, I'd bet on bad rngs as the most likely source of a
breakthrough in decrypting lots of encrypted traffic from different sources.

If I had to bet, I'd bet on anything but the crypto.  Why attack when you can
bypass [1].

Peter.

[1] From Shamir's Law [2], crypto is bypassed, not penetrated.
[2] Well I'm going to call it a law, because it deserves to be.
[3] This is a recursive footnote [3].

It looks like it is all of the above.  These are the specific
interventions I have seen mention of so far:

* weakened algorithms/protocols for big players (e.g., GSM, Cisco)
* weakening of RNGs
* inside access by 'covert agents' to hand over secrets (e.g., big 4)
* corruption of the standards process (NIST 2006?)
* corruption of certification process (CSC)
* black ops to steal keys
* black ops to pervert systems

Which makes sense.  Why would the biggest player just do one thing ?
No, they are going to do everything within their power.  They'll try all
the tricks.  Why not, they've got the money...

What is perhaps more interesting is how these tricks interplay with each
other.  That's something that we'll have trouble seeing and imagining.

iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] Bruce Schneier has gotten seriously spooked

```On 6 September 2013 16:25, Jerry Leichter leich...@lrw.com wrote:

software and silently replacing these with their own versions?

http://c2.com/cgi/wiki?TheKenThompsonHack

(and many other references)
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
```

### Re: [Cryptography] Washington Post: Google racing to encrypt links between data centers

```Right.

Maybe some AES32?

2013/9/7 Perry E. Metzger pe...@piermont.com

Quoting:

Google is racing to encrypt the torrents of information that flow
among its data centers around the world, in a bid to thwart
snooping by the NSA as well as the intelligence agencies of foreign
governments, company officials said on Friday.

The move by Google is among the most concrete signs yet that recent
revelations about the National Security Agency’s sweeping
surveillance efforts have provoked significant backlash within an
American technology industry that U.S. government officials long
courted as a potential partner in spying programs.

--
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
```

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

```-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sep 6, 2013, at 11:41 AM, Jack Lloyd ll...@randombit.net wrote:

I think that any of OCB, CCM, or EAX are preferable from a security
standpoint, but none of them parallelize as well. If you want to do
a lot of encrypted and authenticated high-speed link encryption,
well, there is likely no other answer. It's GCM or nothing.

OCB parallelizes very well in software and I see no reason it would
not also do so in hardware; each block of both the plaintext and
associated data can be processed independently of the others, and all
of OCB's operations (xor, GF(2^128) doubling, Grey codes) seem like
they would be well suited to a fast hardware implementation. And
actually McGrew and Viega's original 2003 paper on GCM specifically
mentions that OCB scales to high speeds in hardware, though they do
not provide references to specific results.

I confess that I might not explain very well a controversy that I lie on a
different side of -- I'm using CCM, myself.

My above explanation is what GCM proponents have told me -- that if you are
doing multiple high-speed streams and have hardware you can throw at it, then
it's what you want.

There is/was an additional OCB issue specifically that there is/was IP around
it. Univ. of California has recently relaxed them, but it's still needlessly
complex. I confess I tend to think of OCB as a footnote -- the cool thing we
can't use -- only.

My decision tree is that I think in a perfect world, one would use OCB, but the
IP nixes it. CCM was created specifically because it's not OCB, and EAX as an
alternative to the alternative CCM. GCM is too easy to screw up and is slow in
software (yes, there's galois multiply on Intel processors, but most of what I
do is ARM). There's nothing wrong with EAX, but CCM is there and standardized
in a number of places. Other people might end up with a different place for
their own reasons. I don't think that any of them are bad, including the
decision of using GCM and just making sure you do it right.

Jon

-BEGIN PGP SIGNATURE-
Version: PGP Universal 3.2.0 (Build 1672)
Charset: us-ascii

wj8DBQFSKm8XsTedWZOD3gYRAjUuAKC2sqp6C0wCrg+KydfhroBjYahqjwCgo+4d
tLx/6e9TaWxRuknLWHEvF5w=
=M7s8
-END PGP SIGNATURE-
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] People should turn on PFS in TLS

``` PEM == Perry E Metzger pe...@piermont.com writes:

PEM Anyone at a browser vendor resisting the move to 1.2 should be
PEM viewed with deep suspicion.

Is anyone?

NSS has 1.2 now; it is, AIUI, in progress for ff and sm.

Chromium supports it (as of version 29, it seems).

Opera supports 1.2 (at least as of version 12, maybe earlier?).

Arora 0.11.0 doesn't seem to provide a way to check

I don't see a way to get lynx or w3m (text browsers), midori, luakit or
xombrero (webkit-gtk) or qupzilla (webkit-qt) to report the tls version
details.  So I cannot confirm what webkit can do.

A bug report from 2011 for polarssl mentions that ie9 can do 1.2.

I don't think there is anything else I can test.

With it in openssl, gnutls, nss, polarssl, et alia support seems pretty
complete.  It will take some time for the current ff alpha to filter
down to a release, but otherwise things look good on the 1.2 front.

-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] People should turn on PFS in TLS

```-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/06/2013 01:13 PM, Perry E. Metzger wrote:

Google is also now (I believe) using PFS on their connections, and
they handle more traffic than anyone. A connection I just made to
https://www.google.com/ came out as, TLS 1.2, RC4_128, SHA1,
ECDHE_RSA.

There may be limits to how far they've deployed PFS on their
user-facing services around the world at this time.  I just accessed
encrypted.google.com and Gmail from home, and here's what the Calomel
SSL Validation add-on for Firefox (with HTTPS Finder and
HTTPS-Everywhere, verified manually) and is telling me:

Symmetric cipher RC4 (weak 10/49)
Symmetric key length 128 bits (weak 8/19)
Cert issued by Google, Inc, US SHA-1 with RSA @ 2048 bit (MODERATE 2/6)

Manually keying https://www.google.com/ into my browser returned the
same thing.

Gmail shows me this:
Symmetric cipher RC4 (weak 10/39)
Symmetric key length 128 bits (weak 8/19)
Cert issued by Google, Inc, US SHA-1 with RSA @ 2048 bit (MODERATE 2/6)

https://www.google.com/analytics is returning the same as Gmail.

Symmetric cipher Camellia (STRONG 39/39)
Symmetric key length 256 bits (STRONG 19/19)
Cert issued by CAcert, Inc. SHA-1 with RSA @ 4096 bit (MODERATE 2/6)

I'd be very interested in what other people see where they are.
Alternatively, my browser's SSL/TLS configuration could be hosed, in
which case I'm completely off base and probably need to torch my
browser profile and start over.

- --
The Doctor [412/724/301/703] [ZS]
Developer, Project Byzantium: http://project-byzantium.org/

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F  DD89 3BD8 FF2B 807B 17C1

Be the strange that you want to see in the world. --Gareth Branwyn

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlIqdHwACgkQO9j/K4B7F8Ez8QCg0BvBhYA5EFVrTRwEqUCJFh0Y
Pd8AoJGg5Zg+sKL4NdK76JxcwT1Yvcmb
=T/D2
-END PGP SIGNATURE-
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] People should turn on PFS in TLS

```-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/06/2013 01:13 PM, Perry E. Metzger wrote:

Google is also now (I believe) using PFS on their connections, and
they handle more traffic than anyone. A connection I just made to
https://www.google.com/ came out as, TLS 1.2, RC4_128, SHA1,
ECDHE_RSA.

Addendum: Calomel SSL Validation has an interesting set of
configuration options, which may be of interest and discussion.  Two
noteworthy ones:

- - FIPS 140-2 restricted 256 bit ciphers
- - ...AND limit to Perfect Forward Secrecy ciphers

- --
The Doctor [412/724/301/703] [ZS]
Developer, Project Byzantium: http://project-byzantium.org/

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F  DD89 3BD8 FF2B 807B 17C1

Be the strange that you want to see in the world. --Gareth Branwyn

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlIqdcYACgkQO9j/K4B7F8EKrQCguaWu9UGXABSkUwKJ7A+9n7NX
KUoAn3D1AF+NW8KIu9BoIDoxllKkE2+K
=GSYs
-END PGP SIGNATURE-
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

```-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sep 6, 2013, at 4:42 AM, Jerry Leichter leich...@lrw.com wrote:

Argh!  And this is why I dislike using symmetric and asymmetric to
describe cryptosystems:  In English, the distinction is way too brittle.
Just a one-letter difference - and in including or not the letter physically
right next to the s.

This is why I try to say public key and symmetric key whenever possible.

Jon

-BEGIN PGP SIGNATURE-
Version: PGP Universal 3.2.0 (Build 1672)
Charset: us-ascii

wj8DBQFSKnGAsTedWZOD3gYRAhWzAJ9HfLc3nVuzIGMrywrY83vi63AlLgCeJdhJ
NytYPZWee7tNMqdjI5TMkhQ=
=vdDZ
-END PGP SIGNATURE-
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

```-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sep 6, 2013, at 6:23 AM, Jerry Leichter leich...@lrw.com wrote:

Is such an attack against AES *plausible*?  I'd have to say no.  But if you
were on the stand as an expert witness and were asked under cross-examination
Is this *possible*?, I contend the only answer you could give is I suppose
so (with tone and body language trying to signal to the jury that you're
being forced to give an answer that's true but you don't in your gut believe
it).

I'd be happy to give a different answer, like -- almost certainly not.

Could an encryption algorithm be explicitly designed to have properties like
this?  I don't know of any, but it seems possible.  I've long suspected that
NSA might want this kind of property for some of its own systems:  In some
cases, it completely controls key generation and distribution, so can make
sure the system as fielded only uses good keys.  If the algorithm leaks
without the key generation tricks leaking, it's not just useless to whoever
grabs onto it - it's positively hazardous.  The gun that always blows up when
the bad guy tries to shoot it

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.

To me, it's like getting a cheap supply of gold and then deciding you'll make
bullets out of it instead of lead. To riff on that analogy, it feels like
you're suggesting that they would shoot themselves in the foot because they
know that the bullet fragments will hurt their opponent.

That's why I say almost certainly not. It suggests irrationality beyond my
personal ken. It's something I classify colloquially as too stupid to live.

My assumptions about the NSA are that they're smart, clever, and practical.
Conjectures about their behavior that deviate from any of those axes ring false
to the degree that they deviate from that.

My conjectures start with assuming they're at least as smart as me, and I start
with what would I do if I were them? I think they're smart enough not to
attack the strong points of the system, but the weak points. I think they're
smart enough to prefer operating in stealth.

Yeah, yeah, sure, if with those resources I stumbled into a fundamental
mathematical advantage, I'd use it. But I would use it to maximize my gain, not
to be gratuitously sneaky.

The math we know about block ciphers suggests (not proves, suggests) that a
back door in a cipher is impractical, because it would imply the holy grail of
public key systems -- fast, secure, public key crypto. It suggests secure
trapdoor functions that can be made out of very simple components.

If I found one, it would be great, but I'd devote my resources to places where
I technology is on my side. Those include network security and software
security, along with traffic analysis.

If I wanted to devote research resources, I'd be looking closely at
language-theoretic security. I'd be paying close attention to the fantastic
things that have come out of there.

The stuff that Bangert, Bratus, Shapiro, and Smith did on turning an MMU into a
Turing machine is where I'd devote research, as well as their related work on
weird machines.

I apologize for repeating myself, but I'd fight the next war, not the last one.

Jon

-BEGIN PGP SIGNATURE-
Version: PGP Universal 3.2.0 (Build 1672)
Charset: us-ascii

wj8DBQFSKno7sTedWZOD3gYRAjMUAJ9qDQcQZVr/1580qZStlu/7fFgLIwCg2U5r
WFth65Vi4GIDF1wu5oVukYs=
=M/f+
-END PGP SIGNATURE-
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### [Cryptography] ADMIN: Reminder, yet again...

```Sadly it seems I need to repeat this:

We've got a very large number of participants on this list, and
volume has gone way up at the moment thanks to current
events. To make the experience pleasant for everyone please:

1) Cut down the original you're quoting to only the relevant portions
to minimize the amount of reading the 1600 people who will
be seeing your post will have to do.

2) Do not top post. I've explained why repeatedly.

3) Try to make sure what you are saying is interesting enough and
on topic. Minor asides etc. are not.

The list is moderated for a reason, and if you top post a one liner
followed by a 75 line intact original, be prepared to see a rejection
message.

Perry
--
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### [Cryptography] NYTimes: Legislation Seeks to Bar N.S.A. Tactic in Encryption

```Quoting:

After disclosures about the National Security Agency’s stealth
campaign to counter Internet privacy protections, a congressman has
proposed legislation that would prohibit the agency from installing
“back doors” into encryption, the electronic scrambling that
protects e-mail, online transactions and other communications.

Representative Rush D. Holt Jr., a New Jersey Democrat who is
also a physicist, said on Friday he believed that the N.S.A. was
overreaching and could hurt American interests, including the
reputations of American companies whose products the agency may
have altered or influenced.

“We pay them to spy,” Mr. Holt said. “But if in the process they
degrade the security of the encryption we all use, it’s a net
national disservice.”

http://www.nytimes.com/2013/09/07/us/politics/legislation-seeks-to-bar-nsa-tactic-in-encryption.html

--
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
```

### Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

```...and to add to all that, how about the fact that IPsec was dropped as a 'must
implement' from IPv6 sometime after 2002?

signature.asc
Description: Message signed with OpenPGP using GPGMail
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
```

### Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

```
On 9/6/2013 1:05 PM, Perry E. Metzger wrote:
I have re-read the NY Times article. It appears to only indicate that
this was *a* standard that was sabotaged, not that it was the only
one. In particular, the Times merely indicates that they can now
confirm that this particular standard was sabotaged, but presumably it
was far from the only target.

WEP was so bad it's hard to think anyone could have done that intentionally.
OTOH, stupidity usually wins out over malice.  Besides, I don't believe
that WEP

fits the other attributes of the story.

But seriously, sabotage can manifest itself in a lot of different ways.
Perhaps their

HUMINT promoted attitudes of jealously and backstabbing. Those means would
likely be more efficient means to get something you want. Eventually
everyone
gets weary and will agree on practically anything even if it isn't near
optimal,

especially it it had been suggested early on and then discarded because the
committee decided they could do better. There's also politics, bribes,
and other

gratuity they might offer.

There's more than one one to dumb down standards besides just suggesting
the wording of some crypto details which is what everyone seems to be
assuming they did. Maybe all they did was encourage an dumb idea that
someone else offered.

-kevin
--
Blog: http://off-the-wall-security.blogspot.com/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We *cause* accidents.-- Nathaniel Borenstein
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] Bruce Schneier has gotten seriously spooked

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

Why would they perform the attack only for encryption software? They
could compromise people's laptops by spiking any popular app.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] People should turn on PFS in TLS

```On Fri, Sep 6, 2013 at 5:34 PM, The Doctor dr...@virtadpt.net wrote:

Symmetric cipher RC4 (weak 10/49)
Symmetric key length 128 bits (weak 8/19)
Cert issued by Google, Inc, US SHA-1 with RSA @ 2048 bit (MODERATE 2/6)

First time I've heard of 128-bit symmetric called weak... Sure, RC4
isn't awesome but they seem to be saying that 128-bit keys per se are
weak.

Symmetric cipher Camellia (STRONG 39/39)
Symmetric key length 256 bits (STRONG 19/19)
Cert issued by CAcert, Inc. SHA-1 with RSA @ 4096 bit (MODERATE 2/6)

Without good server authentication, the other stuff doesn't matter.
With Chrome, you get key pinning when talking to some sites (including
Google sites, Tor, and Twtitter); I'd much rather have that and only
128-bit symmetric. Also, I don't know why you weren't getting forward
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] In the face of cooperative end-points, PFS doesn't help

```It seems to me that while PFS is an excellent back-stop against NSA
having/deriving a website RSA key, it does *nothing* to prevent the kind of
cooperative endpoint scenario that I've seen discussed in other
forums, prompted by the latest revelations about what NSA has been up to.

But if your fave website (gmail, your bank, etc) is disclosing the
session-key(s) to the NSA, or has deliberately-weakened session-key
negotiation in

I agree that if the scenario is NSA has a database of RSA keys of
'popular sites' then PFS helps tremendously.  But if the scenario goes
deeper
into the cooperative endpoint territory, then waving the PFS flag
is perhaps like playing the violin on the deck of the Titantic.

Do we now strongly suspect that NSA have a flotilla of TWIRL (or
similar) machines, so that active cooperation of websites isn't strictly
necessary

to derive their (weaker) RSA secret keys?

--
Marcus Leech
Principal Investigator
http://www.sbrac.org

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] NSA hates sunshine

```  As of Jan-2014 CAs are forbidden from issuing/signing anything less than
2048 certs.

For some value of forbidden. :-)

Yeah, just like employees at big companies are forbidden to reveal
how they are collaborating with NSA.

Years ago I heard what happened when George Davida filed a patent on
something related to encryption, all the way back in 1978, and
eventually received a communication from the government telling him
that his patent was subject to patent secrecy, that it would never
issue, and that he could not even tell anyone that it had been
suppressed, nor could he ever tell anyone how his invention worked.
In theory, the law was all on the NSA's and the patent office's side.
But in fact, they were in a very weak position.

Instead of acquiescing, Davida shouted it to the housetops, engaged
involved his Congressperson, etc.  Within months, the secrecy order
was rescinded.

NSA hates sunshine.  NSA secrecy relies on the cowardice of most
people.  Courage is all it takes to beat them.

If NSA tries to shut you up, just shine a lot of attention on their
attempt to shut you up.  Spread the information that they are trying
to suppress, far and wide.  Send copies to a dozen random post-office
boxes in different cities, asking the recipient to physically bring it
in to their local newspaper.  Leave your cellphone at home, then stash
copies in places that you don't frequent, so that government agents
can't come raid your house and office and steal all copies of what
they're trying to suppress.  In my case I posted something like this
(a suppressed paper by Ralph Merkle) to Usenet, and it was suddenly on
thousands of servers overnight.

NSA habitually decides that the publicity that their activities get
from any continued effort to suppress the information is FAR worse
than the damage caused by the initial release of the info.  Any
efforts they make to shut you up, prosecute you, jail you, etc give
you a perfect soapbox, and the attention of the news media and the
public.  Keep repeating the info, from your jail cell if necessary,
and you're likely to win.  Because if NSA relents, your revelations
become last week's news and get a lot less public attention.  When
NSA found out I had copies of an early encryption tutorial that they
considered classified (I was suing them under FOIA to get a copy, but
then found copies in a public library), they first tried to persuade
my lawyer to bring in all the copies so we can secure them in a safe
place.  That's NSA-ese for throw them down a deep hole where you'll
never see them again.  When we refused, and instead contacted the New
York Times, which printed a story about the attempted suppression, NSA
and DoJ buckled within one day.  (Indeed, the way I found out they had
suddenly declassified the document is that they called the NYT
reporter to tell him.  They never did tell me; I got the news from the
reporter.)

As part of suing the government, the Al Haramain foundation
accidentally received a government report making it clear that the
government had illegally wiretapped their phone calls.  They noticed
this but it took the government 60 days to notice.  Unfortunately,
them all over the world and to the press, they did what the government
asked, and destroyed all their copies of the document.  Once all
copies of the document were gone, NSA went to the court and claimed
first that the whole thing was a state secret and couldn't proceed,
and then second that the group didn't have any standing to challenge
the wiretaps in court because Al Haramain (now) had zero evidence that
the taps had even occurred.  The foundation and their lawyers have
literally spent years of work recovering from that one mistake, and
only the kind indulgence of a smarter than average judge enabled their
lawsuit to survive at all.  See this story by one of their lawyers:

http://www.salon.com/2008/07/09/alharamain_lawsuit/

Don't make the same mistake when NSA, or their minions at the FBI or
FISA or DoJ come to threaten YOU to suppress information that came to you
through no fault of your own.

John Gilmore

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

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

```
On Sep 6, 2013, at 6:13 AM, Jaap-Henk Hoepman j...@cs.ru.nl wrote:

In this oped in the Guardian

http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance

Bruce Schneier writes: Prefer symmetric cryptography over public-key
cryptography. The only reason I can think of is that for public key crypto
you typically use an American (and thus subverted) CA to get the recipients
public key.

What other reasons could there be for this advice?

Public-key cryptography is less well-understood than symmetric-key
cryptography. It is also tetchier than symmetric-key crypto, and if you pay
attention to us talking about issues with nonces, counters, IVs, chaining
modes, and all that, you see that saying that it's tetchier than that is a
warning indeed.

The magic of public key crypto is that it gets rid of the key management
problem -- if I'm going to communicate with you with symmetric crypto, how do I
get the keys to you? The pain of it is that it replaces it with a new set of
problems. Those problems include that the amazing power of public-key crypto
tempts one to do things that may not be wise.

Jon

PGP.sig
Description: PGP signature
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
```

### Re: [Cryptography] Using Raspberry Pis

```On 26 August 2013 22:43, Perry E. Metzger pe...@piermont.com wrote:

(I would prefer to see hybrid capability systems in such
applications, like Capsicum, though I don't think any such have been
ported to Linux and that's a popular platform for such work.)

FWIW, we're working on a Linux port of Capsicum. Help is always welcome :-)
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
```

### Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

```On Sep 6, 2013, at 8:22 PM, John Gilmore g...@toad.com wrote:

Speaking as someone who followed the IPSEC IETF standards committee
pretty closely, while leading a group that tried to implement it and
make so usable that it would be used by default throughout the
Internet, I noticed some things:

...and to add to all that, how about the fact that IPsec was dropped as a 'must
implement' from IPv6 sometime after 2002?

signature.asc
Description: Message signed with OpenPGP using GPGMail
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
```

### Re: [Cryptography] Bruce Schneier has gotten seriously spooked

```-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/06/2013 08:48 PM, Chris Palmer wrote:

Why would they perform the attack only for encryption software?
They could compromise people's laptops by spiking any popular app.

What is more important to them: A single system, or all of the comms
going into and coming out of it?

- --
The Doctor [412/724/301/703] [ZS]
Developer, Project Byzantium: http://project-byzantium.org/

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F  DD89 3BD8 FF2B 807B 17C1

Too bizarre for real life, too normal to wind up on Art Bell.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlIqngUACgkQO9j/K4B7F8EtYgCgtMPqxWguJq/ey3jj/jsPFA3V
iD0AoOSHbT8ZLZ7YxNLqdy5uOiS/6o4p
=DGj7
-END PGP SIGNATURE-
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] People should turn on PFS in TLS

```-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/06/2013 09:02 PM, Chris Palmer wrote:

First time I've heard of 128-bit symmetric called weak... Sure,
RC4 isn't awesome but they seem to be saying that 128-bit keys per
se are weak.

calomel.org may be erring on the side of weak due to known
vulnerabilities in RC4.

Without good server authentication, the other stuff doesn't
matter.

I am inclined to agree with you.

With Chrome, you get key pinning when talking to some sites
(including Google sites, Tor, and Twtitter); I'd much rather have
that and only 128-bit symmetric. Also, I don't know why you
weren't getting forward secrecy; check your Firefox configuration.

I did some poking around inside its configuration and it does not seem
to be negotiating upward in strength, but for whatever it can get (see
other post this evening).  I am uncertain as to why; some
investigation is in order, but slash/burn/upgrade may be safest.

- --
The Doctor [412/724/301/703] [ZS]
Developer, Project Byzantium: http://project-byzantium.org/

PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F  DD89 3BD8 FF2B 807B 17C1

Too bizarre for real life, too normal to wind up on Art Bell.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlIqok4ACgkQO9j/K4B7F8HX2ACZAStTl0wR/JJqI7n182jLX6mD
5i0AnAopo0YASsPGYVVntF9KKUwwrpRN
=9Acb
-END PGP SIGNATURE-
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

```On Sep 6, 2013, at 8:58 PM, Jon Callas wrote:
I've long suspected that NSA might want this kind of property for some of
its own systems:  In some cases, it completely controls key generation and
distribution, so can make sure the system as fielded only uses good keys.
If the algorithm leaks without the key generation tricks leaking, it's not
just useless to whoever grabs onto it - it's positively hazardous.  The gun
that always blows up when the bad guy tries to shoot it

We know as a mathematical theorem that a block cipher with a back door *is* a
public-key system.
I'm sorry, but this is just nonsense.  You're starting with informal, rough
definitions and claiming a mathematical theorem.

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 said all this before.  A back door doesn't have to be fast.  It doesn't have
to be implementable using amounts of memory that are practical for a fielded
system.  It may require all kinds of expensive pre-computation to be useful at
all.  It just has to allow practical attacks.  A back door that reduced the
effective key size of AES to 40 bits would amount to an effective break of AES,
but would be a public key system only in some very technical and
uninteresting sense.

And none of this is relevant to whether one could have a system with many weak
keys.  Some kind of structure in the round computation structure would be an
obvious place to look.

In fact, now that I think of it, here's a rough example of such a system:  Take
any secure round-based block cipher and decide that you're not going to use a
round computation at all - you'll let the user specify the full expanded
per-round key.  (People proposed doing this with DES as a way of getting beyond
the 56-bit key size.  It didn't work - DES is inherently good for no more than
56 bits, more or less.  In general doing this with any decent block cipher
won't make it any stronger.  But that's not the point of the example.)  There
are now many weak keys - all kinds of repetitive structures allow for slide
attacks, for example.  Every bad way of designing a round computation
corresponds to a set of weak full keys.  On the other hand, for a certain
subset of the keys - those that could have been produced by the original (good)
round computation - it's *exactly* the original cipher, with *exactly* the
original security guarantees.  If I carefully use only keys from that se
t, I've lost nothing (other than wasted space for a key longer than it needs
to be).

So now I have a block cipher that has two sets of keys.  One set makes it as
secure as the original cipher; one set makes it easy to break - my back door.
Have I just invented a new public key system?
-- Jerry

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

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

```

The magic of public key crypto is that it gets rid of the key
management problem -- if I'm going to communicate with you with
symmetric crypto, how do I get the keys to you? The pain of it is that
it replaces it with a new set of problems. Those problems include that
the amazing power of public-key crypto tempts one to do things that
may not be wise.

I find public-key cryptography to be full of dirty little secrets.
Some of the notions inherent in public-key *infrastructure* are, on the
face of them,
preposterous.  Consider the notion of a certificate authority.  I am
to trust some third party (the CA) that I've never met, and have not the
slightest
reason to trust, is able to make a believable assertion about the
identity (and corresponding public-key binding), of some *other* party
I've never
met, and have no real reason to trust.  It always struck me as
another instance of there's no problem in CS that can't be solved by
layer of abstraction.   I think this is an instance of a general
problem with digitally-signed documents of all kinds: confusion about
exactly what they
are--a signature on a document (like a certificate) says nothing
about the *essential truth* of the statements contained within the document.
When SlushySign issues a certificate for www.crowbars-r-us.com,
there's a subtle distinction between we believe this to be the
appropriate binding
between this public-key, and an entitity known as
www.crowbars-r-us.com  and this really is the binding between this
pubic-key, and the entity you

all know as www.crowbars-r-us.com.

I started thinking about the essential truth problem back when the
whole TPM thing was popular, and proponents were talking as if the digital
signature of a computer stating that it was sane was somehow the
same is said computer actually being sane.   Absent independent
verification,
there's no way to distinguish a strongly-signed lie from a
strongly-signed truth.   That isn't necessarily a problem that's
confined to PK systems.

Any digital-signature scheme has that problem.

The other thing that I find to be a dirty little secret in PK systems
is revocation.  OCSP makes things, in some ways, better than CRLs, but
I still
find them to be a kind of swept under the rug problem when people
are waxing enthusiastic about PK systems.

However, PK is the only pony we've managed to bring to this circus, so,
we we make do with making the dirty little secrets as inoffensive as
we can.

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### [Cryptography] I have to whistle to blow...

```... but I must scream.

http://kebesays.blogspot.com/2013/09/i-have-no-whistle-to-blow-but-i-must.html

FYI, and thanks,
Dan McD.

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

```

### Re: [Cryptography] Using Raspberry Pis

```
On 09/07/2013 12:04 AM, Ben Laurie wrote:

On 26 August 2013 22:43, Perry E. Metzger pe...@piermont.com
mailto:pe...@piermont.com wrote:

(I would prefer to see hybrid capability systems in such
applications, like Capsicum, though I don't think any such have been
ported to Linux and that's a popular platform for such work.)

FWIW, we're working on a Linux port of Capsicum. Help is always
welcome :-)

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
I implemented a lightweight, tightly-focused (well, it started out that
way), capabilities-like system for Android kernels last year. It was a
monumental PITA
largely due to interior kernel-side APIs changing so frequently
across kernel versions.

We had mechanisms for binding capabilities to ELF binaries in a way
that the kernel could verify.

The project failed, largely because it kept being dragged around by
marketing so often, that we never got it really nicely robust in any
given direction.
This week, it's a floor polish.  Next week, it's a turbine
maintenance system.

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
```