Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-11 Thread Chris Palmer
On Tue, Sep 10, 2013 at 2:04 PM, Joe Abley jab...@hopcount.ca wrote:

 As an aside, I see CAs with Chinese organisation names in my browser list.

I wouldn't pick on/fear/call out the Chinese specifically.

Also, be aware that browsers must transitively trust all the issuers
that the known trust anchors have issued issuing certificates for.
That's a much bigger set, and is not currently fully knowable.
(Another reason to crave Certificate Transparency.)
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-10 Thread Andreas Davour
 

 On Mon, Sep 09, 2013 at 06:41:23AM -0700, Andreas Davour wrote:
  So there *is* a BTNS implementation, after all. Albeit
  only for OpenBSD -- but this means FreeBSD is next, and
  Linux to follow.
 
  I might add that as far as I know, this work has not been picked up
  yet by neither FreeBSD, nor Linux, so if you feel like giving the
  project a hand pushing it into the mainstream, I'm pretty sure mc
  would be very happy.  I.e.  I don't think anything is following on
  this work unless someone reading this helps making that happen. 
  Personally I have neither the skills nor the contacts needed.
 
 To use btns, you need iked installed:
 
 from http://hack.org/mc/projects/btns/howto.html
 
 Please note:  The BTNS implementation is currently very experimental
 and should be used with caution.
 
 Doesn't sound like this is production ready?


It isn't. Thus my addition to Eugen's suggestion that other operating system 
implementations are to follow, and my suggestion that you might want to hack on 
the project. 

But, I wanted to let people engaged by the topic of btns know of an 
implementaion, since at least there is a start! 

/andreas
--
My
 son has spoken the truth, and he has sacrificed more than either the 
president of the United States or Peter King have ever in their 
political careers or their American lives. So how they choose to 
characterize him really doesn't carry that much weight with me. -- 
Edward Snowden's Father
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-10 Thread Joe Abley

On 2013-09-09, at 12:04, Salz, Rich rs...@akamai.com wrote:

 ➢  then maybe it's not such a silly accusation to think that root CAs are 
 routinely distributed to multinational secret
 ➢  services to perform MITM session decryption on any form of communication 
 that derives its security from the CA PKI.
 
 How would this work, in practice?

Suppose Mallory has access to the private keys of CAs which are in the 
browser list or otherwise widely-trusted.

An on-path attack between Alice and Bob would allow Mallory to terminate 
Alice's TLS connection, presenting an opportunistically-generated server-side 
certificate with signatures that allow it to be trusted by Alice without 
pop-ups and warnings. Instantiating a corresponding session with Bob and ALGing 
the plaintext through with interception is then straightforward.

This would be detectable by Bob by the visible client address, but that could 
be obfuscated (Mallory could exit the session through something tor-like, for 
example, to avoid advertising their topological location; this would just make 
it look like Alice is using tor).

In the case where Alice is presenting a certificate specifically trusted by 
Bob, this wouldn't work so well. But my observation is that many TLS-protected 
streams used by consumers don't use client certificate authentication.

As an aside, I see CAs with Chinese organisation names in my browser list. I 
don't know how to distinguish between enterprises and government from this side 
of the Pacific (so, presumably, assume they are all government). I had always 
assumed that this was already happening at the Great Firewall, as a working 
example of government-sponsored TLS interception with no requirement for 
expensive crunching of large integers.


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

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-10 Thread Perry E. Metzger
On Tue, 10 Sep 2013 17:04:51 -0400 Joe Abley jab...@hopcount.ca
wrote:
 On 2013-09-09, at 12:04, Salz, Rich rs...@akamai.com wrote:
 
  then maybe it's not such a silly accusation to think that
  root CAs are routinely distributed to multinational secret
  services to perform MITM session decryption on any form of
  communication that derives its security from the CA PKI.
  
  How would this work, in practice?
 
 Suppose Mallory has access to the private keys of CAs which are in
 the browser list or otherwise widely-trusted.
 
 An on-path attack between Alice and Bob would allow Mallory to
 terminate Alice's TLS connection, presenting an
 opportunistically-generated server-side certificate with signatures
 that allow it to be trusted by Alice without pop-ups and warnings.

Note that the apparent attacks against Petrobras, SWIFT and others
disclosed a few days ago appear to have used precisely this attack.

Perry
-- 
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-10 Thread Ben Laurie
On 10 September 2013 22:04, Joe Abley jab...@hopcount.ca wrote:

 Suppose Mallory has access to the private keys of CAs which are in the
 browser list or otherwise widely-trusted.

 An on-path attack between Alice and Bob would allow Mallory to terminate
 Alice's TLS connection, presenting an opportunistically-generated
 server-side certificate with signatures that allow it to be trusted by
 Alice without pop-ups and warnings. Instantiating a corresponding session
 with Bob and ALGing the plaintext through with interception is then
 straightforward.


CT makes this impossible to do undetected, of course.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-09 Thread ianG

Hi Jeffery,

On 8/09/13 02:52 AM, Jeffrey I. Schiller wrote:


The IETF was (and probably still is) a bunch of hard working
individuals who strive to create useful technology for the
Internet.



Granted!  I do not want to say that the IETF people are in a conspiracy 
with someone or each other, or that they are not hard workers [0].


But, I do want to say that, when it comes to security, we now have 
enough history and experience to suggest:


the committee may be part of the problem [1],

*and*

it is not clear that it can ever be part of the solution.

Insultingly;  those who've spent a decade or so devoting themselves to 
this process will not take to that notion kindly.  It's sad and 
frustrating -- I also spent a lot of time  money pushing OpenPGP code 
-- but that does not change the basic economic data we have in front of 
us.  In the 1990s we had little or no real data about Internet security. 
 Now we're 20 years on.  We have real data.




In particular IETF contributors are in theory individual
contributors and not representatives of their employers. Of course
this is the theory and practice is a bit “noisier”



The notion that employees are there as individuals is noble but 
unrealistic, naive.  That's to ignore business and politics, h/t to John 
Young.


Individuals without funded interests are rare, and tend to only be 
around for brief periods [2].  It is the case that the IETF has done 
better than other industry groups by insisting on open access and rough 
consensus [3].


But the IETF has done nothing to change the laws of economics:  Being on 
a committee costs a huge amount of time.  Only corporates who are 
engaged in making money off of the results can typically re-invest that 
money, and only individuals committed to working *that job* from 
corporates would spend that time on their own dime.


So, naturally, the corporates dominate the committees.  To argue 
anything else is to argue against economics, perhaps the strongest force 
in human nature.




but the bulk of
participant I worked with were honest hard working individuals.



There's nothing dishonest or lazy about defending ones job.



Security fails on the Internet for three important reasons, that have
nothing to do with the IETF or the technology per-se (except for point
3).

  1.  There is little market for “the good stuff”. When people see that
  they have to provide a password to login, they figure they are
  safe... In general the consuming public cannot tell the
  difference between “good stuff” and snake oil. So when presented
  with a $100 “good” solution or a $10 bunch of snake oil, guess
  what gets bought.



Although it is nicely logical and oft received wisdom, this is not 
historically supported.  Skype, SSH, Bitcoin, OTR, iMessage are 
successful security products.


There is clearly a market for good stuff but we the engineers don't 
see how to get there, and corporates don't either.  Putting us in a 
committee doesn't improve that, and probably makes it worse.




  2.  Security is *hard*, it is a negative deliverable. You do not know
  when you have it, you only know when you have lost it (via
  compromise).



2. counter-points in abundance:  transaction databases, protocols, 
monies, browsers, webservers, file sharing, p2p chats, office, 
languages, registries, source control, kernels, etc.  These are all 
hard.  We have a long list of projects and systems where we (the 
non-committee'd internet) have produced very difficult things.




  It is therefore hard to show return on investment
  with security. It is hard to assign a value to something not
  happening.



ROI:

a. it is hard to show quality at any points behind the screen.  The only 
things that are easy to show are pretty widgets on screens.  Everything 
else is hard.


b. I often show ROI models as to why security saves money.  (The model 
derives from support costs, if anyone doubts this.  Also, see Lynn 
Wheeler's discussion of credit card fees for the basic economics.)


Which is to say, the problems the net face in security are somewhat 
distinct from them being just hard  hard to show;  correlation maybe 
but causality?




  2a. Most people don’t really care until they have been personally
  bitten. A lot of people only purchase a burglar alarm after they
  have been burglarized. Although people are more security aware
  today, that is a relatively recent development.



2a., I agree!  I now feel bitten by Skype, and damn them to hell!




  3.  As engineers we have totally and completely failed to deliver
  products that people can use.



Right.  (It is a slow-moving nightmare moving all our people to OTR, 
which is dominated at the usability level by Skype.)




  I point out e-mail encryption as a
  key example. With today’s solutions you need to understand PK and
  PKI at some level in order to use it. That is likely requiring a
  driver to 

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-09 Thread Salz, Rich
➢  then maybe it's not such a silly accusation to think that root CAs are 
routinely distributed to multinational secret
➢  services to perform MITM session decryption on any form of communication 
that derives its security from the CA PKI.

How would this work, in practice?  How would knowing a CA's private key give 
them knowledge of my key?  Or if they issued a fake certificate and keypair, 
how does that help?  They'd also have to suborn DNS and IP traffic such that it 
would, perhaps eventually or perhaps quickly, become obvious.

What am I missing?

/r$
--  
Principal Security Engineer
Akamai Technology
Cambridge, MA



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

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-09 Thread Andreas Davour

 From: Eugen Leitl eu...@leitl.org

Forwarded with permission.
[snip]
 http://hack.org/mc/projects/btns/


So there *is* a BTNS implementation, after all. Albeit
only for OpenBSD -- but this means FreeBSD is next, and
Linux to follow.

I might add that as far as I know, this work has not been picked up yet by 
neither FreeBSD, nor Linux, so if you feel like giving the project a hand 
pushing it into the mainstream, I'm pretty sure mc would be very happy. I.e. I 
don't think anything is following on this work unless someone reading this 
helps making that happen. Personally I have neither the skills nor the contacts 
needed.


/andreas
--
My son has spoken the truth, 
and he has sacrificed more than either the president of the United 
States or Peter King have ever in their political careers or their 
American lives. So how they choose to characterize him really doesn't 
carry that much weight with me. -- Edward Snowden's Father 

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-09 Thread Salz, Rich
   *  NSA employees participted throughout, and occupied leadership roles
  in the committee and among the editors of the documents

 Slam dunk.  If the NSA had wanted it, they would have designed it themselves. 
  The only
 conclusion for their presence that is rational is to sabotage it [3].

No.  One mission of the NSA is to protect US government secrets. Since the 
government can no longer afford to specify their own security products all the 
time (or rather that the computer market has become commoditized), the NSA has 
an interest in making standard COTS products be secure.

I do not know if the NSA worked to subvert IETF specifications, but 
participation isn't proof of it.

/r$

   Flaming Carrot!...  Do
you see Communists behind
every bush?
 No... but SOMETIMES they
  hide there.


--  
Principal Security Engineer
Akamai Technology
Cambridge, MA
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-08 Thread John Gilmore
  First, DNSSEC does not provide confidentiality.  Given that, it's not
  clear to me why the NSA would try to stop or slow its deployment.

DNSSEC authenticates keys that can be used to bootstrap
confidentiality.  And it does so in a globally distributed, high
performance, high reliability database that is still without peer in
the world.

It was never clear to me why DNSSEC took so long to deploy, though
there was one major moment at an IETF in which a member of the IESG
told me point blank that Jim Bidzos had made himself so hated that the
IETF would never approve a standard that required the use of the RSA
algorithm -- even despite a signed blanket license for use of RSA for
DNSSEC, and despite the expiration of the patent.  I thought it was an
extreme position, and it was very forcefully expressed -- but it was
apparently widely enough shared that the muckety-mucks did force the
standard to go back to the committee and have a second algorithm added
to it (which multiplied the interoperability issues considerably and
caused several years of further delay).

John

PS: My long-standing domain registrar (enom.com) STILL doesn't support
DNSSEC records -- which is why toad.com doesn't have DNSSEC
protection.  Can anybody recommend a good, cheap, reliable domain
registrar who DOES update their software to support standards from ten
years ago?
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-08 Thread Ray Dillinger

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


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



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

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

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

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

Bear



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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-08 Thread John Kelsey
Let's suppose I design a block cipher such that, with a randomly generated key 
and 10,000 known plaintexts, I can recover that key.  For this to be useful in 
a world with relatively sophisticated cryptanalysts, I must have confidence 
that it is extremely hard to find my trapdoor, even when you can look closely 
at my cipher's design.   

At this point, what I have is a trapdoor one-way function.  You generate a 
random key K and then compute E(K,i) for i = 1 to 1.  The output of the 
one-way function is the ciphertext.  The input is K.  If nobody can break the 
cipher, then this is a one-way funciton.  If only I, who designed it, can break 
it, then it's a trapdoor one-way function.  

At this point, I have a perfectly fine public key encryption system.  To send 
me a message, choose a random K, use it to encrypt 1 through 1, and then 
send me the actual message encrypted after that in K.  If nobody but me can 
break the system, then this cipher works as my public key.  

The assumption that matters here is that you know enough cryptanalysis that it 
would be hard to hide a practical attack from you.  If you don't know about 
differential cryptanalysis, I can do the master key cryptosystem, but only 
until you learn about it, at which point you will break my cipher.   But if you 
can, say, hide the only good linear characteristics for some cipher in its 
S-boxes in a way that is genuinely intractible for anyone else to find, then 
you have a public key cryptosystem. You can publish the algorithm for hiding 
new linear characteristics in an S-box--this becomes the keypair generation 
algorithm.  The private key is the linear characteristic that lets you break 
the cipher with (say) 1 known plaintexts, the public key is the cipher 
definition.  

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-08 Thread Phillip Hallam-Baker
On Sat, Sep 7, 2013 at 8:53 PM, Gregory Perry gregory.pe...@govirtual.tvwrote:

 On 09/07/2013 07:52 PM, Jeffrey I. Schiller wrote:
  Security fails on the Internet for three important reasons, that have
  nothing to do with the IETF or the technology per-se (except for point
  3).
   1.  There is little market for “the good stuff”. When people see that
   they have to provide a password to login, they figure they are
   safe... In general the consuming public cannot tell the
   difference between “good stuff” and snake oil. So when presented
   with a $100 “good” solution or a $10 bunch of snake oil, guess
   what gets bought.
 The IETF mandates the majority of the standards used on the Internet
 today.


No they do not. There is W3C and OASIS both of which are larger now. And
there has always been IEEE.

And they have no power to mandate anything. In fact one of the things I
have been trying to do is to persuade people that the Canute act commanding
the tides to turn is futile. People need to understand that the IETF does
not have any power to mandate anything and that stakeholders will only
follow standards proposals if they see a value in doing so.




  If the IETF were truly serious about authenticity and integrity
 and confidentiality of communications on the Internet, then there would
 have been interim ad-hoc link layer encryption built into SMTP
 communications since the end of U.S. encryption export regulations.


Like STARTTLS which has been in the standards and deployed for a decade now?



 There would have been an IETF-mandated requirement for Voice over IP
 transport encryption, to provide a comparable set of confidentiality
 with VoIP communications that are inherent to traditional copper-based
 landline telephones.  There would at the very least be ad-hoc (read
 non-PKI integrated) DNSSEC.


What on earth is that? DNS is a directory so anything that authenticates
directory attributes is going to be capable of being used as a PKI.



 And then there is this Bitcoin thing.  I say this as an individual that
 doesn't even like Bitcoin.  For the record and clearly off topic, I hate
 Bitcoin with a passion and I believe that the global economic crisis
 could be easily averted by returning to a precious metal standard with
 disparate local economies and currencies, all in direct competition with
 each other for the best possible GDP.


The value of all the gold in the world ever mined is $8.2 trillion. The
NASDAQ alone traded $46 trillion last Friday.

There are problems with bitcoin but I would worry rather more about the
fact that the Feds have had no trouble at all shutting down every prior
attempt at establishing a currency of that type and the fact that there is
no anonymity whatsoever.





 So how does Bitcoin exist without the IETF?  In its infancy, millions of
 dollars of transactions are being conducted daily via Bitcoin, and there
 is no IETF involved and no central public key infrastructure to validate
 the papers of the people trading money with each other.  How do you
 counter this Bitcoin thing, especially given your tenure and experience
 at the IETF?


Umm I would suggest that it has more to do with supply and demand and the
fact that there is a large amount of economic activity that is locked out
of the formal banking system (including the entire nation of Iran) that is
willing to pay a significant premium for access to a secondary.


 Nonsense.  Port 25 connects to another port 25 and exchanges a public
 key.  Then a symmetrically keyed tunnel is established.  This is not a
 complex thing, and could have been written into the SMTP RFC decades ago.


RFC 3702 published in 2002.


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

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-08 Thread Phillip Hallam-Baker
On Sat, Sep 7, 2013 at 10:35 PM, Gregory Perry
gregory.pe...@govirtual.tvwrote:

  On 09/07/2013 09:59 PM, Phillip Hallam-Baker wrote:
 
 Anyone who thinks Jeff was an NSA mole when he was one of the main people
 behind the MIT version of PGP and the distribution of Kerberos is talking
 daft.
 
  I think that the influence was rather more subtle and was more directed
 at encouraging choices that would make the crypto hopelessly impractical
 so people would not use it than in adding backdoors.
 
  
  One of the lessons of PRISM is that metadata is very valuable. In
 particular social network analysis. If I know who is talking to whom then I
 have pretty much 90% of the data needed to wrap up any conspiracy against
 the government. So lets make sure we all use PGP and sign each other's
 keys...

 1) At the core of the initial PGP distribution authored by Philip R.
 Zimmermann, Jr. was the RSA public key encryption method

 2) At that time, the Clinton administration and his FBI was advocating
 widespread public key escrow mechanisms, in addition to the inclusion of
 the Clipper chip to all telecommunication devices to be used for remote
 lawful intercepts

 3) Shortly after the token indictment of Zimmerman (thus prompting
 widespread use and promotion of the RSA public key encryption algorithm),
 the Clinton administration's FBI then advocated a relaxation of encryption
 export regulations in addition to dropping all plans for the Clipper chip

 4) On September 21, 2000, the patent for the RSA public key encryption
 algorithm expired, yet RSA released their open source version of the RSA
 encryption algorithm two weeks prior to their patent's expiry for use
 within the public domain

 5) Based upon the widespread use and public adoption of the RSA public key
 encryption method via the original PGP debacle, RSA (now EMC) could have
 easily adjusted the initial RSA patent term under the auspice of national
 security, which would have guaranteed untold millions (if not billions) of
 additional dollars in revenue to the corporate RSA patent holder

 You do the math


