Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-06 Thread John Kelsey
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

2013-09-06 Thread John Kelsey


Sent from my iPad

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))
 
 Could you determine, just from black-box access to H1, that it's equally bad 
 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

2013-09-06 Thread John Kelsey

...
 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

2013-09-06 Thread Perry E. Metzger
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)

2013-09-06 Thread Perry E. Metzger
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)

2013-09-06 Thread Perry E. Metzger
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)

2013-09-06 Thread Perry E. Metzger
  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?

2013-09-06 Thread Dirk-Willem van Gulik

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

2013-09-06 Thread Eugen Leitl
On Thu, Sep 05, 2013 at 04:11:57PM -0400, Phillip Hallam-Baker wrote:

 If a person at Snowden's level in the NSA had any access to information

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.

Culling admins and adding the two-eyes rule will cripple the TLAs 
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)

2013-09-06 Thread Peter Saint-Andre
-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

2013-09-06 Thread Benjamin Kreuter
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

2013-09-06 Thread Ralph Holz
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)

2013-09-06 Thread Bill Squier

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

2013-09-06 Thread Kristian Gjøsteen

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

2013-09-06 Thread Perry E. Metzger
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)

2013-09-06 Thread Jerry Leichter
 
 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

2013-09-06 Thread Jerry Leichter
 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

2013-09-06 Thread Jerry Leichter
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

2013-09-06 Thread Tim Dierks
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

2013-09-06 Thread John Gilmore
 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:

  https://www.toad.com/des-stanford-meeting.html

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
access to decrypted information upon a legally authorized request.
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

2013-09-06 Thread Ralph Holz
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)

2013-09-06 Thread Jerry Leichter
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)

2013-09-06 Thread Raphaël Jacquot

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 
add the following line:


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)

2013-09-06 Thread Daniel Veditz
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
can get it by asking.

-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

2013-09-06 Thread ianG

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)

2013-09-06 Thread Jerry Leichter
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 
that advertised itself as using AES (you know, military-grade encryption) which 
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

2013-09-06 Thread Ben Laurie
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

2013-09-06 Thread James A. Donald

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

2013-09-06 Thread Perry E. Metzger
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

2013-09-06 Thread Jack Lloyd

 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)

2013-09-06 Thread Peter Fairbrother

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 - 
instead.


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?

2013-09-06 Thread Jaap-Henk Hoepman
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 
Radboud University Nijmegen 
(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

2013-09-06 Thread Eugen Leitl
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:
 
 Q: Could the NSA be intercepting downloads of open-source encryption 
 software and silently replacing these with their own versions?
 
 A: (Schneier) Yes, I believe so.

This is why I've been verifying Tor downloads using
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
no added bill of materials.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-06 Thread ianG

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

2013-09-06 Thread Perry E. Metzger
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
 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.)
 

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

2013-09-06 Thread Perry E. Metzger
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


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

2013-09-06 Thread Perry E. Metzger
On Fri, 06 Sep 2013 18:52:46 +0200 Raphaël Jacquot
sxp...@sxpert.org wrote:
 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.

As I've said earlier, I think that we no longer have the luxury of
speaking in terms of higher connection establishment latency or
similar considerations as a reason not to use PFS techniques. At the
very least, we should presume that people will pressure technologists
to overconsider such issues in an attempt to assure that stealing
keys is enough to be able to read TLS connections.

Certainly in a very wide variety of contexts, like XMPP, connections
are so long lived that there is never a performance excuse.

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.


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

2013-09-06 Thread Jerry Leichter
A response he wrote as part of a discussion at 
http://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html:

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

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

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


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

2013-09-06 Thread Perry E. Metzger
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

2013-09-06 Thread Peter Gutmann
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

2013-09-06 Thread Peter Gutmann
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

2013-09-06 Thread Perry E. Metzger
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.

http://www.washingtonpost.com/business/technology/google-encrypts-data-amid-backlash-against-nsa-spying/2013/09/06/9acc3c20-1722-11e3-a2ec-b47e45e6f8ef_story.html

-- 
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

