subject:"Re\: \[Cryptography\] Opening Discussion\: Speculation on \"BULLRUN\""

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

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

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

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

 Perhaps it's time to move away from public-key entirely!  We have a classic 
 paper - Needham and Schroeder, maybe? - showing that private key can do 
 anything public key can; it's just more complicated and less efficient.
 
 Not really. The Needham-Schroeder you're thinking of is the essence of 
 Kerberos, and while Kerberos is a very nice thing, it's hardly a replacement 
 for public key.
 
 If you use a Needham-Schroeder/Kerberos style system with symmetric key 
 systems, you end up with all of the trust problems, but on steroids
I don't think we're really in disagreement here.  Much of what you say later in 
the message is that the way we are using symmetric-key systems (CA's and such), 
and the way browsers work, are fundamentally wrong, and need to be changed.  
And that's really the point:  The system we have is all of a piece, and 
incremental changes, sadly, can only go so far.  We need to re-think things 
from the ground up.  And I'll stand by my contention that we need to re-examine 
things we think we know, based on analyses done 30 years ago.  Good theorems 
are forever, but design choices apply those theorems to real-world 
circumstances.  So much has changed, both on the technical front and on 
non-technical fronts, that the basis for those design choices has fundamentally 
changed.

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

-- Jerry


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

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

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

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

Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

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

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

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

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

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

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

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

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

[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

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

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

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

-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

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

-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

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

 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

-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