This is seriously off topic here but the idea that the indictment of Phil
Zimmerman was a token effort is nonsense. I was not accusing Phil Z. of
being a plant.

Not only was Louis Freeh going after Zimmerman for real, he went against
Clinton in revenge for the Clipper chip program being junked. He spent much
of Clinton's second term conspiring with Republicans in Congress to get
Clinton impeached.

Clipper was an NSA initiative that began under Bush or probably even
earlier. They got the incoming administration to endorse it as a fait
accompli.


Snowden and Manning on the other hand... Well I do wonder if this is all
some mind game to get people to secure the Internet against cyberattacks.
But the reason I discount that as a possibility is that what has been
revealed has completely destroyed trust. We can't work with the Federal
Government on information security the way that we did in the past any more.

I think the administration needs to make a downpayment on restoring trust.
They could begin by closing the gulag in Guantanamo.

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

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-08 Thread Phillip Hallam-Baker
On Sat, Sep 7, 2013 at 9:50 PM, John Gilmore g...@toad.com wrote:

   First, DNSSEC does not provide confidentiality.  Given that, it's not
   clear to me why the NSA would try to stop or slow its deployment.

 DNSSEC authenticates keys that can be used to bootstrap
 confidentiality.  And it does so in a globally distributed, high
 performance, high reliability database that is still without peer in
 the world.

 It was never clear to me why DNSSEC took so long to deploy, though
 there was one major moment at an IETF in which a member of the IESG
 told me point blank that Jim Bidzos had made himself so hated that the
 IETF would never approve a standard that required the use of the RSA
 algorithm -- even despite a signed blanket license for use of RSA for
 DNSSEC, and despite the expiration of the patent.  I


No, that part is untrue. I sat at the table with Jeff Schiller and Burt
Kaliski when Burt pitched S/MIME at the IETF. He was Chief Scientist of RSA
Labs at the time.

Jim did go after Phil Z. over PGP initially. But Phil Z. was violating the
patent at the time. That led to RSAREF and the MIT version of PGP.


DNSSEC was (and is) a mess as a standard because it is an attempt to
retrofit a directory designed around some very tight network constraints
and with a very poor architecture to make it into a PKI.

PS: My long-standing domain registrar (enom.com) STILL doesn't support
 DNSSEC records -- which is why toad.com doesn't have DNSSEC
 protection.  Can anybody recommend a good, cheap, reliable domain
 registrar who DOES update their software to support standards from ten
 years ago?


The Registrars are pure marketing operations. Other than GoDaddy which
implemented DNSSEC because they are trying to sell the business and more
tech looks kewl during due diligence, there is not a market demand for
DNSSEC.

One problem is that the Registrars almost invariably sell DNS registrations
at cost or at a loss and make the money up on value added products. In
particular SSL certificates.


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

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-08 Thread Jerry Leichter
On Sep 7, 2013, at 11:45 PM, John Kelsey wrote:

 Let's suppose I design a block cipher such that, with a randomly generated 
 key and 10,000 known plaintexts, I can recover that key At this point, 
 what I have is a trapdoor one-way function.  You generate a random key K and 
 then compute E(K,i) for i = 1 to 1.  The output of the one-way function 
 is the ciphertext.  The input is K.  If nobody can break the cipher, then 
 this is a one-way funciton.  If only I, who designed it, can break it, then 
 it's a trapdoor one-way function At this point, I have a perfectly fine 
 public key encryption system.  To send me a message, choose a random K, use 
 it to encrypt 1 through 1, and then send me the actual message encrypted 
 after that in K.  If nobody but me can break the system, then this cipher 
 works as my public key.
OK, let's look at this another way.  The broader argument being made here 
breaks down into three propositions:

1.  If you have a way to spike a block cipher based on embedding a secret in 
it, you can a way to create something with the formal properties of a public 
key cryptosystem - i.e., there is a function E(P) which anyone can compute on 
any plaintext P, but given E(P), only you can invert to recover P.

2.  Something with the formal properties of a public key cryptosystem can be 
used as a *practical* public key cryptosystem.

3.  A practical public-key cryptosystem is much more valuable than a way to 
embed a secret in a block cipher, so if anyone came up with the latter, they 
would certainly use it to create the former, as it's been the holy grail of 
cryptography for many years to come up with a public key system that didn't 
depend on complex mathematics with uncertain properties.

If we assume these three propositions, and looks around us and observe the lack 
of the appropriate kinds of public key systems, we can certainly conclude that 
no one knows how to embed a secret in a block cipher.

Proposition 1, which is all you specifically address, is certainly true.  I 
claim that Propositions 2 and 3 are clearly false.

In fact, Proposition 3 isn't even vaguely mathematical - it's some kind of 
statement about the values that cryptographers assign to different kinds of 
primitives and to publication.  It's quite true that if anyone in the academic 
world were to come up with a way to create a practical public key cryptosystem 
without a dependence on factoring or DLP, they would publish to much acclaim.  
(Of course, there *are* a couple of such systems known - they were published 
years ago - but no one uses them for various reasons.  So acclaim ... well, 
maybe.)  Then again, an academic cryptographer who discovered a way to hide a 
secret in a block cipher would certainly publish - it would be really 
significant work.  So we never needed this whole chain of propositions to begin 
with:  It's self-evidently true that no one in the public community knows how 
to embed a secret in a block cipher.

But ... since we're talking *values*, what are NSA's values?  Would *they* have 
any reason to publish if they found a way to embed a secret in a block cipher? 
Hell, no!  Why would they want to give away such valuable knowledge?  Would 
they produce a private-key system based on their breakthrough?  Maybe, for 
internal use.  How would we ever know?

But let's talk mathematics, not psychology and politics.  You've given a 
description of a kind of back door that *would* produce a practical public key 
system.  But I've elsewhere pointed out that there are all kinds of back doors. 
 Suppose that my back door reduces the effective key size of AES to 40 bits.  
Even 20+ years ago, NSA was willing to export 40-bit crypto; presumably they 
were willing to do the brute-force computation to break it.  Today, it would be 
a piece of cake.  But would a public-key system that requires around 2^40 
operations to encrypt be *practical*?  Even today, I doubt it.  And if you're 
willing to do 2^40 operations, are you willing to do 2^56?  With specialized 
hardware, that, too, has been easy for years.  NSA can certainly have that 
specialized hardware for code breaking - will you buy it for encryption?

 The assumption that matters here is that you know enough cryptanalysis that 
 it would be hard to hide a practical attack from you.  If you don't know 
 about differential cryptanalysis, I can do the master key cryptosystem, but 
 only until you learn about it, at which point you will break my cipher.
In fact, this is an example I was going to give:  In a world in which 
differential crypto isn't known, it *is* a secret that's a back door.  Before 
DC was published, people seriously proposed strengthening DES by using a 
448-bit (I think that's the number) key - just toss the round key computation 
mechanism and provide all the keying for all the rounds.  If that had been 
widely used, NSA would have been able to break it use DC.

Of course we know about DC.  But the only 

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-08 Thread Daniel Cegiełka
Hi,

http://www.youtube.com/watch?v=K8EGA834Nok

Is DNSSEC is really the right solution?

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-08 Thread Peter Bowen
On Sat, Sep 7, 2013 at 6:50 PM, John Gilmore g...@toad.com wrote:
 PS: My long-standing domain registrar (enom.com) STILL doesn't support
 DNSSEC records -- which is why toad.com doesn't have DNSSEC
 protection.  Can anybody recommend a good, cheap, reliable domain
 registrar who DOES update their software to support standards from ten
 years ago?

PIR (the .org registry) has a field in their registrar list indicating
if the registrar supports DNSSEC:
http://www.pir.org/get/registrars?order=field_dnssec_valuesort=desc

If you exclude all the name.com and Go Daddy shell registrars, you
still have more than 30 to choose from.  I would be shocked if they
didn't all offer .com in addition to .org.

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-08 Thread Jon Callas
 3) Shortly after the token indictment of Zimmerman (thus prompting widespread 
 use and promotion of the RSA public key encryption algorithm), the Clinton 
 administration's FBI then advocated a relaxation of encryption export 
 regulations in addition to dropping all plans for the Clipper chip

I need to correct some facts, especially since I'm seeing this continue to get 
repeated.

Phil was never charged, indicted, sued, or anything else. He was 
*investigated*. He was investigated for export violations, not for anything 
else. Being investigated is bad enough, but that's what happened. The 
government dropped the investigation in early 1996.