2013-09-06 Thread Ben Laurie
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)

2013-09-06 Thread ianG

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
can get it by asking.



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?

2013-09-06 Thread John Denker
-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)

2013-09-06 Thread Ben Laurie
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

2013-09-06 Thread Jerry Leichter
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

2013-09-06 Thread ianG

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)

2013-09-06 Thread Anne Lynn Wheeler

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

2013-09-06 Thread Perry E. Metzger
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

2013-09-06 Thread ianG

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)
* crunching of poor passwords
* 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

2013-09-06 Thread Harald Koch
On 6 September 2013 16:25, Jerry Leichter leich...@lrw.com wrote:

 Q: Could the NSA be intercepting downloads of open-source encryption
 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

2013-09-06 Thread Marcus D. Leech

On 09/06/2013 07:38 PM, Perry E. Metzger wrote:

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.

http://www.washingtonpost.com/business/technology/google-encrypts-data-amid-backlash-against-nsa-spying/2013/09/06/9acc3c20-1722-11e3-a2ec-b47e45e6f8ef_story.html


One wonders why they weren't already using link encryption systems?


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

Re: [Cryptography] Bruce Schneier has gotten seriously spooked

2013-09-06 Thread Lodewijk andré de la porte
That they have the capacity doesn't mean they ever actually did it,
Schneier's comment is conservative. It is obviously within in their (legal)
capacity to change anything going accross US and INTNET cables and to forge
a some families of signatures.


2013/9/6 Eugen Leitl eu...@leitl.org

 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:
 
  Q: Could the NSA be intercepting downloads of open-source encryption
 software and silently replacing these with their own versions?
 
  A: (Schneier) Yes, I believe so.

 This is why I've been verifying Tor downloads using
 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
 no added bill of materials.
 ___
 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] Washington Post: Google racing to encrypt links between data centers

2013-09-06 Thread Lodewijk andré de la porte
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.


 http://www.washingtonpost.com/business/technology/google-encrypts-data-amid-backlash-against-nsa-spying/2013/09/06/9acc3c20-1722-11e3-a2ec-b47e45e6f8ef_story.html

 --
 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

2013-09-06 Thread Jon Callas
-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

2013-09-06 Thread James Cloos
 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

Links and elinks only did tls 1.1.

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

2013-09-06 Thread The Doctor
-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.

Let's contrast this with ChaosPad:
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
WWW: https://drwho.virtadpt.net/

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

2013-09-06 Thread The Doctor
-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

Interestingly, turning this on breaks access to
https://addons.mozilla.org/.  Bluh.

- -- 
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
WWW: https://drwho.virtadpt.net/

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

2013-09-06 Thread Jon Callas
-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

2013-09-06 Thread Jon Callas
-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...

2013-09-06 Thread Perry E. Metzger
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

2013-09-06 Thread Perry E. Metzger
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

2013-09-06 Thread Derrell Piper
...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

2013-09-06 Thread Kevin W. Wall

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

2013-09-06 Thread Chris Palmer
 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

2013-09-06 Thread Chris Palmer
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.

 Let's contrast this with ChaosPad:
 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
secrecy; check your Firefox configuration.
___
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

2013-09-06 Thread Marcus D. Leech
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

  some way, then PFS doesn't help you.

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
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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


Re: [Cryptography] NSA hates sunshine

2013-09-06 Thread John Gilmore
  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
the press and his university about censorship of academic freedom,
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,
instead of making hundreds of copies of the document, and spreading
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?

2013-09-06 Thread Jon Callas

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

2013-09-06 Thread Ben Laurie
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

2013-09-06 Thread Derrell Piper
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

2013-09-06 Thread The Doctor
-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
WWW: https://drwho.virtadpt.net/

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

2013-09-06 Thread The Doctor
-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
WWW: https://drwho.virtadpt.net/

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

2013-09-06 Thread Jerry Leichter
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?

2013-09-06 Thread Marcus D. Leech




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 
adding another
  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...

2013-09-06 Thread Dan McDonald
... 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

2013-09-06 Thread Marcus D. Leech

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