The government started the investigation because they were responding to a 
complaint from RSADSI that Phil and team violated export control. As Phill 
noted, there was the secondary issue of the dispute over the RSA patent 
license, but that was a separate issue. RSADSI filed the complaint with the 
government that started the investigation.

Jon




PGP.sig
Description: 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-08 Thread Jeffrey I. Schiller
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Sep 06, 2013 at 05:22:26PM -0700, John Gilmore 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:
 ...

Speaking as one of the Security Area Directors at the time...

I have to disagree with your implication that the NSA intentionally
fouled the IPSEC working group. There were a lot of people working to
foul it up! I also don’t believe that the folks who participated,
including the folks from the NSA, were working to weaken the
standard. I suspect that the effort to interfere in standards started
later then the IPSEC work. If the NSA was attempting to thwart IETF
security standards, I would have expected to also see bad things in
the TLS working group and the PGP working group. There is no sign of
their interference there.

The real (or at least the first) problem with the IPSEC working group
was that we had a good and simple solution, Photuris. However the
document editor on the standard decided to claim it (Photuris) as his
intellectual property and that others couldn’t recommend changes
without his approval. This effectively made Photuris toxic in the
working group and we had to move on to other solutions. This is one of
the events that lead to the IETF’s “Note Well” document and clear
policy on the IP associated with contributions. Then there was the
ISAKMP (yes, an NSA proposal) vs. SKIP. As Security AD, I eventually
had to choose between those two standards because the working group
could not generate consensus. I believed strongly enough that we
needed an IPSEC solution so I decided to choose (as I promised the
working group I would do if they failed to!). I chose ISAKMP. I posted
a message with my rationale to the IPSEC mailing list, I’m sure it is
still in the archives. I believe that was in 1996 (I still have a copy
somewhere in my personal archives).

At no point was I contacted by the NSA or any agent of any government
in an attempt to influence my decision. Folks can choose to believe
this statement, or not.

IPSEC in general did not have significant traction on the Internet in
general. It eventually gained traction in an important niche, namely
VPNs, but that evolved later.

IPSEC isn’t useful unless all of the end-points that need to
communicate implement it. Implementations need to be in the OS (for
all practical purposes).  OS vendors at the time were not particularly
interested in encryption of network traffic.

The folks who were interested were the browser folks. They were very
interested in enabling e-commerce, and that required
encryption. However they wanted the encryption layer someplace where
they could be sure it existed. An encryption solution was not useful
to them if it couldn’t be relied upon to be there. If the OS the user
had didn’t have an IPSEC layer, they were sunk. So they needed their
own layer. Thus the Netscape guys did SSL, and Microsoft did PCT and
in the IETF we were able to get them to work together to create
TLS. This was a *big deal*. We shortly had one deployed interoperable
encryption standard usable on the web.

If I was the NSA and I wanted to foul up encryption on the Internet,
the TLS group is where the action was. Yet from where I sit, I didn’t
see any such interference.

If we believe the Edward Snowden documents, the NSA at some point
started to interfere with international standards relating to
encryption. But I don’t believe they were in this business in the
1990’s at the IETF.

-Jeff

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iD8DBQFSLSMV8CBzV/QUlSsRAigkAKCU6erw1U7FOt7A1QdItlGbFRfo+gCfeMg1
0Woyz0FyKqKYqS+gZFQWEf0=
=yWOw
-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-07 Thread Samuel Weiler

On Thu, 5 Sep 2013, Phillip Hallam-Baker wrote:

* Allowing deployment of DNSSEC to be blocked in 2002(sic) by 
blocking a technical change that made it possible to deploy in 
.com.


As an opponent of DNSSEC opt-in back in the day, I think this is a 
poor example of NSA influence in the standards process.


I do not challenge PHB's theory that the NSA has plants in the 
IETF to discourage moves to strong crypto, particularly given John 
Gilmore's recent message on IPSEC, but I doubt that the NSA had any 
real influence on the DNSSEC opt-in debacle of 2003.


First, DNSSEC does not provide confidentiality.  Given that, it's not 
clear to me why the NSA would try to stop or slow its deployment.


Second, as I look at the people who opposed opt-in and the IETF 
working group chairs who made the decision to kill it, I don't see 
likely NSA stooges.  The list of opponents during working group last 
call was so short [1] (as compiled by PHB, back in the day) that I 
thought the working group chairs got the consensus call wrong.  The 
DNSEXT chairs were Randy Bush and Olafur Gudmundsson.  In previous 
years, Olafur had worked for TIS Labs, which had taken plenty of DoD 
money over the years.  Even so, I do not suspect he was influenced by 
the NSA.  Randy has taken money from DHS in more recent years, but I'm 
even more convinced he was not an NSA stooge.  (Randy was the chair 
issuing the opt-in last call and writing the summary.)


Third, many of the opt-in opponents in 2003 seemed to be pretty 
convinced that the lowered security guarantees and extra complexity of 
opt-in were nothing more than a subsidy for Verisign, which could just 
as well throw more money at the problem of signing its large zones. 
One might plausibly argue that Verisign's push for opt-in (and its 
later push for NSEC3) was itself a stalling tactic.  One might even go 
further and say that Verisign initiated such stalling at the behest of 
the NSA.  I would not make that argument, but it is at least as 
plausible as an argument that the opt-in opponents or WG chairs were 
NSA stooges.


Lastly, the US DoD was funding some amount of work on DNSSEC at the 
time (i.e., my own participation).  During that timeframe, significant 
progress was being made on the deployability of DNSSEC, and I think 
the DoD funding helped.  Depending on your whims, you could either 
credit DoD for helping or blame them for not providing even more 
funding, which might have made for faster progress.


So, again, while PHB's general theory might have merit, I think the 
DNSSEC opt-in example is not on point.


Disclosures: I was deeply involved in the IETF's DNSEXT working group 
during this time, and my funding came from non-NSA bits of DoD.  I am 
not aware of any NSA influence in my funding, and I felt no NSA 
pressure in the work I was doing.  I was a vocal opponent of opt-in, 
but in the end I chose to step aside and let it advance.[2]


-- Samuel Weiler


[1] http://marc.info/?l=namedroppersm=105145468327451w=2

[2] http://marc.info/?l=namedroppersm=104874927417175w=2

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-07 Thread Gregory Perry
As an opponent of DNSSEC opt-in back in the day, I think this is a
poor example of NSA influence in the standards process.

I do not challenge PHB's theory that the NSA has plants in the
IETF to discourage moves to strong crypto, particularly given John
Gilmore's recent message on IPSEC, but I doubt that the NSA had any
real influence on the DNSSEC opt-in debacle of 2003.

First, DNSSEC does not provide confidentiality.  Given that, it's not
clear to me why the NSA would try to stop or slow its deployment.

Insecure DNS deployments are probably in the top five attack vectors
for remotely compromising internal network topologies, even those
sporting split DNS configurations.  As you were ...deeply involved in the
IETF's DNSEXT working group then I presume you know this.

For example, DNS cache poisoning attacks, local ARP cache spoofing
attacks to redirect DNS queries and responses, redirection of operating
system update and patching services that map to fully qualified domain
names such as windowsupdate.microsoft.com, etc.

Correct me if I am wrong, but in my humble opinion the original intent
of the DNSSEC framework was to provide for cryptographic authenticity
of the Domain Name Service, not for confidentiality (although that
would have been a bonus).

Lastly, the US DoD was funding some amount of work on DNSSEC at
the time (i.e., my own participation).  During that timeframe,
significant progress was being made on the deployability of DNSSEC,
and I think the DoD funding helped.  Depending on your whims, you
could either credit DoD for helping or blame them for not providing
even more funding, which might have made for faster progress.

There are many different camps within the DoD.

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-07 Thread ianG

On 7/09/13 01:51 AM, Peter Gutmann wrote:

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?



In principle, it doesn't -- which is why SOPs are saboteur's tools of 
preference.  They are used against you, as the lesser experienced people 
can't see the acts behind [1]


The point is one of degree.  SOPs are there to resolve real disputes. 
They can also be used to cause disputes, and to turn any innocent thing 
into a fight.  So do that, and keep doing that!  Pretty soon the org 
becomes a farce.


In contrast, strong leadership (the chair) knows when to put the lid on 
such trivialities and move on.  So, part of the overall strategy is to 
neutralise the strong chair [2].  As John just reported:


  *  NSA employees participted throughout, and occupied leadership roles
 in the committee and among the editors of the documents

Slam dunk.  If the NSA had wanted it, they would have designed it 
themselves.  The only conclusion for their presence that is rational is 
to sabotage it [3].




iang




[0]   SOPs is standard operating procedures.
[1]   This is the flaw in don't attribute to malice what can be 
explained by incompetence.  Explaining by incompetence does not 
eliminate that malice inspired incompetence.  Remember, we are all 
innoculated against malice, so we prefer to see benign causes.
[2]  this is not to say that committees are ill-intentioned or people 
are bad, but that it only takes a few with malicious intent and 
expertise to bring the whole game to a halt.  Cartels such as IETF WGs 
are fundamentally and inescapably fragile.
[3]  as a sort of summer-flu-shot, I present that document to each new 
board as their SOPs.

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-07 Thread ianG

On 7/09/13 03:58 AM, Jon Callas wrote:


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.



I'm not as yet seeing that a block cipher with a backdoor is a public 
key system, but I really like the mental picture this is trying to create.


In order to encrypt to that system, one needs the (either) key.  If 
everyone has it (either) the system is ruined.


A public key system is an artiface where one can distribute the public 
key, and not have to worry about the system being ruined;  it's still 
perfectly usable.  Whereas with a symmetric system with two keys, either 
key being distributed ruins the system.


One could argue that the adversary would prefer the cleaner, more 
complete semantics of the public key system -- maybe that is what the 
theorem assumes?  But if I was the NSA I'd be happy with the compromise. 
 I'm good at keeping *my key secret* at least.




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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-07 Thread Eugen Leitl
On Fri, Sep 06, 2013 at 09:19:07PM -0400, Derrell Piper wrote:
 ...and to add to all that, how about the fact that IPsec was dropped as a 
 'must implement' from IPv6 sometime after 2002?

Apropos IPsec, I've tried searching for any BTNS (opportunistic encryption mode 
for
IPsec) implementations, and even the authors of the RFC are not aware of any.

Obviously, having a working OE BTNS implementation in Linux/*BSD would be a very
valuable thing, as an added, transparent protection layer against passive 
attacks.

There are many IPsec old hands here, it is probably just a few man-days worth
of work. It should be even possible to raise some funding for such a project.

Any takers?


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

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-07 Thread ianG

On 7/09/13 10:15 AM, Gregory Perry wrote:


Correct me if I am wrong, but in my humble opinion the original intent
of the DNSSEC framework was to provide for cryptographic authenticity
of the Domain Name Service, not for confidentiality (although that
would have been a bonus).



If so, then the domain owner can deliver a public key with authenticity 
using the DNS.  This strikes a deathblow to the CA industry.  This 
threat is enough for CAs to spend a significant amount of money slowing 
down its development [0].


How much more obvious does it get [1] ?

iang



[0] If one is a finance geek, one can even calculate how much money the 
opponents are willing to spend.
[1] As an aside, NSA/DoD have invested significant capital in the PKI as 
well.  Sufficient that they will be well aligned with the CA mission, 
and sufficient that they will approve of any effort to keep the CAs in 
business.  But this part is far less obvious.

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-07 Thread Jerry Leichter
On Sep 7, 2013, at 12:31 AM, Jon Callas wrote:
 I'm sorry, but this is just nonsense.  You're starting with informal, rough 
 definitions and claiming a mathematical theorem.
 
 Actually, I'm doing the opposite. I'm starting with a theorem and arguing 
 informally from there
Actually, if you look at the papers cited, *they* are themselves informal.  The 
fundamental thing they are lacking is a definition of what would constitute a 
master key.  Let's see if we can formalize this a bit:

We're given a block cipher E(K,P) and a corresponding decryption algorithm 
D(K,C).  The system has a master key M such that D(E(K,P),M) == P.  This is 
what a master key does in a traditional lock-and-key system, so unless we see 
some other definition, it's what we have to start with.  Is there such a 
system?  Sure, trivially.  Given any block cipher E'/D', I simply define E(K,P) 
= E'(M,K) || E'(K,P).  (I can optimize the extra length by leaking one randomly 
chosen bit of E'(M,K) per block.  It won't take long for the whole key to be 
transmitted.)  OK, where's the public key system?

So maybe there isn't *one* master key, but let's go to the extreme and say 
there is one unique master per user key, based on some secret information S.  
That is:  Given K, there is a function F(S,K) which produces a *different* key 
K', with the property that D(K,C) == D(K',C).  Or maybe, as in public key 
systems, you start with S and some random bits and produce a matched pair K and 
K'  But how is this a master key system?  If I wasn't present at the birth 
of the K that produced the cyphertext I have in hand ... to get K' now, I need 
K (first form) or S and the random bits (second form), which also gives me K 
directly.  So what have I gained?

I can construct a system of the first form trivially:  Just use an n-bit key 
but ignore the first bit completely.  There are now two keys, one with a 
leading 0, one with a leading 1.  Constructing a system of the second form 
shouldn't be hard, though I haven't done it.  In either case, it's 
uninteresting - my master key is as hard to get at as the original key.

I'm not sure exactly where to go next.  Let's try to modify some constraints.  
Eliminate directly hiding the key in the output by requiring that E(K,.) be a 
bijection.  There can't possibly be a single master key M, since if there were, 
what could D(M,E(M,0...0)) be?  It must be E(K,0...0) for any possible K, so 
E(K,0...0) must be constant - and in fact E must be constant.  Not very 
interesting.  In fact, a counting argument shows that there must be as many M's 
as there are K's.  It looks as we're back to the two-fold mapping on keys 
situation.  But as before ... how could this work?

In fact, it *could* work.  Suppose I use a modified form of E() which ignores 
all but the first 40 bits of K - but I don't know that E is doing this.  I can 
use any (say, 128-bit) key I like, and to someone not in on the secret, a brute 
force attack is impossible.  But someone who knows the secret simply sets all 
but the first 40 bits to 0 and has an easy attack.

*Modified forms (which hid what was happening to some degree) of such things 
were actually done in the days of export controls!*  IBM patented and sold such 
a thing under the name CDMF 
(http://domino.research.ibm.com/tchjr/journalindex.nsf/600cc5649e2871db852568150060213c/a453914c765e690085256bfa0067f9f4!OpenDocument).
  I worked on adding cryptography to a product back in those days, and we had 
to come up with a way to be able to export our stuff.  I talked to IBM about 
licensing CDMF, but they wanted an absurd amount of money.  (What you were 
actually paying for wasn't the algorithm so much as that NSA had already 
approved products using it for export.)  We didn't want to pay, and I designed 
my own algorithm to do the same thing.  It was a silly problem to have to 
solve, but I was rather proud of the solution - I could probably find my spec 
if anyone cares.  It was also never implemented, first because this was right 
around the time the crypto export controls got loosened; a
 nd second because we ended up deciding we didn't need crypto anyway.  We came 
back and did it very differently much later.  My two fun memories from the 
experience:  (a) Receiving a FAX from NSA - I still have it somewhere; (b) 
being told at one point that we might need someone with crypto clearance to 
work on this stuff with NSA, and one of my co-workers chiming in with Well, I 
used to have it.  Unfortunately it was from the KGB.

Anyway ... yes, I can implement such a thing - but there's still no public key 
system here.

So ... would *you* like to take a stab at pinning down a definition relative to 
which the theorem you rely on makes sense?

-- Jerry

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-07 Thread Gregory Perry
If so, then the domain owner can deliver a public key with authenticity
using the DNS.  This strikes a deathblow to the CA industry.  This
threat is enough for CAs to spend a significant amount of money slowing
down its development [0].

How much more obvious does it get [1] ?

The PKI industry has been a sham since day one, and several root certs
have been compromised by the proverbial bad guys over the years (for
example, the Flame malware incident used to sign emergency Windows
Update packages which mysteriously only affected users in Iran and the
Middle East, or the Diginotar debacle, or the Tunisian Ammar MITM
attacks etc).  This of course is assuming that the FBI doesn't already
have access to all of the root CAs so that on domestic soil they can
sign updates and perform silent MITM interception of SSL and
IPSEC-encrypted traffic using transparent inline layer-2 bridging
devices that are at every major Internet peering point and interconnect,
because that would be crazy talk.

However, some form of authenticity and integrity is better than zero,
which is what the majority of the current DNS system offers, and it is
point and click trivial to perform MITM attacks with unauthenticated
DNS, especially on local area network segments which are rarely
protected with more than the Windows firewall.

Even without a centralized PKI, stateless port 53 UDP DNS could benefit
from some type of cryptographic security, but as with any standard
seemingly related to privacy or confidentiality we are left with this
DNSSEC quagmire of meetings and proposed meetings to talk about the next
meeting to discuss how the committee will propose the next request for
comment, ad nauseum.

Bitcoin for example doesn't need hundreds of private companies with
elaborate PKI documentation authentication services which are in reality
just mental placebos for Joe Consumer when he updates his monthly
Brazzers subscription, and it's doing just fine as the runner up for the
next global world monetary standard.

So with that said, I would still place my wager on the FBI being the
source of these various privacy enhancing service delays and not some
secret cabal of PKI execs that are engaging in standards committee
subterfuge.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-07 Thread David Mercer
On Sat, Sep 7, 2013 at 2:19 AM, ianG i...@iang.org wrote:

 On 7/09/13 10:15 AM, Gregory Perry wrote:

  Correct me if I am wrong, but in my humble opinion the original intent
 of the DNSSEC framework was to provide for cryptographic authenticity
 of the Domain Name Service, not for confidentiality (although that
 would have been a bonus).



 If so, then the domain owner can deliver a public key with authenticity
 using the DNS.  This strikes a deathblow to the CA industry.  This threat
 is enough for CAs to spend a significant amount of money slowing down its
 development [0].

 How much more obvious does it get [1] ?

 iang


I proposed essentially this idea around 10 years ago on the capabilities
list, using custom TXT records and some hackish things that  are/were
sub-optimal due to DNSSEC being more of a pipedream then than it is now to
deliver public keys for any arbitrary purpose. I only went so far as to
kick around design ideas on and off-list back then under the tag-line of
objectdns (as in being able to locate and connect to any arbitrary object
via a public key crypto connection) and registering the domain objectdns.com.
Things stalled out there due to my lack of copious free time.

David Mercer - http://dmercer.tumblr.com
IM:  AIM: MathHippy Yahoo/MSN: n0tmusic
Facebook/Twitter/Google+/Linkedin: radix42
FAX: +1-801-877-4351 - BlackBerry PIN: 332004F7
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-07 Thread Anne Lynn Wheeler

On 09/07/13 05:19, ianG wrote:

If so, then the domain owner can deliver a public key with authenticity using 
the DNS.
This strikes a deathblow to the CA industry.  This threat is enough for CAs to 
spend a significant amount
of money slowing down its development [0].


unfortunately as far as SSL domain name certificate ... the domain name 
infrastructure is the
authoritative agency for domain name ownership ... the SSL domain name 
certification agencies
have to rely on the domain name infrastructure to validate true ownership for 
SSL domain name
applications. As I've repeatedly referenced ... this puts the CAs in catch22 
... they
need improved integrity of domain name infrastructure (attacks on ownership 
records of domain
name ownership and then being issued valid SSL certificate) ... which comes 
with lots of
DNSSEC ... but that also eliminates much of the need for SSL domain 
certificates.

as per prior reference about original working on SSL for electronic commerce 
... at least for
the financial industry I've repeatedly shown that digital certificates were 
redundant
and superfluous. I also shown that at the time, the addition of digital 
certificates
increased the payload size by two orders of magnitude (besides being redundant 
and superfluous).
That apparently motivated the compressed digital certificate financial 
standard effort ...
trying to reduce digital certificates so that the payload bloat was only ten 
times (instead
of hundred times) ... in large part by eliminating all information that the 
processing
institution already had. I demonstrated that processing institution would have 
all
information and therefor digital certificates could be reduced to zero bytes 
... so
instead of eliminating redundant and superfluous digital certificates ... it 
was possible
to mandate that zero byte certificates be appended to every transaction (it 
would be
possible to digitally sign a payment transaction for authentication ... and 
rely on
the individual's financial institution to have registered the person's public 
key ... w/o
having to increase the size of every payment transaction in the world by 100 
times just
to transmit a redundant and superfluous appended digital certificate).

I like the interchange at panel discussion in early 90s ACM SIGMOD ballroom 
open session,
somebody in the audience asked what was all this x.5xx stuff about and one of 
the panelists
said it was a bunch of networking engineers trying to reinvent 1960s database 
technology.

there was some amount of participation by the information assurance directorate 
in financial
industry standards meetings. at various times there were references to rifts 
between IA
and SIGINT ... but for all I know that may be kabuki theater. I was fairly 
vocal about
any backdoors could put financial industry at risk for bad guys discovering the 
vulnerabilities
... and wanted KISS applied to as much as possible (and backdoors forbidden)

there are other agendas in much of this. at the start of the century there
were several safe internet payment products pitched to major merchants 
(accounting for 70%
of internet transactions) which got high acceptance. Merchants have been 
indoctrinated for
decades that a large part of interchange fee is proportional to associated 
fraud rate ...
and the merchants were expecting an order of magnitude reduction in their fees 
(with
the safe products). Then came the cognitive dissonance when the banks told the 
merchants that
rather than major reduction in interchange fees with the safe payment 
products ... there would
effectively be a surcharge added to the highest fee that they were already 
paying (and all the
safe efforts collapse).

Part of the issue was that the bottom line for large issuing banks was 40%-60% 
from these
fees and an order of magnitude reduction in those fees would be a big hit to
their bottom line (the size of fees in part justified by fraud rates). The 
safe products
going a long way to eliminating most fraud and commoditizing the payment 
transaction
business ... which would also lower the bar for entry by competition.

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-07 Thread Gregory Perry
On 09/07/2013 04:20 PM, Phillip Hallam-Baker wrote:

Before you make silly accusations go read the VeriSign Certificate Practices 
Statement and then work out how many people it takes to gain access to one of 
the roots.

The Key Ceremonies are all videotaped from start to finish and the auditors 
have reviewed at least some of the ceremonies. So while it is not beyond the 
realms of possibility that such a large number of people were suborned, I think 
it drastically unlikely.

Add to which Jim Bizdos is not exactly known for being well disposed to the NSA 
or key escrow.


Hacking CAs is a poor approach because it is a very visible attack. Certificate 
Transparency is merely automating and generalizing controls that already exist.

But we can certainly add them to S/MIME, why not.

VeriSign is one single certificate authority.  There are many, many more 
certificate authorities spread across the world, and unless you can guarantee 
an air-gapped network with tightly constrained physical security controls and a 
secret videotaped bohemian ceremony such as the one you reference above at each 
and every one of those CAs, then maybe it's not such a silly accusation to 
think that root CAs are routinely distributed to multinational secret services 
to perform MITM session decryption on any form of communication that derives 
its security from the CA PKI.

To whit:  ...Mozilla maintains a list of at least 57 trusted root CAs, though 
multiple commercial CAs or their resellers may share the same trusted root). 
[http://en.wikipedia.org/wiki/Certificate_authority]http://en.wikipedia.org/wiki/Certificate_authority

Another relevant read:  
http://www.quora.com/SSL-Certificates/How-many-intermediate-Certificate-Authorities-are-there#

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

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-07 Thread Phillip Hallam-Baker
On Sat, Sep 7, 2013 at 5:19 AM, ianG i...@iang.org wrote:

 On 7/09/13 10:15 AM, Gregory Perry wrote:

  Correct me if I am wrong, but in my humble opinion the original intent
 of the DNSSEC framework was to provide for cryptographic authenticity
 of the Domain Name Service, not for confidentiality (although that
 would have been a bonus).



 If so, then the domain owner can deliver a public key with authenticity
 using the DNS.  This strikes a deathblow to the CA industry.  This threat
 is enough for CAs to spend a significant amount of money slowing down its
 development [0].

 How much more obvious does it get [1] ?


Good theory only the CA industry tried very hard to deploy and was
prevented from doing so because Randy Bush abused his position as DNSEXT
chair to prevent modification of the spec to meet the deployment
requirements in .com.

DNSSEC would have deployed in 2003 with the DNS ATLAS upgrade had the IETF
followed the clear consensus of the DNSEXT working group and approved the
OPT-IN proposal. The code was written and ready to deploy.

I told the IESG and the IAB that the VeriSign position was no bluff and
that if OPT-IN did not get approved there would be no deployment in .com. A
business is not going to spend $100million on deployment of a feature that
has no proven market demand when the same job can be done for $5 million
with only minor changes.


CAs do not make their money in the ways you imagine. If there was any
business case for DNSSEC I will have no problem at all finding people
willing to pay $50-100 to have a CA run their DNSSEC for them because that
is going to be a lot cheaper than finding a geek with the skills needed to
do the configuration let alone do the work.

One reason that PGP has not spread very far is that there is no group that
has a commercial interest in marketing it.

At the moment revenues from S/MIME are insignificant for all the CAs.
Comodo gives away S/MIME certs for free. Its just not worth enough to try
to charge for right now.

If we can get people using secure email or DNSSEC on a large scale then CAs
will figure out how to make money from it. But right now nobody is making a
profit from either.


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

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-07 Thread Gregory Perry
On 09/07/2013 05:03 PM, Phillip Hallam-Baker wrote:

Good theory only the CA industry tried very hard to deploy and was prevented 
from doing so because Randy Bush abused his position as DNSEXT chair to prevent 
modification of the spec to meet the deployment requirements in .com.

DNSSEC would have deployed in 2003 with the DNS ATLAS upgrade had the IETF 
followed the clear consensus of the DNSEXT working group and approved the 
OPT-IN proposal. The code was written and ready to deploy.

I told the IESG and the IAB that the VeriSign position was no bluff and that if 
OPT-IN did not get approved there would be no deployment in .com. A business is 
not going to spend $100million on deployment of a feature that has no proven 
market demand when the same job can be done for $5 million with only minor 
changes.

And this is exactly why there is no real security on the Internet.  Because the 
IETF and standards committees and working groups are all in reality political 
fiefdoms and technological monopolies aimed at lining the pockets of a select 
few companies deemed worthy of authenticating user documentation for purposes 
of establishing online credibility.

There is no reason for any of this, and I would once again cite to Bitcoin as 
an example of how an entire secure online currency standard can be created and 
maintained in a decentralized fashion without the need for complex hierarchies 
of quasi-political commercial interests.

Encrypting SMTP is trivial, it's all about the standard to make it happen.  
Encrypting IPv6 was initially a mandatory part of the spec, but then it somehow 
became discretionary.  The nuts and bolts of strong crypto have been around for 
decades, but the IETF and related standards powers to be are more interested 
in creating a global police state than guaranteeing some semblance of 
confidential and privacy for Internet users.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-07 Thread Jeffrey I. Schiller
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Sep 07, 2013 at 09:14:47PM +, Gregory Perry wrote:
 And this is exactly why there is no real security on the Internet.
 Because the IETF and standards committees and working groups are all
 in reality political fiefdoms and technological monopolies aimed at
 lining the pockets of a select few companies deemed worthy of
 authenticating user documentation for purposes of establishing
 online credibility.
 ...
 Encrypting IPv6 was initially a mandatory part of the spec,
 but then it somehow became discretionary.  The nuts and bolts of
 strong crypto have been around for decades, but the IETF and related
 standards powers to be are more interested in creating a global
 police state than guaranteeing some semblance of confidential and
 privacy for Internet users.

I’m sorry, but I cannot let this go unchallenged. I was there, I saw
it. For those who don’t know, I was the IESG Security Area Director
from 1994 - 2003. (by myself until 1998 after which we had two co-AD’s
in the Security Area). During this timeframe we formed the TLS working
group, the PGP working group and IPv6 became a Draft Standard. Scott
Bradner and I decided that security should be mandatory in IPv6, in
the hope that we could drive more adoption.

The IETF was (and probably still is) a bunch of hard working
individuals who strive to create useful technology for the
Internet. In particular IETF contributors are in theory individual
contributors and not representatives of their employers. Of course
this is the theory and practice is a bit “noisier” but the bulk of
participant I worked with were honest hard working individuals.

Security fails on the Internet for three important reasons, that have
nothing to do with the IETF or the technology per-se (except for point
3).

 1.  There is little market for “the good stuff”. When people see that
 they have to provide a password to login, they figure they are
 safe... In general the consuming public cannot tell the
 difference between “good stuff” and snake oil. So when presented
 with a $100 “good” solution or a $10 bunch of snake oil, guess
 what gets bought.

 2.  Security is *hard*, it is a negative deliverable. You do not know
 when you have it, you only know when you have lost it (via
 compromise). It is therefore hard to show return on investment
 with security. It is hard to assign a value to something not
 happening.

 2a. Most people don’t really care until they have been personally
 bitten. A lot of people only purchase a burglar alarm after they
 have been burglarized. Although people are more security aware
 today, that is a relatively recent development.

 3.  As engineers we have totally and completely failed to deliver
 products that people can use. I point out e-mail encryption as a
 key example. With today’s solutions you need to understand PK and
 PKI at some level in order to use it. That is likely requiring a
 driver to understand the internal combustion engine before they
 can drive their car. The real world doesn’t work that way.

No government conspiracy required. We have seen the enemy and it is...

-Jeff

___
Jeffrey I. Schiller
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room E17-110A, 32-392
Cambridge, MA 02139-4307
617.910.0259 - Voice
j...@mit.edu
http://jis.qyv.name
___
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iD8DBQFSK7xM8CBzV/QUlSsRApyUAKCB6GpP/hUHxtOQNGjSB5FDZS8hFACfVec6
pPw4Xvukq3OqPEkmVZKl0c8=
=9/UP
-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 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] 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] 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] 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] 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] 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] 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


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] 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] 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] 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 John Gilmore
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:

  *  NSA employees participted throughout, and occupied leadership roles
 in the committee and among the editors of the documents

  *  Every once in a while, someone not an NSA employee, but who had
 longstanding ties to NSA, would make a suggestion that reduced
 privacy or security, but which seemed to make sense when viewed
 by people who didn't know much about crypto.  For example, 
 using the same IV (initialization vector) throughout a session,
 rather than making a new one for each packet.  Or, retaining a
 way to for this encryption protocol to specify that no encryption
 is to be applied.

  *  The resulting standard was incredibly complicated -- so complex
 that every real cryptographer who tried to analyze it threw up
 their hands and said, We can't even begin to evaluate its
 security unless you simplify it radically.  See for example:

https://www.schneier.com/paper-ipsec.html

 That simplification never happened.

 The IPSEC standards also mandated support for the null
 encryption option (plaintext hiding in supposedly-encrypted
 packets), for 56-bit Single DES, and for the use of a 768-bit
 Diffie-Hellman group, all of which are insecure and each of which
 renders the protocol subject to downgrade attacks.

  *  The protocol had major deployment problems, largely resulting from
 changing the maximum segment size that could be passed through an
 IPSEC tunnel between end-nodes that did not know anything about
 IPSEC.  This made it unusable as a drop-in privacy improvement.

  *  Our team (FreeS/WAN) built the Linux implementation of IPSEC, but
 at least while I was involved in it, the packet processing code
 never became a default part of the Linux kernel, because of
 bullheadedness in the maintainer who managed that part of the
 kernel.  Instead he built a half-baked implementation that never
 worked.  I have no idea whether that bullheadedness was natural,
 or was enhanced or inspired by NSA or its stooges.

In other circumstances I also found situations where NSA employees
explicitly lied to standards committees, such as that for cellphone
encryption, telling them that if they merely debated an
actually-secure protocol, they would be violating the export control
laws unless they excluded all foreigners from the room (in an
international standards committee!).  The resulting paralysis is how
we ended up with encryption designed by a clueless Motorola employee
-- and kept secret for years, again due to bad NSA export control
advice, in order to hide its obvious flaws -- that basically XOR'd
each voice packet with the same bit string!  Their encryption
scheme for the control channel, CMEA, was almost as bad, being
breakable with 2^24 effort and small numbers of ciphertexts:

  https://www.schneier.com/cmea-press.html

To this day, no mobile telephone standards committee has considered
or adopted any end-to-end (phone-to-phone) privacy protocols.  This is
because the big companies involved, huge telcos, are all in bed with
NSA to make damn sure that working end-to-end encryption never becomes
the default on mobile phones.

John Gilmore


___
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


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] 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] 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] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread Phillip Hallam-Baker
OK how about this:

If a person at Snowden's level in the NSA had any access to information
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.

What was important in Ultra was the fact that the Germans never discovered
they were being intercepted and decrypted. They would have strengthened
their cipher immediately if they had known it was broken.


So either the NSA has committed an unpardonable act of carelessness (beyond
the stupidity of giving 50,000 people like Snowden access to information
that should not have been shared beyond 500) or the program involves lower
strength ciphers that we would not recommend the use of but are still there
in the cipher suites.

I keep telling people that you do not make a system more secure by adding
the choice of a stronger cipher into the application. You make the system
more secure by REMOVING the choice of the weak ciphers.

I would bet that there is more than enough DES traffic to be worth attack
and probably quite a bit on IDEA as well. There is probably even some 40
and 64 bit crypto in use.


Before we assume that the NSA is robbing banks by using an invisibility
cloak lets consider the likelihood that they are beating up old ladies and
taking their handbags.


On Thu, Sep 5, 2013 at 3:58 PM, Perry E. Metzger pe...@piermont.com wrote:

 I would like to open the floor to *informed speculation* about
 BULLRUN.

 Informed speculation means intelligent, technical ideas about what
 has been done. It does not mean wild conspiracy theories and the
 like. I will be instructing the moderators (yes, I have help these
 days) to ruthlessly prune inappropriate material.

 At the same time, I will repeat that reasonably informed
 technical speculation is appropriate, as is any solid information
 available.


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




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

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread Tim Dierks
On Thu, Sep 5, 2013 at 4:57 PM, Perry E. Metzger pe...@piermont.com wrote:

 On Thu, 5 Sep 2013 16:53:15 -0400 Perry E. Metzger
 pe...@piermont.com wrote:
   Anyone recognize the standard?
 
  Please say it aloud. (I personally don't recognize the standard
  offhand, but my memory is poor that way.)

 There is now some speculation in places like twitter that this refers
 to Dual_EC_DRBG though I was not aware that was widely enough deployed
 to make a huge difference here, and am not sure which international
 group is being mentioned. I would be interested in confirmation.


I believe it is Dual_EC_DRBG. The ProPublica
storyhttp://www.propublica.org/article/the-nsas-secret-campaign-to-crack-undermine-internet-encryptionsays:

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

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

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread Eric Murray

On 09/05/2013 01:57 PM, Perry E. Metzger wrote:

and am not sure which international group is being mentioned.


ISO.   Not that narrows it down much.

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread Bernie Cosell
On 5 Sep 2013 at 16:11, Phillip Hallam-Baker wrote:

 I would bet that there is more than enough DES traffic to be worth
 attack 
 and probably quite a bit on IDEA as well. There is probably even some 40
 and 64 bit crypto in use.

Indeed -- would you (or any of us) guess that NSA could break TDES these 
days?

/Bernie\

-- 
Bernie Cosell Fantasy Farm Fibers
mailto:ber...@fantasyfarm.com Pearisburg, VA
--  Too many people, too few sheep  --   



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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread Eric Murray

The NYT article is pretty informative:
(http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html)

Because strong encryption can be so effective, classified N.S.A. 
documents make clear, the agency’s success depends on working with 
Internet companies — by getting their voluntary collaboration, forcing 
their cooperation with court orders or surreptitiously stealing their 
encryption keys or altering their software or hardware.


N.S.A. documents show that the agency maintains an internal database of 
encryption keys for specific commercial products, called a Key 
Provisioning Service, which can automatically decode many messages. If 
the necessary key is not in the collection, a request goes to the 
separate Key Recovery Service, which tries to obtain it.


How keys are acquired is shrouded in secrecy, but independent 
cryptographers say many are probably collected by hacking into 
companies’ computer servers, where they are stored


Also interesting:

Cryptographers have long suspected that the agency planted 
vulnerabilities in a standard adopted in 2006 by the National Institute 
of Standards and Technology, the United States’ encryption standards 
body, and later by the International Organization for Standardization, 
which has 163 countries as members.


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


“Eventually, N.S.A. became the sole editor,” the memo says.

Anyone recognize the standard?

Eric

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread John Kelsey
First, I don't think it has anything to do with Dual EC DRGB.  Who uses it?  

My impression is that most of the encryption that fits what's in the article is 
TLS/SSL.  That is what secures most encrypted content going online.  The easy 
way to compromise that in a passive attack is to compromise servers' private 
keys, via cryptanalysis or compromise or bad key generation.  For server side 
TLS using RSA, guessing just the client's random values ought to be enough to 
read the traffic.  

For active attacks, getting alternative certs issued for a given host and 
playing man in the middle would work.  

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.  
What does most of the world's TLS?  OpenSSL and a few other libraries, is my 
guess.  But someone must have good data about this.  

My broader question is, how the hell did a sysadmin in Hawaii get hold of 
something that had to be super secret?  He must have been stealing files from 
some very high ranking people.  

--John

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread arxlight
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

What surprises me is that anyone is surprised.  If you believed
OpenBSD's Theo de Raadt and Gregory Perry back in late 2010, various
government agencies (in this specific case the FBI- though one wonders
if they were the originating agency) have been looking to introduce
weaknesses wholesale into closed AND open source software and OS
infrastructures for some time.  Over a decade in his example.

(See: http://marc.info/?l=openbsd-techm=129236621626462w=2)

Those of us old enough might marvel at the fact that going back to the
late 1980s a huge dust up was caused by the allegations that Swiss
firm Crypto AG introduced backdoors into their products at the
behest of Western (read: United States and the BND) intelligence
agencies, products that, at the time, were in widespread use by
foreign governments who, one presumes, could not afford to field their
own national cryptology centers to protect their own infrastructure
(or were just lazy and seduced by a Swiss flag on the corporate
domicile of Crypto AG).

For the unwashed on the list, Wikipedia (and Der Spiegel) relate the
story of (probably) hapless Crypto AG salesman Hans Buehler's 1992
arrest by the Iranian authorities after those allegations came to
light, and the fact that Crypto AG paid a $1m ransom for him (but then
later billed him for the $1m--you stay classy, Crypto AG).

(See: http://en.wikipedia.org/wiki/Crypto_AG)

But fear not.  Governments and NGOs around the world will be pleased
to know that Crypto AG lives on and continues to provide superior
crypto and security solutions to foreign institutions of all kinds,
including:

National security councils, national competence centres, e-government
authorities, encryption authorities, national banks, ministries of
defence, combined/joint commands, cyber commands, air forces, land
forces, naval forces, special forces, military intelligence services,
defence encryption authorities, ministries of foreign affairs and
numerous international organisations, ministries of the interior,
presidential guards, critical infrastructure authorities, homeland
security authorities, intelligence services, police forces, and cyber
forces.

(See: http://www.crypto.ch/ - The inclusion of a shot of the
Patrouille Suisse is an especially nice touch.  I often drive by their
offices in Steinhausen and was stunned to realize a few years ago that
they are thriving- I can only imagine what the mortgage on that place
costs).

I expect that today many of us feel quite naive at being shocked by
those penetration revelations (sorry, allegations) given that it seems
highly probable now that anyone using any sort of Microsoft, Cisco,
Google, Facebook, Yahoo, YouTube, Skype, AOL or Apple product has now
been elevated to a collection priority that seemed confined to the
Irans of the world in the 1990s and early 2000s.

Perry wondered after the unpardonable carelessness of the NSA in
giving 50,000 Snowden's access to a Powerpoint with all the Prism
partners. I would argue that the NSA had good cause to think no one
would notice or care given how many people who should know MUCH MUCH
better still send Crypto AG scads of money. And going back to the days
of toad.com hasn't this always been the story?

Security is expensive. Most people (and some governments) are cheap.

There's something about the present political climate in the United
States that really interests me. Mere mention of the word fascism in
any context other than sarcasm seems to brand one quite instantly as a
tin-foil nutjob. Granted, I think the world fascism is as overused
as the word communism, but it bears mentioning that the usurpation
of corporate entities and industry by the state to its own purposes is
one of the classic tenants of fascism.  I'm sure the list's readers
sense where I'm going with this by now.

It is hard to escape noticing that the NSA and its sister and orbital
agencies have long since broken the traditional firewall and morphed
themselves into domestic surveillance agencies.  But the United States
is late to the party here.

In the world of finance it was long understood that certain
state-dominated Russian firms were front-running a number of U.S.
economic indicators prior to release.  The rumor at the time was that
this activity stopped cold after a security audit at the offending
U.S. agencies.  It's possible that the story was apocryphal, but I
sort of doubt it.  The economic intelligence apparatus of foreign
intelligence services was the place to be if you wanted to find
yourself in the good graces of your nation-state.  (It's not an
accident that Nikolay Patolichev, once the Soviet Union's Foreign
Trade Minister, led the pack having been awarded the Order of Lenin
twelve times).

Of course, drafting otherwise independent-appearing private
enterprises to the purposes of the state was popular then (the CIA
would routinely interview U.S. businessmen and businesswomen after
trips to jurisdictions 

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread Perry E. Metzger
On Thu, 5 Sep 2013 19:14:53 -0400 John Kelsey crypto@gmail.com
wrote:
 First, I don't think it has anything to do with Dual EC DRGB.  Who
 uses it?

It did *seem* to match the particular part of the story about a
subverted standard that was complained about by Microsoft
researchers. I would not claim that it is the most important part of
the story.

 My impression is that most of the encryption that fits what's in
 the article is TLS/SSL.

Yes, and if they have a real hole there they're exploiting, that is
quite disturbing. If they're merely using a hodge-podge of techniques
to get keys, it is less worrying.

 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.

 What does most of the  world's TLS?  OpenSSL and a few other
 libraries, is my guess.  But someone must have good data about this.
 
 My broader question is, how the hell did a sysadmin in Hawaii get
 hold of something that had to be super secret?  He must have been
 stealing files from some very high ranking people.  

I believe there was already discussion in the press on that latter
point, but I think it is less germane to our discussion here and
would prefer that we avoid speculating on things that are only of
human/gossip interest.

Perry
-- 
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-05 Thread Perry E. Metzger
On Thu, 5 Sep 2013 16:53:15 -0400 Perry E. Metzger
pe...@piermont.com wrote:
  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.”
  
  “Eventually, N.S.A. became the sole editor,” the memo says.
  
  Anyone recognize the standard?
 
 Please say it aloud. (I personally don't recognize the standard
 offhand, but my memory is poor that way.)

There is now some speculation in places like twitter that this refers
to Dual_EC_DRBG though I was not aware that was widely enough deployed
to make a huge difference here, and am not sure which international
group is being mentioned. I would be interested in confirmation.

Perry
-- 
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-05 Thread Perry E. Metzger
On Thu, 05 Sep 2013 13:33:48 -0700 Eric Murray er...@lne.com wrote:
 The NYT article is pretty informative:
 (http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html)
[...]
 Also interesting:
 
 Cryptographers have long suspected that the agency planted 
 vulnerabilities in a standard adopted in 2006 by the National
 Institute of Standards and Technology, the United States’
 encryption standards body, and later by the International
 Organization for Standardization, which has 163 countries as
 members.
 
 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.”
 
 “Eventually, N.S.A. became the sole editor,” the memo says.
 
 Anyone recognize the standard?

Please say it aloud. (I personally don't recognize the standard
offhand, but my memory is poor that way.)

BTW, I will now openly speculate if the deeply undeployable key
management protocols for IPSec that originated at the NSA were an
accident. I had enough involvement not to feel overly strongly that
this is what happened, but it does lead one to wonder strongly.

Perry
-- 
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-05 Thread Perry E. Metzger
On Thu, 5 Sep 2013 15:58:04 -0400 Perry E. Metzger
pe...@piermont.com wrote:
 I would like to open the floor to *informed speculation* about
 BULLRUN.

Here are a few guesses from me:

1) I would not be surprised if it turned out that some people working
for some vendors have made code and hardware changes at the NSA's
behest without the knowledge of their managers or their firm. If I
were running such a program, paying off a couple of key people here
and there would seem only rational, doubly so if the disclosure of
their involvement could be made into a crime by giving them a
clearance or some such.

2) I would not be surprised if some of the slow speed at which
improved/fixed hashes, algorithms, protocols, etc. have been adopted
might be because of pressure or people who had been paid off.

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. Whether I am correct or not, such behavior clearly serves
the interest of those who would do bad things.

3) I would not be surprised if random number generator problems in a
variety of equipment and software were not a very obvious target,
whether those problems were intentionally added or not.

4) Choices not to use things like Diffie-Hellman in TLS connections
on the basis that it damages user experience and the like should be
viewed with enormous suspicion.

5) Choices not to make add-ons available in things like chat clients
or mail programs that could be used for cryptography should be viewed
with suspicion.

Perry
-- 
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-05 Thread Phillip Hallam-Baker
On Thu, Sep 5, 2013 at 3:58 PM, Perry E. Metzger pe...@piermont.com wrote:

 I would like to open the floor to *informed speculation* about
 BULLRUN.

 Informed speculation means intelligent, technical ideas about what
 has been done. It does not mean wild conspiracy theories and the
 like. I will be instructing the moderators (yes, I have help these
 days) to ruthlessly prune inappropriate material.

 At the same time, I will repeat that reasonably informed
 technical speculation is appropriate, as is any solid information
 available.


http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security
• The NSA spends $250m a year on a program which, among other goals, works
with technology companies to covertly influence their product designs.

I believe this confirms my theory that the NSA has plants in the IETF to
discourage moves to strong crypto.

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

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread Phillip Hallam-Baker
On Thu, Sep 5, 2013 at 4:41 PM, Perry E. Metzger pe...@piermont.com wrote:

 On Thu, 5 Sep 2013 15:58:04 -0400 Perry E. Metzger
 pe...@piermont.com wrote:
  I would like to open the floor to *informed speculation* about
  BULLRUN.

 Here are a few guesses from me:

 1) I would not be surprised if it turned out that some people working
 for some vendors have made code and hardware changes at the NSA's
 behest without the knowledge of their managers or their firm. If I
 were running such a program, paying off a couple of key people here
 and there would seem only rational, doubly so if the disclosure of
 their involvement could be made into a crime by giving them a
 clearance or some such.


Or they contacted the NSA alumni working in the industry.



 2) I would not be surprised if some of the slow speed at which
 improved/fixed hashes, algorithms, protocols, etc. have been adopted
 might be because of pressure or people who had been paid off.



 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. Whether I am correct or not, such behavior clearly serves
 the interest of those who would do bad things.


I think it is subtler that that. Trying to block a strong cipher is too
obvious. Much better to push for something that is overly complicated or
too difficult for end users to make use of.

* The bizare complexity of IPSEC.

* Allowing deployment of DNSSEC to be blocked in 2002 by blocking a
technical change that made it possible to deploy in .com.

* Proposals to deploy security policy information (always send me data
encrypted) have been consistently filibustered by people making nonsensical
objections.

3) I would not be surprised if random number generator problems in a
 variety of equipment and software were not a very obvious target,
 whether those problems were intentionally added or not.


Agreed, the PRNG is the easiest thing to futz with.

It would not surprise me if we discovered kleptography at work as well.


 4) Choices not to use things like Diffie-Hellman in TLS connections
 on the basis that it damages user experience and the like should be
 viewed with enormous suspicion.

 5) Choices not to make add-ons available in things like chat clients
 or mail programs that could be used for cryptography should be viewed
 with suspicion.


I think the thing that discouraged all that was the decision to make end
user certificates hard to obtain (still no automatic spec) and expire after
a year.

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

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread Perry E. Metzger
On Thu, 05 Sep 2013 16:43:59 -0400 Bernie Cosell
ber...@fantasyfarm.com wrote:
 On 5 Sep 2013 at 16:11, Phillip Hallam-Baker wrote:
 
  I would bet that there is more than enough DES traffic to be worth
  attack 
  and probably quite a bit on IDEA as well. There is probably even
  some 40 and 64 bit crypto in use.
 
 Indeed -- would you (or any of us) guess that NSA could break TDES
 these days?

The articles make it sound much more like implementation flaws that
have been intentionally placed in software and hardware, and a
select few bad protocols and standards. I'm not going to say that it
is impossible that they can break 3DES at this point, but it doesn't
sound like that's what is being discussed here.

-- 
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-05 Thread Eric Murray

Bruce Schneier explains the Dual_EC_DRBG attack:

http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread Lance James
Hi all,


If you read the articles carefully, you'll note that at no point does the
NSA appear to have actually broken the *cryptography* in use.  It's hard to
get concrete details from such vague writing and no access to the the
original documents, but it sounds like they've mostly gotten a lot of
backdoors in *systems* (not algorithms, though they may have tried that
with Dual_EC_DRBG in NIST SP 800-90 in 2006 ... which lasted barely a year
before public cryptographers flagged it).


Basically, the summary of this new information appears to be best given by
Paul Kocher, who noted that the NSA had pushed for a backdoor key escrow
system with the Clipper Chip, was denied, ... and they went and did it
anyway, without telling anyone.  In this case, it wasn't a mandated key
escrow backdoor, but through a combination of targeted interception and
strong-arming companies like Google and Microsoft, they got enough.


It's the same old story of crypto in the real world: Don't attack the
algorithm; Attack the system.


Better story here:
http://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html


On Thu, Sep 5, 2013 at 3:58 PM, Perry E. Metzger pe...@piermont.com wrote:

 I would like to open the floor to *informed speculation* about
 BULLRUN.

 Informed speculation means intelligent, technical ideas about what
 has been done. It does not mean wild conspiracy theories and the
 like. I will be instructing the moderators (yes, I have help these
 days) to ruthlessly prune inappropriate material.

 At the same time, I will repeat that reasonably informed
 technical speculation is appropriate, as is any solid information
 available.


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




-- 
Lance James
http://soundcloud.com/lancejames
Office: 760-262-4141
l lan...@securescience.netan...@gmail.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread Jerry Leichter
[This drifts from the thread topic; feel free to attach a different subject 
line to it]

On Sep 5, 2013, at 4:41 PM, Perry E. Metzger wrote:
 3) I would not be surprised if random number generator problems in a
 variety of equipment and software were not a very obvious target,
 whether those problems were intentionally added or not.
Random number generators make for a very interesting target.  Getting decent 
amounts of entropy on conventional machines is very difficult.  Servers have 
almost no random variation in their environments; desktops somewhat more; 
modern laptops, yet more.  Virtualization - now extremely common on the server 
side - makes things even harder.  But even laptops don't have much.  So we're 
left trying to distill enough randomness for security - a process that's 
error-prone and difficult to check.

So ... along comes Intel with a nice offer:  Built-in randomness on their 
latest chips.  Directly accessible to virtual machines, solving the very 
difficult problems they pose.  The techniques used to generate that randomness 
are published.  But ... how could anyone outside a few chip designers at Intel 
possibly check that the algorithm wasn't, in some way, spiked?  For that 
matter, how could anyone really even check that the outputs of the hardware Get 
Random Value instruction were really generated by the published algorithm?

Randomness is particularly tricky because there's really no way to test for a 
spiked random number generator (unless it's badly spiked, of course).  Hell, 
every encryption algorithm is judged by its ability to generate streams of bits 
that are indistinguishable from random bits (unless you know the key).

Now, absolutely, this is speculation.  I know of no reason to believe that the 
NSA, or anyone else, has influenced the way Intel generates randomness; or that 
there is anything at all wrong with Intel's implementation.  But if you're 
looking for places an organization like the NSA would really love to insert 
itself - well, it's hard to pick a better one.

Interestingly, though, there's good news here as well.  While it's hard to get 
at sources of entropy in things like servers, we're all carrying computers with 
excellent sources of entropy in our pockets.  Smartphones have access to a 
great deal of environmental data - accelerometers, one or two cameras, one or 
two microphones, GPS, WiFi, and cell signal information (metadata, data, signal 
strength) - more every day.  This provides a wealth of entropy, and it's hard 
to see how anyone could successfully bias more than a small fraction of it.  
Mix these together properly and you should be able to get extremely high 
quality random numbers.  Normally, we assume code on the server side is 
better and should take the major role in such tasks as providing randomness.  
Given what we know now about the ability of certain agencies to influence what 
runs on servers, *in general*, we need to move trust away from them.  The case 
is particularly strong in the case of randomness.

Of course, there's a whole other layer of issue introduced by the heavily 
managed nature of phone software.
-- Jerry


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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread Jerry Leichter
On Sep 5, 2013, at 7:14 PM, John Kelsey wrote:
 My broader question is, how the hell did a sysadmin in Hawaii get hold of 
 something that had to be super secret?  He must have been stealing files from 
 some very high ranking people.  
This has bothered me from the beginning.  Even the first leaks involved 
material that you would expect to only be available to highly trusted people 
*well up in the organization* - they were slides selling capabilities to 
managers and unlikely to be shown to typical employees, cleared or not.  My 
immediate impression was that we were looking at some disgruntled higher-up.

The fact that these are coming from a sysadmin - who would never have reason to 
get legitimate access to pretty much *any* of the material leaked so far - is a 
confirmation of a complete breakdown of NSA's internal controls.  They seem to 
know how to do cryptography and cryptanalysis and all that stuff - but basic 
security and separation of privileges and internal monitoring ... that seems to 
be something they are just missing.

Manning got to see all kinds of material that wasn't directly related to his 
job because the operational stuff was *deliberately* opened up in an attempt to 
get better analysis.  While he obviously wasn't supposed to leak the stuff, he 
was authorized to look at it.  I doubt the same could be said of Snowden.  
Hell, when I had a data center manager working for me, we all understood that 
just because root access *let* you look at everyone's files, you were not 
*authorized* to do so without permission.

One of the things that must be keeping the NSA guys up night after night is:  
If Snowden could get away with this much without detection, who's to say what 
the Chinese or the Russians or who knows who else have managed to get?  Have 
they spiked the spikers, grabbing the best stuff the NSA manages to find?

-- Jerry

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread Perry E. Metzger
On Fri, 06 Sep 2013 12:13:48 +1200 Peter Gutmann
pgut...@cs.auckland.ac.nz wrote:
 Perry E. Metzger pe...@piermont.com writes:
 
 I would like to open the floor to *informed speculation* about
 BULLRUN.
 
 Not informed since I don't work for them, but a connect-the-dots:
 
 1. ECDSA/ECDH (and DLP algorithms in general) are incredibly
 brittle unless you get everything absolutely perfectly right.

I'm aware of the randomness issues for ECDSA, but what's the issue
with ECDH that you're thinking of?

 2. The NSA has been pushing awfully hard to get everyone to switch
 to ECDSA/ECDH.

Yes, and 24 hours ago I would have said that was because they
themselves depended on the use of commercial products with such
algorithms available (as in Suite B.) Now I'm less sure.

 Wasn't Suite B promulgated in the 2005-2006 period?

Yes, though it doesn't sound like Suite B is what the article
meant when discussing standards.

 Peter (who choses RSA over ECC any time, follow a few basic rules
 and you're safe with RSA while ECC is vulnerable to all manner of
 attacks, including many yet to be discovered).

Many people out there seem to claim the opposite of course. The
current situation doesn't give us a definitive way to resolve such an
argument.

RSA certainly appears to require vastly longer keys for the same
level of assurance as ECC.

-- 
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-05 Thread Peter Fairbrother
BULLRUN seems to be just an overarching name for several wide programs 
to obtain plaintext of passively encrypted internet communications by 
many different methods.


While there seem to be many non-cryptographic attacks included in the 
BULLRUN program, of particular interest is the cryptographic attack 
mentioned in the Snowden papers and also hinted at in earlier US 
congressional manouverings for NSA funding.


The most obvious target of attack is some widespread implementation of 
SSL/TLS, and while it might just be an attack against a reduced 
keyspace, eg password-guessing or RNG compromise, I wonder whether NSA 
have actually made a big cryptographic break against some cipher, and if 
so, against what?


Candidate ciphers are:

3DES
RC4
AES

and key establishment mechanisms:

RSA
DH
ECDH


I don't think a break in another cipher or KEM would be widespread 
enough to matter much. Assuming NSA (or possibly GCHQ) have made a big 
break:


I don't think it's against 3DES or RC4, though the latter is used a lot 
more than people imagine.


AES? Maybe, but a break in AES would be a very big deal. I don't know 
whether hiding that would be politically acceptable.


RSA? Well, maybe indeed. Break even a few dozen RSA keys per month, and 
you get a goodly proportion of all internet encrypted traffic. It's just 
another advance on factorisation.


If you can break RSA you can probably break DH as well.

ECDH? Again quite possible, especially against the curves in use - but 
perhaps a more widespread break against ECDH is possible as well. The 
math says that it can be done starting with a given curve (though we 
don't know how to do it), and you only need to do the hard part once per 
curve.





My money? RSA.


But even so, double encrypting with two different ciphers (and using two 
different KEMs) seems a lot more respectable now.


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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread Peter Gutmann
Perry E. Metzger pe...@piermont.com writes:

I would like to open the floor to *informed speculation* about BULLRUN.

Not informed since I don't work for them, but a connect-the-dots:

1. ECDSA/ECDH (and DLP algorithms in general) are incredibly brittle unless
   you get everything absolutely perfectly right.

2. The NSA has been pushing awfully hard to get everyone to switch to
   ECDSA/ECDH.

Wasn't Suite B promulgated in the 2005-2006 period?

Peter (who choses RSA over ECC any time, follow a few basic rules and you're
   safe with RSA while ECC is vulnerable to all manner of attacks,
   including many yet to be discovered).

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread David Mercer
On Thursday, September 5, 2013, Jerry Leichter wrote:

 [This drifts from the thread topic; feel free to attach a different
 subject line to it]

 On Sep 5, 2013, at 4:41 PM, Perry E. Metzger wrote:
  3) I would not be surprised if random number generator problems in a
  variety of equipment and software were not a very obvious target,
  whether those problems were intentionally added or not.
 Random number generators make for a very interesting target.  Getting
 decent amounts of entropy on conventional machines is very difficult.
  Servers have almost no random variation in their environments; desktops
 somewhat more; modern laptops, yet more.  Virtualization - now extremely
 common on the server side - makes things even harder.  But even laptops
 don't have much.  So we're left trying to distill enough randomness for
 security - a process that's error-prone and difficult to check.


Virtual private servers are a very big problem. Virtual machine deployment
systems at very large hosting providers have been found to use the same
/dev/urandom initialization for many thousands of machines. It comes from
not re-seeding from /dev/random on provisioning, and running with the same
seed as was in the VM template when it was 'cut'.

I know because I fixed it at places I worked as a contractor. I know at
least one competitor had the issue. No knowledge if it was ever fixed
there. Don't trust seeds you didn't generate. Think about Amazon AWS
instances all spinning up on demand with the exact same init code and prng
seed (this example is not the ones i dealt with, butnis perhaps a larger
problem). You always have a window after startup where you can predicte the
state of the kernel level prng. Not a big one, but it is real and in the
wild.

-David Mercer



-- 
David Mercer - http://dmercer.tumblr.com
IM:  AIM: MathHippy Yahoo/MSN: n0tmusic
Facebook/Twitter/Google+/Linkedin: radix42
FAX: +1-801-877-4351 - BlackBerry PIN: 332004F7
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

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

I think you're ascribing way too much of the usual standards committee
crapification effect to enemy action.  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.

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

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread Perry E. Metzger
On Fri, 06 Sep 2013 13:50:54 +1200 Peter Gutmann
pgut...@cs.auckland.ac.nz wrote:
 Perry E. Metzger pe...@piermont.com writes:
 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.

Maybe. Yesterday I would have consistently ascribed things to
bureaucracy instead of malice. Today, I'm less sure. At the very
least, the current revelations make such things less benevolent --
whether from malice or stupidity, we can no longer sit on security
fixes on the basis that no one will exploit them and they're not
important to the user.

Perry
-- 
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-05 Thread Peter Gutmann
Perry E. Metzger pe...@piermont.com writes:

I'm aware of the randomness issues for ECDSA, but what's the issue with ECDH
that you're thinking of?

It's not just randomness, it's problems with DLP-based crypto in general.  For
example there's the scary tendency of DLP-based ops to leak the private key
(or at least key bits) if you get even the tiniest thing wrong.  For example
if you follow DSA's:

  k = G(t,KKEY) mod q

then you've leaked your x after a series of signatures, so you need to know 
that you generate a large-than-required value before reducing mod q.  The 
whole DLP family is just incredibly brittle.

RSA certainly appears to require vastly longer keys for the same level of
assurance as ECC.

That's assuming that the threat is cryptanalysis rather than bypass.  Why
bother breaking even 1024-bit RSA when you can bypass?

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread Jon Callas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Sep 5, 2013, at 7:01 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote:

 Perry E. Metzger pe...@piermont.com writes:
 
 I'm aware of the randomness issues for ECDSA, but what's the issue with ECDH
 that you're thinking of?
 
 It's not just randomness, it's problems with DLP-based crypto in general.  For
 example there's the scary tendency of DLP-based ops to leak the private key
 (or at least key bits) if you get even the tiniest thing wrong.  For example
 if you follow DSA's:
 
  k = G(t,KKEY) mod q
 
 then you've leaked your x after a series of signatures, so you need to know 
 that you generate a large-than-required value before reducing mod q.  The 
 whole DLP family is just incredibly brittle.

I don't disagree by any means, but I've been through brittleness with both 
discrete log and RSA, and it seems like only a month ago that people were 
screeching to get off RSA over to ECC to avert the cryptocalypse. And that 
the ostensible reason was that there are new discrete log attacks -- which was 
just from Mars and I thought that that proved the people didn't know what they 
were talking about. Oh, wait, it *was* only a month ago! Silly me.

Crypto experts issue a call to arms to avert the cryptopocalypse

http://arstechnica.com/security/2013/08/crytpo-experts-issue-a-call-to-arms-to-avert-the-cryptopocalypse/

Discrete log has brittleness. RSA has brittleness. ECC is discrete log over a 
finite field that's hard to understand. It all sucks.

 
 RSA certainly appears to require vastly longer keys for the same level of
 assurance as ECC.
 
 That's assuming that the threat is cryptanalysis rather than bypass.  Why
 bother breaking even 1024-bit RSA when you can bypass?

And now we're back to the hymnal you and I have been singing from. It ain't the 
crypto, it's the software.

Jon


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

wj8DBQFSKTuhsTedWZOD3gYRAhiJAKDaNIw1ztD/Lj1WAW3U/pOtkpoybQCgoW6o
nd08pq+l1QiViF7cPATuPig=
=Z3wh
-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-05 Thread Jerry Leichter
The actual documents - some of which the Times published with few redactions - 
are worthy of a close look, as they contain information beyond what the 
reporters decided to put into the main story.  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.  It's 
never been clear whether these kinds of notes are just guesses by the 
reporters, come from their own sources, or com
 e from Snowden himself.  The Washington Post got burned on one they wrote.  
But in this case, it's hard to come up with an alternative explanation.

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.  Makes you 
wonder.  (I know for a fact that NSA has been interested in this area of 
mathematics for a *very* long time:  A mathematician I knew working in the area 
of algebraic curves (of which elliptic curves are an example) was re
 cruited by - and went to - NSA in about 1975.  I heard indirectly from him 
after he was at NSA, where he apparently joined an active community of people 
with related interests.  This is a decade before the first public suggestion 
that elliptic curves might be useful in cryptography.  (But maybe NSA was just 
doing a public service, advancing the mathematics of algebraic curves.)

NSA has two separate roles:  Protect American communications, and break into 
the communications of adversaries.  Just this one example shows that either (a) 
the latter part of the mission has come to dominate the former; or (b) the 
current definition of an adversary has become so broad as to include pretty 
much everyone.

Now, the NSA will say:  Only *we* can make use of these back doors.  But given 
the ease with which Snowden got access to so much information ... why should we 
believe they can keep such secrets?
-- Jerry

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread Jon Callas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sep 5, 2013, at 7:31 PM, Jerry Leichter leich...@lrw.com 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.  Makes you wonder.

Yes, but. The reason we are using those curves is because they want them for 
products they buy. 

  (I know for a fact that NSA has been interested in this area of mathematics 
 for a *very* long time:  A mathematician I knew working in the area of 
 algebraic curves (of which elliptic curves are an example) was re
 
 cruited by - and went to - NSA in about 1975.  I heard indirectly from him 
 after he was at NSA, where he apparently joined an active community of people 
 with related interests.  This is a decade before the first public suggestion 
 that elliptic curves might be useful in cryptography.  (But maybe NSA was 
 just doing a public service, advancing the mathematics of algebraic curves.)

I think it might even go deeper than that. ECC was invented in the civilian 
world by Victor Miller and Neal Koblitz (independently) in 1985, so they've 
been planning for breaking it even a decade before its invention. 

 NSA has two separate roles:  Protect American communications, and break into 
 the communications of adversaries.  Just this one example shows that either 
 (a) the latter part of the mission has come to dominate the former; or (b) 
 the current definition of an adversary has become so broad as to include 
 pretty much everyone.

I definitely believe (b). However, I also think that they aren't a monolith, 
and we know that each part of the mission is the adversary of the other. I 
don't believe that the IA people would do a bad job to support SIGINT. Once you 
start down that path, it's easy to get to madness, or perhaps merely evidence 
that they have time travel.

I'll add that they have a third mission -- run the government's classified 
computer network, and that *that* mission is the one that Snowden worked for.

Jon


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

wj8DBQFSKUQLsTedWZOD3gYRAlZvAKCtZP9iy1eyGBq4UbG9xO9jmNscigCZAYVv
M13sxiFZ5ch7PhgoIh1LziA=
=fEtw
-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-05 Thread Jerry Leichter
On Sep 5, 2013, at 10:19 PM, Jon Callas wrote:
 I don't disagree by any means, but I've been through brittleness with both 
 discrete log and RSA, and it seems like only a month ago that people were 
 screeching to get off RSA over to ECC to avert the cryptocalypse. And that 
 the ostensible reason was that there are new discrete log attacks -- which 
 was just from Mars and I thought that that proved the people didn't know what 
 they were talking about. Oh, wait, it *was* only a month ago! Silly me.
 
 Crypto experts issue a call to arms to avert the cryptopocalypse
 
 http://arstechnica.com/security/2013/08/crytpo-experts-issue-a-call-to-arms-to-avert-the-cryptopocalypse/
 
 Discrete log has brittleness. RSA has brittleness. ECC is discrete log over a 
 finite field that's hard to understand. It all sucks.
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 only are the techniques brittle and increasingly under suspicion, but in
practice almost all of our public key crypto inherently relies on CA's - a 
structure that's just *full* of well-known problems and vulnerabilities.  
Public key *seems to* distribute the risk - you just get the other guy's 
public key and you can then communicate with him safely.  But in practice it 
*centralizes* risks:  In CA's, in single magic numbers that if revealed allow 
complete compromise for all connections to a host (and we now suspect they 
*are* being revealed.)

We need to re-think everything about how we do cryptography.  Many decisions 
were made based on hardware limitations of 20 and more years ago.  More 
efficient claims from the 1980's often mean nothing today.  Many decisions 
assumed trust models (like CA's) that we know are completely unrealistic.  
Mobile is very different from the server-to-server and dumb-client-to-server 
models that were all anyone thought about the time.  (Just look at SSL:  It has 
the inherent assumption that the server *must* be authenticated, but the client 
... well, that's optional and rarely done.)  None of the work then anticipated 
the kinds of attacks that are practical today.

I pointed out in another message that today, mobile endpoints potentially have 
access to excellent sources of randomness, while servers have great difficulty 
getting good random numbers.  This is the kind of fundamental change that needs 
to inform new designs.
-- Jerry

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread Jerry Leichter
 Another interesting goal:  Shape worldwide commercial cryptography 
 marketplace to make it more tractable to advanced cryptanalytic capabilities 
 being developed by NSA/CSS. ... 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.  Makes you wonder.
 Yes, but. The reason we are using those curves is because they want them for 
 products they buy. 
They 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.  The time-honored way to do that is to embed some secret 
in the design of the system.  NSA, knowing the secret, can break in; no one 
else can.  There have been claims in this direction since NSA changed the 
S-boxes in DES.  For DES, we now know that was to protect against differential 
cryptanalysis.  No one's ever shown a really convincing case of such an 
embedded secret hack being done ... but now if you claim it can't happen, you 
have to explain how the goal in NSA's budget could be carried out in a way 
consistent with the two constraints.  Damned if I know

 (I know for a fact that NSA has been interested in this area of mathematics 
 for a *very* long time:  A mathematician I knew working in the area of 
 algebraic curves (of which elliptic curves are an example) was recruited by 
 - and went to - NSA in about 1975
 I think it might even go deeper than that. ECC was invented in the civilian 
 world by Victor Miller and Neal Koblitz (independently) in 1985, so they've 
 been planning for breaking it even a decade before its invention. 
I'm not sure exactly what you're trying to say.  Yes, Miller and Koblitz are 
the inventors of publicly known ECC, and a number of people (Diffie, Hellman, 
Merkle, Rivest, Shamir, Adelman) are the inventors of publicly known public-key 
cryptography.  But in fact we now know that Ellis, Cocks, and Williamson at 
GCHQ anticipated their public key cryptography work by several years - but in 
secret.

I think the odds are extremely high that NSA was looking at cryptography based 
on algebraic curves well before Miller and Koblitz.  Exactly what they had 
developed, there's no way to know.  But of course if you want to do good 
cryptography, you also have to do cryptanalysis.  So, yes, it's quite possible 
that NSA was breaking ECC a decade before its (public) invention.  :-)

-- Jerry

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread Jon Callas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sep 5, 2013, at 8:02 PM, Jerry Leichter leich...@lrw.com wrote:

 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.

(And by the way, please say symmetric key as opposed to public key -- if 
you say private key then someone will inevitably get confused and think you 
mean the private half of a public key pair and there will be tears.)

 
 Not only are the techniques brittle and increasingly under suspicion, but in
 practice almost all of our public key crypto inherently relies on CA's - a 
 structure that's just *full* of well-known problems and vulnerabilities.  
 Public key *seems to* distribute the risk - you just get the other guy's 
 public key and you can then communicate with him safely.  But in practice it 
 *centralizes* risks:  In CA's, in single magic numbers that if revealed allow 
 complete compromise for all connections to a host (and we now suspect they 
 *are* being revealed.)

I have to disagree. You don't need a CA. 

There's a very long rant I could make here, and I'll try to keep it a summary.

Much of the system we have is built needing CAs, but it was only built that 
way. A long time ago, the certificate structure we're still vestigially using 
had as one of its goals a way to keep the riff-raff from using crypto. I 
remember when I got my first PEM certificate, I had to send my blinking 
passport off to MITRE for two weeks so they could let me encrypt the crapola 
that was sitting on my disk unencrypted. It was harder to get a cert than it 
was to get a visa to Saudi Arabia! So much of what we would have encrypted we 
just printed on paper and put in a file cabinet. Excuse me, I'm starting on 
that rant I said I wouldn't do.

The major problem one has with public key is knowing that the public key of the 
endpoint you want to talk to us actually the right public key. Trusted 
Introducers of any sort are one way to solve the problem. CAs are merely an 
industrialized form of Trusted Introducer and not ipso facto bad. The way that 
Web PKI (as it's now being called) is using Trusted Introducers is 
suboptimal, but ironically, we are on the inflection point of a real 
honest-to-whomever fix to them in the form of Certificate Transparency. That 
suggests even another discussion, one that I promised Ben I'd get to eventually.

The major problem with the certificate system is actually the browsers, in my 
opinion, because they actively discourage using certificates in any other way. 
If browsers, for example, allowed you to use a private cert with a user 
experience that was ultimately SSH-like (also called TOFU for Trust On First 
Use) as opposed to putting big blood-red danger warnings up, it would work out 
better for everyone including the CAs.

But anyway, there are other solutions. They range from some variant of Direct 
Trust being TOFU or even using a Kerberos-like system to hand you a key, or 
what we do in ZRTP, or lots of other things. 

The bottom line is that if you want to send someone a message securely and you 
have never talked to them before, you have no other way to deal with it than 
public key systems. 

(Or you can re-define the problem. Suppose I want to send Glenn Greenwald a 
message and his Kerberos controller gives me an AES key, I merely have to trust 
the controller. If we say that trusting him is the same as trusting the 
controller, then yeah, sure, it works. That's a suitable redefinition in which 
the KDC is isomorphic to a CA. But if we allow public key, then I could get Mr. 
Greenwald's public key from an intermediary who is not necessarily an 
authority, or even self-publish keys. It's done with PGP all the time.)


 
 We need to re-think everything about how we do cryptography.  Many decisions 
 were made based on hardware limitations of 20 and more years ago.  More 
 efficient claims from the 1980's often mean nothing today.  Many decisions 
 assumed trust models (like CA's) that we know are completely unrealistic.  
 Mobile is very different from the server-to-server and dumb-client-to-server 
 models that were all anyone thought about the time.  (Just look at SSL:  It 
 has the inherent assumption that the server *must* be authenticated, but the 
 client ... well, that's optional and rarely done.)  None of the work then 
 anticipated the kinds of attacks that are practical today.

I concur that the way that browsers and web servers us SSL is suboptimal. This 
doesn't mean that a solution is impossible, it only means we have 

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread Jon Callas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Sep 5, 2013, at 8:24 PM, Jerry Leichter leich...@lrw.com wrote:

 Another interesting goal:  Shape worldwide commercial cryptography 
 marketplace to make it more tractable to advanced cryptanalytic 
 capabilities being developed by NSA/CSS. ... 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.  Makes you 
 wonder.
 Yes, but. The reason we are using those curves is because they want them for 
 products they buy. 
 They 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.  The time-honored way to do that is to embed 
 some secret in the design of the system.  NSA, knowing the secret, can break 
 in; no one else can.  There have been claims in this direction since NSA 
 changed the S-boxes in DES.  For DES, we now know that was to protect against 
 differential cryptanalysis.  No one's ever shown a really convincing case of 
 such an embedded secret hack being done ... but now if you claim it can't 
 happen, you have to explain how the goal in NSA's budget could be carried out 
 in a way consistent with the two constraints.  Damned if I know
 
 (I know for a fact that NSA has been interested in this area of mathematics 
 for a *very* long time:  A mathematician I knew working in the area of 
 algebraic curves (of which elliptic curves are an example) was recruited by 
 - and went to - NSA in about 1975
 I think it might even go deeper than that. ECC was invented in the civilian 
 world by Victor Miller and Neal Koblitz (independently) in 1985, so they've 
 been planning for breaking it even a decade before its invention. 
 I'm not sure exactly what you're trying to say.  Yes, Miller and Koblitz are 
 the inventors of publicly known ECC, and a number of people (Diffie, Hellman, 
 Merkle, Rivest, Shamir, Adelman) are the inventors of publicly known 
 public-key cryptography.  But in fact we now know that Ellis, Cocks, and 
 Williamson at GCHQ anticipated their public key cryptography work by several 
 years - but in secret.
 
 I think the odds are extremely high that NSA was looking at cryptography 
 based on algebraic curves well before Miller and Koblitz.  Exactly what they 
 had developed, there's no way to know.  But of course if you want to do good 
 cryptography, you also have to do cryptanalysis.  So, yes, it's quite 
 possible that NSA was breaking ECC a decade before its (public) invention.  
 :-)

What am I trying to say?

I'm being a bit of a smartass. I'm sorry, it's a character flaw, but it's one 
that amuses me. I'll be blunt, instead.

There is a lot of discussion here -- not really so much from you but in general 
--  that in my opinion is fighting the last war. Sometimes that last war is the 
crypto wars of the 1990s, but sometimes it's WWII. Yeah, yeah, if you don't 
remember history you'll repeat it, but we need to look through the windshield, 
not the rear view mirror.

My smartassedness was saying that by looking at the past, gawrsh, maybe we're 
seeing a time machine!

The present war is not the previous one. This one is not about crypto. It 
involves crypto, but it's not *about* it. The bright young things of 1975 who 
went to work for the NSA wrote theorems and got lifetime employment. The bright 
young things of 2010 write shellcode and are BAH contractors.

There are two major trends that are happening. One is that they're hitting the 
network, not the crypto. Look at Dave Aitel's career, not your mathematician 
friend. Aitel is one of the ones that got away, and what he talks about is what 
we're seeing that they are doing. If you have to listen to one of the old 
school mathematicians, listen to Shamir -- they go around crypto. (And 
actually, we need to look not at Aitel as he left in 2002, but the bright young 
thing who left last year, but I think I'm making my point.)

The other major trend is that outsourcing, contracting and other things ruined 
the social contract between them and the people who work there. (This reflects 
the other other problem which is that the social contract between them and us 
seems to be void.) Nonetheless, Aitel and others left and are leaving because 
no longer do they tap you on the shoulder in college and then there's the 
mutual backscratching of a lifelong career. Now a contractor knows that when 
the contract is over, they're out of a job. And when the contractor sees 
malfeasance that goes all the way up to the Commander-in-Chief, they look at 
what their employment agreement said, as well as the laws that apply to them.

If you're in that environment and you see malfeasance, you go to your superior 
and it's a felony not to. If your superior is part of the malfeasance, you go 

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread John Kelsey

 On Thu, 5 Sep 2013 19:14:53 -0400 John Kelsey crypto@gmail.com
 wrote:
 First, I don't think it has anything to do with Dual EC DRGB.  Who
 uses it?
 
 It did *seem* to match the particular part of the story about a
 subverted standard that was complained about by Microsoft
 researchers. I would not claim that it is the most important part of
 the story.

One thing I can say for certain:  NSA did not write SP 800-90.  (That was the 
implication of from the New York Times article.). That was mostly Elaine 
Barker, my coworker, with me providing a lot of text around technical issues.  
The algorithms all came out of work from ANSI X9.82 Part 3, which Elaine also 
wrote with lots of input and text from me and the rest of the editing 
committee.  We worked with NSA people on this, and X9.82 Part 2 (the entropy 
source section) was written entirely by NSA people, but it isn't easy for me to 
see how anyone could stick a trapdoor in that.  We're still working with NSA 
people on SP 800-90B, which includes a lot of stuff on testing entropy sources. 
 

When I started there was an RSA based algorithm which we eventually dropped 
(analogous to bbs), Dual EC DRBG, the hash drbg (which is still in 800-90 in a 
much-changed version for backward comatibility reasons, because the 
standardization process took forever and people started designing to the X9.82 
standard before it was done--this was also the reason we ended up keeping the 
Dual EC DRBG) and an X9.17 based thing we got rid of.  A bunch of the symmetric 
stuff in there is mine--I made changes the the hash DRBG to address 
time/memory/data tradeoffs, and wrote the HMAC DRBG and CTR DRBG.  I also 
changed around the hash df and wrote the bc df.  

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

...
 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.  That looks to be what happened with the Henninger and Lenstra 
results regarding lots of RSA keys with shared moduli.  That flaw implies a 
huge number of easily factored RSA keys out there, thanks to insufficient 
entropy and calling /dev/urandom on a system where it won't block even if it 
thinks it has zero entropy.  (This was a multi-level screw up, as I understand 
it, between a Linux version and OpenSSL and the implementors of various 
appliance network devices.). 

It would be smarter for any crypto software to use the OS source for some seed 
material, and then combine it with both unique or nearly unique information and 
anything that's likely to have some entropy, and use that to initialize a good 
PRNG.  (I'd use CTR DRBG.)   Your ethernet address doesn't have any entropy, 
but it works like a salt in a password hashing scheme--an attacker must now 
rerun his attack for each individual instance of the crypto software. 

In general, software that uses crypto should probably be trying to gather 
entropy wherever possible, not just trusting the OS.  And it should use that 
entropy plus the OS' entropy to seed its own PRNG.  And it should throw in any 
information that might distinguish this instance from other instances, to force 
any attackers to rerun their attack on each instance individually.  

When I saw the keystore stuff, I thought bad key generation.  Henninger found 
a bunch of RSA 
keys from the same make of devices that were sharing primes, thanks to really 
awful entropy collection.  If those devices had been collecting 40 bits of 
entropy for the first prime, she might never have found a pair of keys with a 
shared prime.  But someone using analogous methods might be able to generate 
2^{40} primes ahead of time, and efficiently run each new RSA key sent in 
against that list and break a large fraction of the keys.

I think long-term public keys are the