[Cryptography] Ars Technica on the Taiwanese National ID smart card break

2013-09-17 Thread Perry E. Metzger
Weeks after the informal announcement, the Taiwanese National ID
smartcard break is finally getting press. It is a great example of
a piece of certified crypto hardware that works poorly because
of bad random number generation.

Good explanation for your technical but not security oriented friends
in Ars Technica:

http://arstechnica.com/security/2013/09/fatal-crypto-flaw-in-some-government-certified-smartcards-makes-forgery-a-snap/

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


Re: [Cryptography] paranoid cryptoplumbing is a probably not defending the weakest point

2013-09-17 Thread Perry E. Metzger
On Tue, 17 Sep 2013 12:15:48 -0400 Jerry Leichter leich...@lrw.com
wrote:
 Actually, I think there is a potentially interesting issue here:
 RC4 is faster and requires significantly fewer resources than
 modern block ciphers.  As a result, people would really like to use
 it - and actually they *will* continue to use it even in the face
 of the known attacks (which, *so far*, are hardly fatal except in
 specialized settings).

If you are dealing with huge numbers of connections, you probably have
hardware and AES is plenty fast -- modern Intel hardware accelerates
it, too.

(If you really want a fast stream cipher, why not use ChaCha20 or
something else that is probably much better than RC4? I mean, if
you're going to propose changing it, as you do, it won't interoperate
anyway, so you can substitute something better.)

In any case, I would continue to suggest that the weakest point
(except for RC4) is (probably) not going to be your symmetric cipher.
It will be protocol flaws and implementation flaws. No point in
making the barn out of titanium if you're not going to put a door on
it.

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


Re: [Cryptography] Radioactive random numbers

2013-09-17 Thread Perry E. Metzger
On Tue, 17 Sep 2013 11:35:34 -0400 Perry E. Metzger
pe...@piermont.com wrote:
 Added c...@panix.com -- if you want to re-submit this (and maybe not
 top post it) I will approve it...

Gah! Accidentally forwarded that to the whole list, apologies.

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


[Cryptography] paranoid cryptoplumbing is a probably not defending the weakest point

2013-09-17 Thread Perry E. Metzger
On the Paranoid Cryptoplumbing discussion:

I'd like to note quite strongly that (with certain exceptions like
RC4) the odds of wholesale failures in ciphers seem rather small
compared to the odds of systems problems like bad random number
generators, sabotaged accelerator hardware, stolen keys, etc., and a
smart attacker goes for the points of weakness.

I'm not going to put my admin hat on and stop the discussion so long
as it remains relatively sane and technical, but for most purposes it
is probably just reinforcing a steel door in a paper wall.

(Of course, if the endpoints are trusted hardware running a formally
verified capability operating system and you still have time on your
hands, hey, why not? Of course, when I posted a long message about
modern formal verification techniques and how they're now practical,
no one bit on the hook.)

All that said, even I feel the temptation for low performance
applications to do something like Bill Frantz suggests. It is in the
nature of people in our community to like playing with such things.
Just don't take them *too* seriously please.

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


Re: [Cryptography] Radioactive random numbers

2013-09-17 Thread Perry E. Metzger
Added c...@panix.com -- if you want to re-submit this (and maybe not
top post it) I will approve it...

Perry

On Tue, 17 Sep 2013 11:08:43 -0400 Carl Ellison c...@panix.com wrote:
 If you can examine your setup and determine all possible memory in
 the device, count that memory in bit-equivalents, and discover that
 the number of bits is small (e.g., 8), then you can apply Maurer's
 test:
 
 ftp://ftp.inf.ethz.ch/pub/crypto/publications/Maurer92a.pdf
 
 
 Of course, if you're concerned that someone has slipped you a CPU
 chip with a PRNG replacing the RNG, you can't detect that without
 ripping the chip apart.
 
 On 9/12/13 11:00 AM, Perry E. Metzger pe...@piermont.com wrote:
 
 On Wed, 11 Sep 2013 17:06:00 -0700 Tony Arcieri basc...@gmail.com
 wrote:
  It seems like Intel's approach of using thermal noise is fairly
  sound. Is there any reason why it isn't more widely adopted?
 
 Actually, I think things like this mostly have been missing
 because manufacturers didn't understand they were important. Even
 the Raspberry Pi now has an SoC with a hardware RNG.
 
 In addition to getting CPU makers to always include such things,
 however, a second vital problem is how to gain trust that such RNGs
 are good -- both that a particular unit isn't subject to a hardware
 defect and that the design wasn't sabotaged. That's harder to do.
 
 Perry
 -- 
 Perry E. Metzger pe...@piermont.com
 ___
 The cryptography mailing list
 cryptography@metzdowd.com
 http://www.metzdowd.com/mailman/listinfo/cryptography
 
 



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


[Cryptography] Ivan Ristić blog post on TLS best practices

2013-09-17 Thread Perry E. Metzger
Recommends phasing out RC4 among other things:

http://blog.ivanristic.com/2013/09/updated-best-practices-deprecate-rc4.html

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


Re: [Cryptography] The paranoid approach to crypto-plumbing

2013-09-17 Thread Perry E. Metzger
On Mon, 16 Sep 2013 17:47:11 -0700 Bill Frantz
fra...@pwpconsult.com wrote:
 Authentication is achieved by signing the entire exchange with 
 DSA.  --  Change the protocol to sign the exchange with both RSA 
 and DSA and send and check both signatures.

Remember to generate the nonce for DSA using a deterministic method.

 The current data exchange encryption uses SHA1 in HMAC mode and 
 3DES in CBC mode with MAC then encrypt. The only saving grace is 
 that the first block of each message is the HMAC, which will 
 make the known plain text attacks on the protocol harder. -- I 
 would replace this protocol with one that encrypts twice and 
 MACs twice. Using one of the modes which encrypt and MAC in one 
 operation as the inner layer is very tempting with a different 
 cypher in counter mode and a HMAC as the outer layer.

I confess I'm not sure what the current state of research is on MAC
then Encrypt vs. Encrypt then MAC -- you may want to check on that.

Also, you may want to generate your IVs deterministically from a
block cipher in counter mode, and not actually send them on the wire
-- see earlier discussions for why that is good, but in addition to
assuring the IVs are unpredictable and do not repeat, it prevents a
bad actor from using the IV as a covert channel. (Some would argue
against using CBC mode entirely -- see Rogaway's paper on block
cipher modes.)

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


Re: [Cryptography] paranoid cryptoplumbing is a probably not defending the weakest point

2013-09-17 Thread Perry E. Metzger
On Tue, 17 Sep 2013 10:07:38 -0700 Tony Arcieri basc...@gmail.com
wrote:
 The NSA of course participated in active attacks too, but it seems
 their main MO was passive traffic collection.

That's not what I've gotten out of the most recent revelations. It
would seem that they've been evading rather than breaking the crypto:
putting back doors in protocols, stealing keys, encouraging weak
RNGs, adding flaws to hardware, etc. -- as well as doing active
attacks using stolen or broken CA keys.

I don't doubt that they archive everything they can forever, of
course.

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


[Cryptography] Johns Hopkins round table on NSA and Crypto

2013-09-17 Thread Perry E. Metzger
Matthew Green tweeted earlier today that Johns Hopkins will be hosting
a roundtable at 10am EDT tomorrow (Wednesday, September 18th) to
discuss the NSA crypto revelations.

Livestream will be at: https://connect.johnshopkins.edu/jhuisicrypto/ 

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


Re: [Cryptography] PRISM-Proofing and PRISM-Hardening

2013-09-17 Thread Perry E. Metzger
On Tue, 17 Sep 2013 16:52:26 -0400 John Kemp j...@jkemp.net wrote:
 On Sep 17, 2013, at 2:43 PM, Phillip Hallam-Baker
 hal...@gmail.com wrote:
  The objective of PRISM-hardening is not to prevent an
  attack absolutely, it is to increase the work factor for the
  attacker attempting ubiquitous surveillance.
  
  Examples include:
  
  Forward Secrecy: Increases work factor from one public key per
  host to one public key per TLS session.
 
 How does that work if one of PRISMs objectives is to compromise
 data _before_ it is transmitted by subverting its storage in one
 way or another?
 
 Forward secrecy does nothing to impact the work factor in that
 case.

So, PFS stops attackers from breaking all communications by simply
stealing endpoint RSA keys. You need some sort of side channel or
reduction of the RNG output space in order break an individual
communication then.

(Note that this assumes no cryptographic breakthroughs like doing
discrete logs over prime fields easily or (completely theoretical
since we don't really know how to do it) sabotage of the elliptic
curve system in use.)

Given that many real organizations have hundreds of front end
machines sharing RSA private keys, theft of RSA keys may very well be
much easier in many cases than broader forms of sabotage.

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


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

2013-09-16 Thread Perry E. Metzger
On Sat, 14 Sep 2013 20:37:07 -0700 John Gilmore g...@toad.com wrote:
[A very interesting message, and I'm going to reply to just one tiny
detail in it...]
 We in the outside world *invented* all of NSA's infrastructure.
 They buy it from us, and are just users like most computer
 users.  (Yes, they have programmers and they write code, but their
 code seems mostly applications, not lower level OS improvements or
 protocols.  I'm not talking about the parts of NSA that find
 security holes in other peoples' infrastructure, nor the malware
 writers.)

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

(I will not argue with the larger point though.)

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


[Cryptography] Apple and Certificate Pinning

2013-09-16 Thread Perry E. Metzger
I've not been able to figure out if Apple is using certificate
pinning for its applications (including its update systems) that seem
to use PKI. Does anyone know?

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


[Cryptography] ADMIN: entropy of randomness discussion is falling...

2013-09-15 Thread Perry E. Metzger
One wants maximum entropy not only from one's RNG but also from one's
discussions about randomness.

Sadly, entropy is measured based on the level of surprise at the
content, and the level of surprise is going down in the current
discussion. As surprise goes to zero, so does interest on the part of
the couple thousand people reading along.

I'd like to ask participants to please:

1) Write compactly but clearly.
2) Avoid repeating themselves.

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


[Cryptography] Key management, key storage. (was Re: prism proof email, namespaces, and anonymity)

2013-09-14 Thread Perry E. Metzger
On Sat, 14 Sep 2013 17:23:40 +0100 Max Kington
mking...@webhanger.com wrote:
 The keys. This to me is the critical point for widespread adoption,
 key management. How do you do this in a way that doesn't put people
 off immediately.

You don't seem to be entirely talking about key management, given
that you talk about mailpile and parley. Parley seems to be simply
talking about *key storage* for example, which is a different kettle
of fish.

However, on the topic of key management itself, my own proposal was
described here:

http://www.metzdowd.com/pipermail/cryptography/2013-August/016870.html

In summary, I proposed a way you can map IDs to keys through pure
long term observation/widely witnessed events. The idea is not
original given that to some extent things like Certificate
Transparency already do this in other domains.


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


Re: [Cryptography] RSA equivalent key length/strength

2013-09-14 Thread Perry E. Metzger
On Sat, 14 Sep 2013 09:31:22 -0700 Paul Hoffman
paul.hoff...@vpnc.org wrote:
 Also see RFC 3766 from almost a decade ago; it has stood up fairly
 well.

For those not aware, the document, by Paul and Hilarie Orman,
discusses equivalent key strengths and practical brute force methods,
giving extensive detail on how all calculations were done.

A URL for the lazy:

http://tools.ietf.org/html/rfc3766

It is very well done. I'd like to see an update done but it does
feel like the methodology was well laid out and is difficult to
argue with in general. The detailed numbers are slightly different
from others out there, but not so much as to change the general
recommendations that have been floating around.

Their table, from April 2004, looked like this:

   +-+---+--+--+
   | System  |   |  |  |
   | requirement | Symmetric | RSA or DH| DSA subgroup |
   | for attack  | key size  | modulus size | size |
   | resistance  | (bits)| (bits)   | (bits)   |
   | (bits)  |   |  |  |
   +-+---+--+--+
   | 70  | 70|  947 | 129  |
   | 80  | 80| 1228 | 148  |
   | 90  | 90| 1553 | 167  |
   |100  |100| 1926 | 186  |
   |150  |150| 4575 | 284  |
   |200  |200| 8719 | 383  |
   |250  |250|14596 | 482  |
   +-+---+--+--+

They had some caveats, such as the statement that if TWIRL like
machines appear, we could presume an 11 bit reduction in strength --
see the RFC itself for details.

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


[Cryptography] Quantum Computers for Shor's Algorithm (was Re: Perfection versus Forward Secrecy)

2013-09-14 Thread Perry E. Metzger
On Sat, 14 Sep 2013 11:49:50 -0700 Tony Arcieri basc...@gmail.com
wrote:
 We still haven't seen quantum computers built yet which can truly
 rival their conventional electronic brethren, especially if you
 look at it from a cost perspective. DWave computers are interesting
 from a novelty perspective, but not really ready to replace
 existing computers, even for highly specialized tasks like running
 Shor's algorithm.
 
 Nevertheless, if you've been following the trends in quantum
 computers over the last few years, they are getting larger, and
 DWave is an example of them moving out of the labs and turning into
 something you can buy.
 
 I wouldn't be surprised to see a large quantum computer built in
 the next two decades.

DWave has never unambiguously shown their machine actually is a
quantum computer, and even if it is, given its design it very
specifically cannot run Shor's algorithm or anything like it.

I'm unaware of a quantum computer of more than five qbits that has
been demonstrated that can run Shor's algorithm, and that specific
method, using a molecule with five distinct NMR peaks, cannot really
be extended further.

If you can find a reference to quantum computer with more qbits that
can run Shor's algorithm that has been demonstrated in public, I
would be very interested.

(And yes, I'm aware of the two photon device that factored the number
21, though I believe the team used tricks to make that work --
opinions on whether that work could scale would be welcome of course.)

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


Re: [Cryptography] Quantum Computers for Shor's Algorithm (was Re: Perfection versus Forward Secrecy)

2013-09-14 Thread Perry E. Metzger
On Sat, 14 Sep 2013 12:42:22 -0700 Tony Arcieri basc...@gmail.com
wrote:
 Sure, I never said it could ;) I also said that conventional
 computers can still outpace it. I'm certainly NOT saying, that in
 their present capacity, that DWave computers are any sort of threat
 to modern cryptography.
 
 But still, it goes to show that quantum computers are happening.

Given that the DWave design is totally unsuitable for Shor's
algorithm, it seems to have no real bearing on the situation in
either direction.

To break 1024 bit keys (a minimum capability for a useful Shor
machine, I'd say), you need several thousand qbits. I've not heard of
a demonstration of more than a half dozen, and I've seen no
progress on the topic in a while. It isn't like last year we could do
six and the year before five and this year someone announced fifteen
-- there have been no incremental improvements.

It is of course possible that there's been secret research on this at
NSA which has gotten far further, but I would expect that the
manufacturing technology needed to do that would require a huge
number of people to pull off, too many to keep quiet indefinitely.

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


Re: [Cryptography] Stealthy Dopant-Level Hardware Trojans

2013-09-13 Thread Perry E. Metzger
On Fri, 13 Sep 2013 11:49:24 +0200 Eugen Leitl eu...@leitl.org
wrote:
 
 http://people.umass.edu/gbecker/BeckerChes13.pdf
 
 Stealthy Dopant-Level Hardware Trojans[...]

This is pretty clearly a big deal. The fact that you can skew HRNGs
just by fiddling with dopant levels is something I would have
suspected, but now that we know, I think need for chip companies
to provide access to the raw HRNG output has become even more obvious.

It is not a question of not trusting the engineers who work on the
hardware. It is a question of not wanting to trust every
single individual in a long supply chain.

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


[Cryptography] Security is a total system problem (was Re: Perfection versus Forward Secrecy)

2013-09-13 Thread Perry E. Metzger
On Fri, 13 Sep 2013 08:08:38 +0200 Eugen Leitl eu...@leitl.org
wrote:
 Why e.g. SWIFT is not running on one time pads is beyond me.

I strongly suspect that delivering them securely to the vast number
of endpoints involved and then securing the endpoints as well would
radically limit the usefulness. Note that it appears that even the
NSA generally prefers to compromise endpoints rather than attack
crypto.

The problem these days is not that something like AES is not good
enough for our purposes. The problem is that we too often build a
reinforced steel door in a paper wall.

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


Re: [Cryptography] Summary of the discussion so far

2013-09-13 Thread Perry E. Metzger
On Fri, 13 Sep 2013 15:46:58 -0500 Nico Williams
n...@cryptonector.com wrote:
 On Fri, Sep 13, 2013 at 03:17:35PM -0400, Perry E. Metzger wrote:
  On Thu, 12 Sep 2013 14:53:28 -0500 Nico Williams
  n...@cryptonector.com wrote:
   Traffic analysis can't really be defeated, not in detail.
  
  What's wrong with mix networks?
 
 First: you can probably be observed using them.

Sure, but the plan I described a few weeks ago would presumably end
with hundreds of thousands or millions of users if it worked at all.

 Second: I suspect that to be most effective the mix network also
 has to be most inconvenient (high latency, for example).

Sure, that's true for voice and such. However, for messaging
apps, that's not an issue. See my claims here:
http://www.metzdowd.com/pipermail/cryptography/2013-August/016874.html

(That was part of a three message sequence that began with these two:
http://www.metzdowd.com/pipermail/cryptography/2013-August/016870.html
and
http://www.metzdowd.com/pipermail/cryptography/2013-August/016872.html

but only the second of those two is really relevant to this
particular discussion.)

 Third: the mix network had better cross multiple jurisdictions that
 are not accustomed to cooperating with each other.  This seems very
 difficult to arrange.

That's important for onion networks, not mix networks. I understand
that the distinction isn't well understood by most, but it can be
summarized thus: an onion network depends on no one observing the
whole network to provide security, while a mix network uses
sufficient cover traffic and delay induction to prevent people from
being able to learn much even if they can observe the whole network
and control a minority of nodes.

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


Re: [Cryptography] prism proof email, namespaces, and anonymity

2013-09-13 Thread Perry E. Metzger
On Fri, 13 Sep 2013 16:55:05 -0400 John Kelsey crypto@gmail.com
wrote:
 Everyone,
 
 The more I think about it, the more important it seems that any
 anonymous email like communications system *not* include people who
 don't want to be part of it, and have lots of defenses to prevent
 its anonymous communications from becoming a nightmare for its
 participants.  If the goal is to make PRISM stop working and make
 the email part of the internet go dark for spies (which definitely
 includes a lot more than just US spies!), then this system has to
 be something that lots of people will want to use.  
 
 There should be multiple defenses against spam and phishing and
 other nasty things being sent in this system, with enough
 designed-in flexibility to deal with changes in attacker behavior
 over tome.

Indeed. As I said in the message I just pointed Nico at:
http://www.metzdowd.com/pipermail/cryptography/2013-August/016874.html

Quoting myself:

   Spam might be a terrible, terrible problem in such a network since
   it could not easily be traced to a sender and thus not easily
   blocked, but there's an obvious solution to that. I've been using
   Jabber, Facebook and other services where all or essentially all
   communications require a bi-directional decision to enable messages
   for years now, and there is virtually no spam in such systems
   because of it. So, require such bi-directional friending within
   our postulated new messaging network -- authentication is handled
   by the public keys of course. 

 Some thoughts off the top of my head.  Note that while I think all
 these can be done with crypto somehow, I am not thinking of how to
 do them yet, except in very general terms.  
 
 a.  You can't freely send messages to me unless you're on my
 whitelist.  

That's my solution. As I note, it seems to work for Jabber, Facebook
and other such systems, so it may be sufficient.

 b.  This means an additional step of sending me a request to be
 added to your whitelist.  This needs to be costly in something the
 sender cares about--money, processing power, reputation, solving a
 captcha, rate-limits to these requests, whatever.

I'm not sure about that. Jabber doesn't really rate limit the number
of friend requests I get per second but I don't seem to get terribly
many, perhaps because fakes at most could hide some attempted phish
in a user@domain name, which isn't very useful to scammers.

 g.  The format of messages needs to be restricted to block malware,
 both the kind that wants to take over your machine and the kind
 that wants to help the attacker track you down.  Plain text email
 only?  Some richer format to allow foreign language support?  

My claim that I make in my three messages from August 25 is that it
is probably best if we stick to existing formats so that we can
re-use existing clients. My idea was that you still talk IMAP and
SMTP and Jabber to a server you control (a $40 box you get at Best Buy
or the like) using existing mail and chat clients, but that past your
server everything runs the new protocols.

In addition to the message I linked to above, see also:
http://www.metzdowd.com/pipermail/cryptography/2013-August/016870.html
http://www.metzdowd.com/pipermail/cryptography/2013-August/016872.html
for my wider proposals.

I agree this makes email delivered malware continue to be a bit of a
problem, though you could only get it from your friends.

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


Re: [Cryptography] Radioactive random numbers

2013-09-12 Thread Perry E. Metzger
On Wed, 11 Sep 2013 17:06:00 -0700 Tony Arcieri basc...@gmail.com
wrote:
 It seems like Intel's approach of using thermal noise is fairly
 sound. Is there any reason why it isn't more widely adopted?

Actually, I think things like this mostly have been missing
because manufacturers didn't understand they were important. Even
the Raspberry Pi now has an SoC with a hardware RNG.

In addition to getting CPU makers to always include such things,
however, a second vital problem is how to gain trust that such RNGs
are good -- both that a particular unit isn't subject to a hardware
defect and that the design wasn't sabotaged. That's harder to do.

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


Re: [Cryptography] Radioactive random numbers

2013-09-12 Thread Perry E. Metzger
On Wed, 11 Sep 2013 21:06:35 -0400 Marcus D. Leech
mle...@ripnet.com wrote:
 And this is the reason that I'd be in favour of diversity --
 using sound cards, lava-lamps, etc, etc.  Sources that don't
 explicitly identify themselves as the random number generator.

As a practical matter, though, people aren't going to put lava lamps
and cameras in their colos along with every 1U box and blade server.
They also won't attach them to the $40 boxes they buy at Best Buy.

Good solutions probably involve hardware that is well tested, on
motherboard, dirt cheap and easy for software to field validate. Yes,
this is hard.

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


[Cryptography] ADMIN: Please pick appropriate Subject lines...

2013-09-11 Thread Perry E. Metzger
A quick note: many recent postings with very useful content have gone
out with entirely inappropriate Subject: lines because of threads
shifting topics. Always look at your Subject: line and ask yourself
if it should be updated.

(And thank all of you for not top posting. It is appreciated.)

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


Re: [Cryptography] Availability of plaintext/ciphertext pairs (was Re: In the face of cooperative end-points, PFS doesn't help)

2013-09-11 Thread Perry E. Metzger
On Wed, 11 Sep 2013 06:49:45 +0200 Raphael Jacquot
sxp...@sxpert.org wrote:
 according to http://en.wikipedia.org/wiki/Padding_(cryptography) ,
 most protocols only talk about padding at the end of the cleartext
 before encryption. now, how about adding some random at the
 beginning of the cleartext, say, 2.5 times the block size, that is
 40 bytes for the example above, of random stuff before the
 interesting text appears ?

The padding at the end is to make sure that you have a full block of
data for a block cipher, since your actual message will usually be
shorter than a full block. In symmetric systems, it is not per se a
security feature. (Asymmetric 

Adding padding at the front to prevent cryptanalysts from using cribs
(that is, known plaintext) seems useless to me. Even if the padding
was of random length, it is of necessity going to be short. If you
have a technique that depends on known plaintext, crib dragging (that
is, trying all of the small number of possibilities) is easy.


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


[Cryptography] Killing two IV related birds with one stone

2013-09-11 Thread Perry E. Metzger
It occurs to me that specifying IVs for CBC mode in protocols
like IPsec, TLS, etc. be generated by using a block cipher in counter
mode and that the IVs be implicit rather than transmitted kills two
birds with one stone.

The first bird is the obvious one: we now know IVs are unpredictable
and will not repeat.

The second bird is less obvious: we've just gotten rid of a covert
channel for malicious hardware to leak information.

Note that if you still transmit the IVs, a misimplemented client
could still interoperate with a malicious counterparty that did not
use the enforced method for IV calculation. If you don't transmit
the IVs at all but calculate them, the system will not interoperate if
the implicit IVs aren't calculated the same way by both sides, thus
ensuring that the covert channel is closed.

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


Re: [Cryptography] Radioactive random numbers

2013-09-11 Thread Perry E. Metzger
On Thu, 12 Sep 2013 08:47:16 +1000 (EST) Dave Horsfall
d...@horsfall.org wrote:
 Another whacky idea...
 
 Given that there is One True Source of randomness to wit
 radioactive emission, has anyone considered playing with old smoke
 detectors?

People have experimented with all sorts of stuff, and you can make
any of hundreds of methods from cameras+lava lamp+hash function to
sound cards to radioactive sources work if you have budget and time.

The issue is not finding ways to generate entropy. The issue is that
you need something that's cheap and ubiquitous.

User endpoints like cell phones have users to help them generate
entropy, but the world's routers, servers, etc. do not have good
sources, especially at first boot time, and for customer NAT boxes and
the like the price points are vicious.

The attraction of methods that use nothing but a handful of
transistors is that they can be fabricated on chip and thus have
nearly zero marginal cost. The huge disadvantage is that if your
opponent can convince chip manufacturers to introduce small changes
into their design, you're in trouble.

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


Re: [Cryptography] Killing two IV related birds with one stone

2013-09-11 Thread Perry E. Metzger
On Wed, 11 Sep 2013 20:01:28 -0400 Jerry Leichter leich...@lrw.com
wrote:
  ...Note that if you still transmit the IVs, a misimplemented
  client could still interoperate with a malicious counterparty
  that did not use the enforced method for IV calculation. If you
  don't transmit the IVs at all but calculate them, the system will
  not interoperate if the implicit IVs aren't calculated the same
  way by both sides, thus ensuring that the covert channel is
  closed.

 Ah, but where did the session and IV-generating keys come from?
 The same random generator you now don't trust to directly give you
 an IV?

Certainly, but if you remove most or all covert channels, you've
narrowed the problem down to auditing the RNG instead of having to
audit much more of the system. It is all a question of small steps
towards better assurance. No one measure will fix everything.

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


[Cryptography] Fw: how could ECC params be subverted other evidence

2013-09-10 Thread Perry E. Metzger
Forwarding because Adam apparently has distinct envelope and From:
addresses and didn't notice the bounce.

Note that anyone replying and attributing this message to *me* will
be laughed at mercilessly as their message is rejected.

Perry

Begin forwarded message:

Date: Tue, 10 Sep 2013 13:42:57 +0200
From: Adam Back a...@cypherspace.org
To: Perry E. Metzger pe...@piermont.com
Cc: Alexander Klimov alser...@inbox.ru, Cryptography List
cryptography@metzdowd.com, Adam Back a...@cypherspace.org
Subject: Re: [Cryptography] how could ECC params be subverted  other
evidence


Perry wrote:
The Times reported that a standard [...] had been subverted, and
there had been much internal congratulation in a memorandum.  

[...]This was only an example, the context in the Guardian and the
Times made it clear others are probably lurking.

The important potential backdoor is NIST 186-3 curves in Peter
Fairbrother's reply, and I think that would be a good place to focus
analysis.  

(DRBG is largely irrelevant due suspected compromised state since
2007, and very limited use.  It is also a different type of issue -
not backdoored curves, arguably backdoored parameters).

I would like to hear also from other readers, who may have a deeper
understanding of EC math and parameter selection.

I do think people should be careful to distinguish between three
things:

1 political confirmed backdoor claims from whistleblower documents
as interpreted by journalists (technical articles by eg Schneier
exempted);

2 possible backdoor (showing that a parameter or key generation lacks
   sufficient fairness in its generation)

3 actual verifiable sabotage (the actual backdoor keys, previously
   unpublished implausible design failure, software backdoor etc.)

We need accuracy because once the dust has settled people will be
making crypto protocol design  implementation decisions based on
what is concluded.  Speculate away, but be clear.

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


[Cryptography] Reports: NSA, GCHQ used forged certs to impersonate Google

2013-09-10 Thread Perry E. Metzger
The story has been floating around for some days now. Apparently, Man
in the Middle attacks have been used quite extensively, including
against the Brazilian state oil company, and a major international
wire transfer network.

http://www.slate.com/blogs/future_tense/2013/09/09/shifting_shadow_stormbrew_flying_pig_new_snowden_documents_show_nsa_deemed.html

I think this indicates that Certificate Transparency and similar
techniques need to be deployed quickly. CAs have been dead as a
form of real assurance for some time now, but at this point the dance
party on the grave has gone on a bit too long.

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


Re: [Cryptography] Techniques for malevolent crypto hardware

2013-09-10 Thread Perry E. Metzger
On Sun, 8 Sep 2013 15:22:32 -0400 Perry E. Metzger
pe...@piermont.com wrote:
 Ah, now *this* is potentially interesting. Imagine if you have a
 crypto accelerator that generates its IVs by encrypting information
 about keys in use using a key an observer might have or could guess
 from a small search space.

Oh, and of course, if you're doing a DSA style algorithm, you can
leak information in your choice of random nonce. This is yet more
reason to force protocols to use nonces that are deterministic based
on context, and to enforce that.

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

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

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

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


Re: [Cryptography] Fw: how could ECC params be subverted other evidence

2013-09-10 Thread Perry E. Metzger
On Tue, 10 Sep 2013 16:45:23 -0400 John Kelsey crypto@gmail.com
wrote:
 [DBRG] seemed like a really weird place to put a backdoor, because
 it was insanely slow, and it seemed unlikely to get any significant
 use.

As an aside, this is just the instance we know about, partially
because they screwed up, partially because the New York Times saw fit
to let us have confirmation of what was suspected in public.

I presume they've been more careful in other places, and that this is
not their only work. I presume that they knew this would not be
used much and it was only a target of opportunity -- and that they've
gotten much more interesting fixes in elsewhere, perhaps even in
other parts of the NIST RNG standards (though it would *seem* much
harder to gimmick those).

 And I, at least, had internalized the idea that we weren't
 going to get intentional bad advice or sabotage from another part
 of the federal government.

You're not the only person feeling betrayed. For many years, the NSA
people appeared on our doorsteps offering help in many, many
contexts -- IETF for example.

The awful part is, many of them may have been completely sincere.
The IA side of the house *does*, in fact, depend on COTS hardware to
secure most of the Federal Government. They *do* have an interest in
keeping US commercial targets safe from attack.

However, even if many of the NSA people who participated in standards
work were sincere, their good will has been ruined by other NSA
people who used the sincere ones as cover for their
machinations. We now have to be suspicious of all of them, probably
permanently, and that's bad for everyone.

I imagine that there are some people inside the NSA now yelling at
others about how they've made it ever so much harder to fix the
security of most of the Federal Government, which ineed depends on
COTS hardware. Now even if they come to us with really good advice,
we have no idea if we should take it because we can't know they're
not lying to us.

None the less, it is done, and those of us on the outside can't
depend on NSA participants in standards work any longer. A set
of short sighted, foolish decisions have created tragedy for all.


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


Re: [Cryptography] Availability of plaintext/ciphertext pairs (was Re: In the face of cooperative end-points, PFS doesn't help)

2013-09-10 Thread Perry E. Metzger
On Tue, 10 Sep 2013 17:04:04 -0400 Jerry Leichter leich...@lrw.com
wrote:
 Phil Rogoway has a paper somewhere discussing the right way to
 implement cryptographic modes and API's.

It would be useful to get a URL for it.

 In particular, he recommends changing the definition of CBC from:
 
 E_0 = IV # Not transmitted
 E_{i+1} = E(E_i XOR P_{i+1})
 
 to
 
 E_0 = E(IV)  # Not transmitted
 E_{i+1} = E(E_i XOR P_{i+1})

You make no mention there of whether the key used to encrypt the IV
is the same as that used for the plaintext. I presume if you need a
lot of IVs (see protocols like IPsec), and have enough key material, a
second key might be of value for that -- but I don't know what all
the ins and outs are, and would prefer to read the literature...

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


Re: [Cryptography] AES state of the art...

2013-09-09 Thread Perry E. Metzger
On Mon, 9 Sep 2013 14:18:41 +0300 Alexander Klimov
alser...@inbox.ru wrote:
 On Sun, 8 Sep 2013, Perry E. Metzger wrote:
  What's the current state of the art of attacks against AES? Is the
  advice that AES-128 is (slightly) more secure than AES-256, at
  least in theory, still current?
 
 I am not sure what is the exact attack you are talking about, but I 
 guess you misunderstood the result that says: the attack works 
 against AES-256, but not against AES-128 as meaning that AES-128
 is more secure. It can be the case that to break AES-128 the attack
 needs 2^240 time, while to break AES-256 it needs 2^250 time. Here
 AES-128 is not technically broken, since 2^240  2^128, but AES-256
 is broken, since 2^250  2^256, OTOH, AES-256 is still more secure
 against the attack.
 

There is a related key attack against AES-256 that breaks it in order
2^99.5, far worse than 2^250!

However, several people seem to have assured me (in private email)
that they think such related key attacks are not important in
practice.

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


[Cryptography] ADMIN: traffic levels

2013-09-09 Thread Perry E. Metzger
List traffic levels are very high right now.

Although the current situation is worrisome to many of us, the list
becomes less useful to all when it becomes so clogged with posts that
it becomes impossible for any reasonable person to read it.

I and the co-moderators are probably going to start being much more
strict about content until things settle down. Do not be surprised or
offended when you get a rejection -- it is nothing personal.

Some rules of thumb:

SHORT BEATS LONG: Don't ramble, get to the point, avoid unnecessary
asides, trim back what you're quoting to the minimum. This is
especially important in replies on long threads.

IMPORTANT BEATS TRIVIAL: The more real, interesting, and new content,
the more likely we are to forward it.

DON'T BE REDUNDANT: If you already said something a couple of times in
a thread, don't repeat it endlessly. Fixing a clear misunderstanding
is okay, of course.

TECHNICAL BEATS POLITICAL: The list explicitly permits political
postings, but especially when the load is this high, they should
be informative and insightful. I'll almost always forward technical
cryptography and protocol discussion.

BARE LINKS ARE IRRITANTS: If you post a link to something, it should
explain clearly why someone might want to click. Even a sentence will
do.

TOP POSTING IS AN ABOMINATION BEFORE THE MODERATOR: ...and I am an
angry, old-testament sort of moderator, too.

Lastly:

I've had to ban two people in the last week for getting incredibly
insulting after I would not forward their postings. It should go
without saying that calling me a fascist, an NSA plant, etc. is
unlikely to alter my opinion of your posting in a positive way. There
are other, unmoderated forums (with even more volume) -- you know how
to find them if you like.

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


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

2013-09-09 Thread Perry E. Metzger
First, David, thank you for participating in this discussion.

To orient people, we're talking about whether Intel's on-chip
hardware RNGs should allow programmers access to the raw HRNG output,
both for validation purposes to make sure the whole system is working
correctly, and if they would prefer to do their own whitening and
stretching of the output.

On Sun, 08 Sep 2013 21:40:34 -0700 David Johnston d...@deadhat.com
wrote:
  Well, since you personally did this, would you care to explain the
  very strange design decision to whiten the numbers on chip, and
  not provide direct access to the raw unwhitened output.

 #1 So that that state remains secret from things trying to discern
 that state for purposes of predicting past or future outputs of the
 DRBG.

That seems like a misguided rationale. In particular, given that
virtually all crypto software and existing kernels already have to
cope with hardware that does not provide this capability, it is
probably better that a hardware RNG not be a cryptographic
PRNG. It should be a source of actual hard-random bits that feed in
to the commonly used software mechanisms.

If you can't generate enough of them to satisfy all possible demand,
then I think it is architecturally far safer to allow software to
make the decision about how to stretch the scarcity, and in any case,
the software needs to exist anyway because other hardware does not
have the capability.

As it stands, the major consumers of your RNG, like the Linux kernel,
already end up mixing it in to a software RNG rather than implicitly
trusting it. It would be better to go further than this, I think.

A far greater concern than non-Intel engineers being bad at building
a random number generator in softare is that a fabrication flaw, a
post-manufacturing failure, or an intentional fabrication failure
induced by a paid agent would reduce the security of the system. It
is difficult to test such things as the system is constructed.

 #2 So that one thread cannot undermine a second thread by putting
 the DRNG into a broken mode. There is only one DRNG, not one per
 core or one per thread. Having one DRNG per thread would be one of
 the many preconditions necessary before this could be contemplated.

I think the same counterarguments hold. In any case, making it
impossible even for a privileged process like the kernel to test the
thing before returning it to its normal state seems like an
unfortunate choice.

 #3 Any method of access is going have to be documented and
 supported and maintained as a constant interface across many
 generations of chip. We don't throw that sort of thing into the PC
 architecture without a good reason.

There is, however, excellent reason here.

   #4 Obviously there are debug modes to access raw entropy source 
 output. The privilege required to access those modes is the same
 debug access necessary to undermine the security of the system.
 This only happens in very controlled circumstances.

Could you be more explicit about that?

Please note we are not asking this sort of thing out of malice. There
is now a document in wide circulation claiming multiple chip vendors
have had their crypto hardware compromised by intent.

Regardless of your own personal integrity, there are others inside
your organization that may very well be beneficiaries of the $250M a
year the NSA is now spending on undermining security. Indeed, were I
running that program, I would regard your group as a key target and
attempt to place someone inside it. Do you not agree that you're a
major vendor and that your hardware would be a very tempting target
for such a program, which we now know to exist?

 Access to the raw output would have been a massive can of worms.

And yet, you will note that many, many security types would prefer
raw output to a finished cryptographic random number source.

Intel could always provide a standard C routine to do the conversion
from the raw output into a suitable whitened and stretched output.

 The statistical properties of the entropy source are easy to model
 and easy to test online in hardware. They are described in the CRI
 paper if you want to read them.

But, forgive me for saying this, in an environment where the NSA
is spending $250M a year to undermine efforts like your own it is
impossible for third parties to trust black boxes any longer. I think
you may not have absorbed that what a week or two ago was a paranoid
fantasy turns out to be true.

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


Re: [Cryptography] how could ECC params be subverted other evidence

2013-09-09 Thread Perry E. Metzger
On Tue, 10 Sep 2013 00:23:51 +0200 Adam Back a...@cypherspace.org
wrote:
 On Mon, Sep 09, 2013 at 06:03:14PM -0400, Perry E. Metzger wrote:
 On Mon, 9 Sep 2013 14:07:58 +0300 Alexander Klimov wrote:
  No. They are widely used curves and thus a good way to reduce
  conspiracy theories that they were chosen in some malicious way
  to subvert DRBG.
 
 Er, don't we currently have documents from the New York Times and
 the Guardian that say that in fact they *did* subvert them?
 
 From what I could see it was more like people are taking more
 seriously the criticism that they could have subverted the curves
 because the published parameter generation seeds are big hex
 strings (rather than the typical literaly quote or digits of pi),
 and therefore there is no way to verify the parameters were chosen
 fairly.

The Times reported that a standard from about the right time period
that had been criticized in a 2007 paper by some researchers at
Microsoft (who reported a backdoor) had been subverted, and there had
been much internal congratulation in a memorandum. The only such
standard was apparently the one in question.

This is no longer speculation, we now know that they seem to have
done this.

This was only an example, the context in the Guardian and the Times
made it clear others are probably lurking.

As I've said before, a week ago I would have called the entire idea
paranoia. Now, the evidence has changed. When the facts change, I
change my mind.

 Relatedly it seems to me that backdooring is a tricky business,
 especially if you care about plausible deniability, and about
 actual security in the face of blackhats or other state actors who
 may rediscover the sabotaged parameters, design, code, master keys
 in the binary etc and exploit it rather than publish it and have it
 fixed by the vendor.

I think you're hardly the only person to note that this is a very
dangerous game they've played, in some cases literally endangering
people's lives.

 Presumably the reverse engineering deities are warming up their
 softICE to pore over the windows and other OS crypto code.

And, I would imagine, people are probably ripping apart popular
hardware crypto implementations, decapping the chips, and
photographing them as we speak. The memoranda spoke of hardware
crypto systems being subverted.

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


Re: [Cryptography] [cryptography] SSH uses secp256/384r1 which has the same parameters as what's in SEC2 which are the same the parameters as specified in SP800-90 for Dual EC DRBG!

2013-09-09 Thread Perry E. Metzger
On Mon, 9 Sep 2013 14:07:58 +0300 Alexander Klimov
alser...@inbox.ru wrote:
 On Mon, 9 Sep 2013, Daniel wrote:
  Is there anyone on the lists qualified in ECC mathematics that can
  confirm that? 
 
 NIST SP 800-90A, Rev 1 says:
 
  The Dual_EC_DRBG requires the specifications of an elliptic curve
 and two points on the elliptic curve. One of the following NIST
 approved curves with associated points shall be used in
 applications requiring certification under [FIPS 140]. More details
 about these curves may be found in [FIPS 186], the Digital
 Signature Standard.
 
  And what ramifications it has, if any..
 
 No. They are widely used curves and thus a good way to reduce 
 conspiracy theories that they were chosen in some malicious way to 
 subvert DRBG.
 

Er, don't we currently have documents from the New York Times and the
Guardian that say that in fact they *did* subvert them?

Yes, a week ago this was paranoia, but now we have confirmation, so
it is no longer paranoia.

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


Re: [Cryptography] [cryptography] SSH uses secp256/384r1 which has the same parameters as what's in SEC2 which are the same the parameters as specified in SP800-90 for Dual EC DRBG!

2013-09-09 Thread Perry E. Metzger
On Tue, 10 Sep 2013 00:25:20 +0100 Peter Fairbrother
zenadsl6...@zen.co.uk wrote:
 On 09/09/13 23:03, Perry E. Metzger wrote:
 
  On Mon, 9 Sep 2013, Daniel wrote:
  [...] They are widely used curves and thus a good way to reduce
  conspiracy theories that they were chosen in some malicious way
  to subvert DRBG.
 
  Er, don't we currently have documents from the New York Times and
  the Guardian that say that in fact they *did* subvert them?
 
  Yes, a week ago this was paranoia, but now we have confirmation,
  so it is no longer paranoia.
 
 I did not see that, and as far as I can tell there is no actual 
 confirmation.

Quoting:

   Cryptographers have long suspected that the agency planted
   vulnerabilities in a standard adopted in 2006 by the National
   Institute of Standards and Technology 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.”

http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html?pagewanted=all

This has generally been accepted to only match the NIST ECC RNG
standard, i.e. Dual_EC_DRBG, with the critique in question being
On the Possibility of a Back Door in the NIST SP800-90 Dual Ec Prng
which may be found here: http://rump2007.cr.yp.to/15-shumow.pdf

Do you have an alternative theory?

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

[Cryptography] Why are some protocols hard to deploy? (was Re: Opening Discussion: Speculation on BULLRUN)

2013-09-08 Thread Perry E. Metzger
On Sat, 07 Sep 2013 18:50:06 -0700 John Gilmore g...@toad.com wrote:
 It was never clear to me why DNSSEC took so long to deploy,
[...]
 PS: My long-standing domain registrar (enom.com) STILL doesn't
 support DNSSEC records -- which is why toad.com doesn't have DNSSEC
 protection.  Can anybody recommend a good, cheap, reliable domain
 registrar who DOES update their software to support standards from
 ten years ago?

I believe you have answered your own question there, John. Even if we
assume subversion, deployment requires cooperation from too many
people to be fast.

One reason I think it would be good to have future key management
protocols based on very lightweight mechanisms that do not require
assistance from site administrators to deploy is that it makes it
ever so much easier for things to get off the ground. SSH deployed
fast because one didn't need anyone's cooperation to use it -- if you
had root on a server and wanted to log in to it securely, you could
be up and running in minutes.

We need to make more of our systems like that. The problem with
DNSSEC is it is so obviously architecturally correct but so
difficult to do deploy without many parties cooperating that it has
acted as an enormous tar baby.

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


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

2013-09-08 Thread Perry E. Metzger
On Sat, 07 Sep 2013 20:14:10 -0700 Ray Dillinger b...@sonic.net
wrote:
 On 09/06/2013 05:58 PM, Jon Callas wrote:
 
  We know as a mathematical theorem that a block cipher with a back
  door *is* a public-key system. It is a very, very, very valuable
  thing, and suggests other mathematical secrets about hitherto
  unknown ways to make fast, secure public key systems.
 
 
 I've seen this assertion several times in this thread, but I cannot
 help thinking that it depends on what *kind* of backdoor you're
 talking about, because there are some cases in which as a crypto
 amateur I simply cannot see how the construction of an asymmetric
 cipher could be accomplished.
 
 As an example of a backdoor that doesn't obviously permit an
 asymmetric-cipher construction, consider a broken cipher that
 has 128-bit symmetric keys; but one of these keys (which one
 depends on an IV in some non-obvious way that's known to the
 attacker) can be used to decrypt any message regardless of the
 key used to encrypt it.

That key would then be known as the private key. The public key
is the set of magic values used in the symmetric cipher (say in the
one way functions of the Feistel network if it were a Feistel cipher)
such that such a magic decryption key exists.

 However, it is not a valid encryption key; no matter what you
 encrypt with it you get the same ciphertext.

So? If you have an algorithm that creates such ciphers in such a way
that the magic key is hard to find, then you produce all that you want
and you have a very powerful primitive for constructing public key
systems. You don't have an obvious signature algorithm yet, but I'm
sure we can think of one with a touch of cleverness.

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

A symmetric cipher encryption function is necessarily one-to-one and
onto from the set of N bit blocks to itself. After all, if two blocks
encrypt to the same block, you can't decrypt them, and one block
can't encrypt to two blocks. If every key produces the same function
from 2^N to 2^N, it will be rapidly obvious, so keys have to produce
quite different mappings.

Your magic key must then take any block of N bits and magically
produce the corresponding plaintext when any given ciphertext
might correspond to many, many different plaintexts depending
on the key. That's clearly not something you can do.

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


Re: [Cryptography] Techniques for malevolent crypto hardware

2013-09-08 Thread Perry E. Metzger
On Sun, 8 Sep 2013 15:55:52 -0400 Thor Lancelot Simon
t...@rek.tjls.com wrote:
 On Sun, Sep 08, 2013 at 03:22:32PM -0400, Perry E. Metzger wrote:
  
  Ah, now *this* is potentially interesting. Imagine if you have a
  crypto accelerator that generates its IVs by encrypting
  information about keys in use using a key an observer might have
  or could guess from a small search space.
  
  Hadn't even occurred to me since it seems way more blatant than
  the other sort of leaks I was thinking of, but of course the mere
  fact that it is blatant doesn't mean that it would never be
  tried...
 
 Well, I guess it depends what your definition of blatant is.
 Treating the crypto hardware as a black box, it would be freaking
 hard to detect, no?

Ah, but it only needs to be found once to destroy the reputation of a
company.

Inserting bugs into chips (say, random number generators that won't
work well in the face of fabrication processes that alter analog
characteristics of circuits slightly) results in a could be an
accident sort of mistake. Altering a chip to insert an encrypted
form of a key into the initialization vectors in use cannot be
explained away that way.

You may say but how would you find that?. However, I've worked
in recent years with people who decap chips, photograph the surface
and reconstruct the circuits on a pretty routine basis -- tearing
apart secure hardware for fun and profit is their specialty. Even
when this process destructively eliminates in-RAM programming,
usually weaknesses such as power glitching attacks are discovered by
the examination of the dead system on the autopsy table and can
then be used with live hardware.

Now that it has been revealed that the NSA has either found or
arranged for bugs in several chips, I would presume that some of
these people are gearing up for major teardowns. Not all
such teardowns will happen in the open community, of course -- I'd
expect that even now there are folks in government labs around the
world readying their samples, their probe stations and their etchant
baths. Hopefully the guys in the open community will let us know
what's bad before the other folks start exploiting our hardware
silently, as I suspect the NSA is not going to send out a warning.

 I also wonder -- again, not entirely my own idea, my whiteboard
 partner can speak up for himself if he wants to -- about whether
 we're going to make ourselves better or worse off by rushing to the
 safety of PFS ciphersuites, which, with their reliance on DH, in
 the absence of good RNGs may make it *easier* for the adversary to
 recover our eventual symmetric-cipher keys, rather than harder!

I'll repeat the same observation I've made a lot: Dorothy Denning's
description of the Clipper chip key insertion ceremony described the
keys as being generated deterministically using an iterated block
cipher. I can't find the reference, but I'm pretty sure that when she
was asked why, the rationale was that an iterated block cipher can be
audited, and a hardware randomness source cannot.

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


[Cryptography] AES state of the art...

2013-09-08 Thread Perry E. Metzger
What's the current state of the art of attacks against AES? Is the
advice that AES-128 is (slightly) more secure than AES-256, at least
in theory, still current?

(I'm also curious as to whether anyone has ever proposed fixes to the
weaknesses in the key schedule...)

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


[Cryptography] Paper on Tor deanonymization: Users Get Routed

2013-09-08 Thread Perry E. Metzger
A new paper on the Tor network, entitled Users Get Routed:
Traffic Correlation on Tor by Realistic Adversaries.

  https://security.cs.georgetown.edu/~msherr/papers/users-get-routed.pdf

Quote to whet your appetite:

We present the first analysis of the popular Tor anonymity network
that indicates the security of typical users against reasonably
realistic adversaries in the Tor network or in the underlying
Internet. Our results show that Tor users are far more susceptible
to compromise than indicated by prior work.
[...]
Our analysis shows that 80% of all types of users may be de-
anonymized by a relatively moderate Tor-relay adversary within six
months. Our results also show that against a single AS adversary
roughly 100% of users in some common locations are deanonymized
within three months (95% in three months for a single IXP). Fur-
ther, we find that an adversary controlling two ASes instead of
one reduces the median time to the first client de-anonymization
by an order of magnitude: from over three months to only 1 day
for a typical web user; and from over three months to roughly
one month for a BitTorrent user. This clearly shows the dramatic
effect an adversary that controls multiple ASes can have on
security.

Disclaimer: one of the authors (Micah Sherr) is a doctoral brother.

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


Re: [Cryptography] Techniques for malevolent crypto hardware

2013-09-08 Thread Perry E. Metzger
On Sun, 08 Sep 2013 20:34:55 -0400 Kent Borg kentb...@borg.org
wrote:
 On 09/08/2013 06:16 PM, John Kelsey wrote:
  I don't think you can do anything useful in crypto without some
  good source of random bits.
 
 I don't see the big worry about how hard it is to generate random 
 numbers unless:

Lenstra, Heninger and others have both shown mass breaks of keys based
on random number generator flaws in the field. Random number
generators have been the source of a huge number of breaks over time.

Perhaps you don't see the big worry, but real world experience says
it is something everyone else should worry about anyway.

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


[Cryptography] Does NSA break in to endpoints (was Re: Bruce Schneier has gotten seriously spooked)

2013-09-07 Thread Perry E. Metzger
On Sat, 07 Sep 2013 09:33:28 +0100
Brian Gladman b...@gladman.plus.com wrote:

 On 07/09/2013 01:48, Chris Palmer wrote:
  Q: Could the NSA be intercepting downloads of open-source
  encryption software and silently replacing these with their own
  versions?
  
  Why would they perform the attack only for encryption software? They
  could compromise people's laptops by spiking any popular app.
 
 Because NSA and GCHQ are much more interested in attacking
 communictions in transit rather than attacking endpoints.

Except, one implication of recent revelations is that stealing keys
from endpoints has been a major activity of NSA in the last decade.

I'm not going to claim that altering patches and software during
download has been a major attack vector they've used for that -- I have
no evidence for the contention whatsoever and besides, endpoints seem
to be fairly vulnerable without such games -- but clearly attacking
selected endpoints is now an NSA passtime.

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


[Cryptography] ADMIN: Volume, top posting, trimming, SUBJECT LINES

2013-09-07 Thread Perry E. Metzger
1) Volume has gotten understandably high the last few days given the
current news. I'd like people to please consider if their posting
conveys interesting information before sending.

2) Please adjust the Subject lines of your messages if your posting
deviates from the original Subject. This makes it much easier for
people to determine what they want to skip.

3) Again, please don't top post. Again, please trim the message you are
replying to.

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


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

2013-09-07 Thread Perry E. Metzger
On Sat, 07 Sep 2013 13:01:53 -0700
Ray Dillinger b...@sonic.net wrote:
 I think we can no longer rule out the possibility that some attacker
 somewhere (it's easy to point a finger at the NSA but it could be
 just as likely pointed at GCHQ or the IDF or Interpol) may have
 secretly developed a functional quantum computer with a qbus wide
 enough to handle key sizes in actual use.

In the same sense that we can no longer rule out the possibility that,
given modern synthetic biology techniques, someone has already come up
with a way to create pigs with wings. I see the possibility of the
quantum computer as slightly smaller, however.

 And IIRC, pretty much every asymmetric ciphersuite (including all
 public- key crypto) is vulnerable to some transformation of Shor's
 algorithm that is in fact practical to implement on such a machine.

To my knowledge, there is no ECC analog of Shor's algorithm.

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


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

2013-09-07 Thread Perry E. Metzger
On Sat, 7 Sep 2013 13:06:14 -0700
Tony Arcieri basc...@gmail.com wrote:
 In order to beat quantum computers, we need to use public key systems
 with no (known) quantum attacks, such as lattice-based (NTRU) or
 code-based (McEliece/McBits) algorithms. ECC and RSA will no longer
 be useful.

I'm unaware of an ECC equivalent of the Shor algorithm. Could you
enlighten me on that?

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


[Cryptography] Replacing CAs (was Re: Why prefer symmetric crypto over public key crypto?)

2013-09-07 Thread Perry E. Metzger
On Sat, 7 Sep 2013 17:46:39 -0400
Derrell Piper d...@electric-loft.org wrote:

 On Sep 6, 2013, at 11:51 PM, Marcus D. Leech mle...@ripnet.com
 wrote:
 
  The other thing that I find to be a dirty little secret in PK
  systems is revocation.  OCSP makes things, in some ways, better
  than CRLs, but I still find them to be a kind of swept under the
  rug problem when people are waxing enthusiastic about PK systems.
 
 Well, there are other saddles, as it were.  SPKI/SDSI both offer a
 path forward without needing a trusted CA...

I think that in general one doesn't need CAs much. I will point out,
again, a message I sent to the list recently in which I propose that
simple demonstration of long term use and association may be
sufficient for ordinary purposes:

http://www.metzdowd.com/pipermail/cryptography/2013-August/016870.html
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


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

2013-09-07 Thread Perry E. Metzger
On Sat, 7 Sep 2013 20:43:39 -0400 I wrote:
 To my knowledge, there is no ECC analog of Shor's algorithm.

...and it appears I was completely wrong on that.

See, for example: http://arxiv.org/abs/quantph/0301141

Senility gets the best of us.

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


Re: [Cryptography] Can you backdoor a symmetric cipher

2013-09-06 Thread Perry E. Metzger
On Thu, 5 Sep 2013 21:42:29 -0700 Jon Callas j...@callas.org wrote:
 On Sep 5, 2013, at 9:33 PM, Perry E. Metzger pe...@piermont.com
 wrote:
 
  
  It is probably very difficult, possibly impossible in practice, to
  backdoor a symmetric cipher. For evidence, I direct you to this
  old paper by Blaze, Feigenbaum and Leighton:
  
  http://www.crypto.com/papers/mkcs.pdf
  
 
 There is also a theorem somewhere (I am forgetting where)

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

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

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


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

2013-09-06 Thread Perry E. Metzger
On Fri, 6 Sep 2013 01:04:31 -0400 John Kelsey crypto@gmail.com
wrote:
  I'm starting to think that I'd probably rather type in the
  results of a few dozen die rolls every month in to my critical
  servers and let AES or something similar in counter mode do the
  rest.
  
  A d20 has a bit more than 4 bits of entropy. I can get 256 bits
  with 64 die rolls, or, if I have eight dice, 16 rolls of the
  group. If I mistype when entering the info, no harm is caused.
  The generator can be easily tested for correct behavior if it is
  simply a block cipher.
 
 If you're trying to solve the problem of not trusting your entropy
 source, this is reasonable, but it doesn't exactly scale to normal
 users.

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

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

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

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

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


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

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

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

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

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


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

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

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

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


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

2013-09-06 Thread Perry E. Metzger
On Fri, 6 Sep 2013 18:18:05 +0100 Ben Laurie b...@links.org wrote:
 On 6 September 2013 18:13, Perry E. Metzger pe...@piermont.com
 wrote:
 
  Google is also now (I believe) using PFS on their connections, and
  they handle more traffic than anyone. A connection I just made to
  https://www.google.com/ came out as, TLS 1.2, RC4_128, SHA1,
  ECDHE_RSA.
 
  It would be good to see them abandon RC4 of course, and soon.
 
 
 In favour of what, exactly? We're out of good ciphersuites.

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

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


[Cryptography] 1024 bit DH still common in Tor network

2013-09-06 Thread Perry E. Metzger
Summary: blog posting claims most of the Tor network is still running
older software that uses 1024 bit Diffie-Hellman.

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

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

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-06 Thread Perry E. Metzger
On Fri, 6 Sep 2013 09:03:27 +0200 Kristian Gjøsteen
kristian.gjost...@math.ntnu.no wrote:
 As a co-author of an analysis of Dual-EC-DRBG that did not
 emphasize this problem (we only stated that Q had to be chosen at
 random, Ferguson co were right to emphasize this point), I would
 like to ask:
 
   Has anyone, anywhere ever seen someone use Dual-EC-DRBG?
 
 I mean, who on earth would be daft enough to use the slowest
 possible DRBG? If this is the best NSA can do, they are over-hyped.
 
 (If you really do want to use Dual-EC-DRBG: truncate more than 16
 bits, and don't use NSA's points, choose your own - at random.)
 

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

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


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

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

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

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

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

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

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


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

2013-09-06 Thread Perry E. Metzger
Quoting:

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

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

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


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

2013-09-06 Thread Perry E. Metzger
Quoting:

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

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

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

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

[Cryptography] Matthew Green on BULLRUN

2013-09-06 Thread Perry E. Metzger
Some interesting nuggets here, including the fact that he explicitly
calls out the existence of NSA's new HUMINT division that infiltrates
corporations for a living.

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

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


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

2013-09-06 Thread Perry E. Metzger
Sadly it seems I need to repeat this:

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

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

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

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

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

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


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

2013-09-06 Thread Perry E. Metzger
Quoting:

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

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

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

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

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

[Cryptography] ADMIN: Please, please, please don't top post.

2013-09-05 Thread Perry E. Metzger
I hate to ask this yet again, but:

Please, please, please don't top post.

Please, please, please edit down your replies.

If your mobile device, say, doesn't let you do otherwise, it can
probably wait half an hour until you get to a machine with a keyboard.

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread Perry E. Metzger
On Thu, 5 Sep 2013 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


[Cryptography] Opening Discussion: Speculation on BULLRUN

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread Perry E. Metzger
On Thu, 5 Sep 2013 16:53:15 -0400 Perry E. Metzger
pe...@piermont.com wrote:
  Classified N.S.A. memos appear to confirm that the fatal
  weakness, discovered by two Microsoft cryptographers in 2007, was
  engineered by the agency. The N.S.A. wrote the standard and
  aggressively pushed it on the international group, privately
  calling the effort “a challenge in finesse.”
  
  “Eventually, N.S.A. became the sole editor,” the memo says.
  
  Anyone recognize the standard?
 
 Please say it aloud. (I personally don't recognize the standard
 offhand, but my memory is poor that way.)

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

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


[Cryptography] The Guardian: US and UK spy agencies defeat privacy and security on the internet

2013-09-05 Thread Perry E. Metzger
Quoting:

US and British intelligence agencies have successfully cracked
much of the online encryption relied upon by hundreds of millions
of people to protect the privacy of their personal data, online
transactions and emails, according to top-secret documents
revealed by former contractor Edward Snowden.

The files show that the National Security Agency and its UK
counterpart GCHQ have broadly compromised the guarantees that
internet companies have given consumers to reassure them that
their communications, online banking and medical records would be
indecipherable to criminals or governments

http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread Perry E. Metzger
On Thu, 05 Sep 2013 13:33:48 -0700 Eric Murray er...@lne.com wrote:
 The NYT article is pretty informative:
 (http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html)
[...]
 Also interesting:
 
 Cryptographers have long suspected that the agency planted 
 vulnerabilities in a standard adopted in 2006 by the National
 Institute of Standards and Technology, the United States’
 encryption standards body, and later by the International
 Organization for Standardization, which has 163 countries as
 members.
 
 Classified N.S.A. memos appear to confirm that the fatal weakness, 
 discovered by two Microsoft cryptographers in 2007, was engineered
 by the agency. The N.S.A. wrote the standard and aggressively
 pushed it on the international group, privately calling the effort
 “a challenge in finesse.”
 
 “Eventually, N.S.A. became the sole editor,” the memo says.
 
 Anyone recognize the standard?

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

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

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

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

Here are a few guesses from me:

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

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

At the very least, anyone whining at a standards meeting from now on
that they don't want to implement a security fix because it isn't
important to the user experience or adds minuscule delays to an
initial connection or whatever should be viewed with enormous
suspicion. Whether I am correct or not, such behavior clearly serves
the interest of those who would do bad things.

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

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

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

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


[Cryptography] Bruce Schneier in The Guardian on BULLRUN etc.

2013-09-05 Thread Perry E. Metzger
Quite worth reading. There is some speculation in there about various
weaknesses that may have been added as well.

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

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


[Cryptography] NY Times: NSA Foils Much Internet Encryption

2013-09-05 Thread Perry E. Metzger
Quoting:

   The National Security Agency is winning its long-running secret
   war on encryption, using supercomputers, technical trickery,
   court orders and behind-the-scenes persuasion to undermine the
   major tools protecting the privacy of everyday communications in
   the Internet age, according to newly disclosed documents.

   The agency has circumvented or cracked much of the encryption, or
   digital scrambling, that guards global commerce and banking
   systems, protects sensitive data like trade secrets and medical
   records, and automatically secures the e-mails, Web searches,
   Internet chats and phone calls of Americans and others around the
   world, the documents show.

http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html?pagewanted=all

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread Perry E. Metzger
On Thu, 05 Sep 2013 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


[Cryptography] Is ECC suspicious?

2013-09-05 Thread Perry E. Metzger
In this posting:

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

Bruce Schneier casts some doubt on the use of ECC

   5) Try to use public-domain encryption that has to be compatible
   with other implementations. For example, it's harder for the NSA to
   backdoor TLS than BitLocker, because any vendor's TLS has to be
   compatible with every other vendor's TLS, while BitLocker only has
   to be compatible with itself, giving the NSA a lot more freedom to
   make changes. And because BitLocker is proprietary, it's far less
   likely those changes will be discovered. Prefer symmetric
   cryptography over public-key cryptography. Prefer conventional
   discrete-log-based systems over elliptic-curve systems; the latter
   have constants that the NSA influences when they can.

Now, this certainly was a problem for the random number generator
standard, but is it an actual worry in other contexts? I tend not to
believe that but I'm curious about opinions.

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


Re: [Cryptography] tamper-evident crypto? (was: BULLRUN)

2013-09-05 Thread Perry E. Metzger
On Thu, 05 Sep 2013 16:56:38 -0700 John Denker j...@av8n.com wrote:
  The generator can
  be easily tested for correct behavior if it is simply a block
  cipher.
 
 I wouldn't have said that.
 
 As Dykstra was fond of saying:
Testing can show the presence of bugs;
testing can never show the absence of bugs.

The point is that a deterministic generator operating off of a seed
can be validated -- you can assure yourself reasonably easily that
the thing is indeed AES in counter mode. A hardware generator can have
horrible flaws that are hard to detect without a lot of data from many
devices. (The recent break of the Taiwanese national ID card system
should be a lesson on that too.)

I will remind everyone that the key generation ceremony for the
Clipper devices used a deterministic generator for precisely this
reason even given that the keys were being escrowed. See Dorothy
Denning's old report on that for a reminder.

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


[Cryptography] ADMIN: less Snowden, more Crypto

2013-09-05 Thread Perry E. Metzger
On Thu, 5 Sep 2013 20:30:40 -0400 Jerry Leichter leich...@lrw.com
wrote:
 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

Admin hat on:

As interesting as the overall speculation might be in a human
interest sort of way, I'd prefer if we avoided it, unless it points
to interesting lessons for making the world more secure going
forward or to something similarly worthwhile.

Yes, this is irresistible gossip for many of us, but I don't know that
it is interesting beyond that, and our traffic levels are quite high
right now already.


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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-05 Thread Perry E. Metzger
On 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 Perry E. Metzger
On Fri, 06 Sep 2013 13:50:54 +1200 Peter Gutmann
pgut...@cs.auckland.ac.nz wrote:
 Perry E. Metzger pe...@piermont.com writes:
 Does that make them NSA plants?  There's drafts for one or
 two more fairly basic fixes to significant problems from other
 people that get stalled forever, while the draft for adding sound
 effects to the TLS key exchange gets fast-tracked.  It's just what
 standards committees do.

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

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


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

2013-09-05 Thread Perry E. Metzger
On Thu, 5 Sep 2013 23:24:54 -0400 Jerry Leichter leich...@lrw.com
wrote:
 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,

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

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

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


[Cryptography] Hashes into Ciphers (was Re: FIPS, NIST and ITAR questions)

2013-09-04 Thread Perry E. Metzger
As a pure aside...

On Tue, 3 Sep 2013 15:16:14 -0400 Faré fah...@gmail.com wrote:
 Can't you trivially transform a hash into a PRNG, a PRNG into a
 cypher, and vice versa?

Phil Karn described a construction for turning any hash function into
the core of a Feistel cipher in 1991. So far as I can tell, such
ciphers are actually quite secure, though impractically slow.

Pointers to his original sci.crypt posting would be appreciated, I
wasn't able to find it with a quick search.

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

Re: [Cryptography] IPv6 and IPSEC

2013-09-04 Thread Perry E. Metzger
On Wed, 4 Sep 2013 09:14:36 +0200 Lucky Green
shamr...@cypherpunks.to wrote:
 I *have* PTR records for my IPv6 addresses. What I don't know is
 which PTR records will make Gmail happy. SPF PTR records clearly do
 not do the trick.

I think this conversation has, at this point, gone well beyond the
scope of the list. There are a bunch of google people on the mailing
list, perhaps one or more of them might want to contact Lucky in
private and see if they can help him with his question.

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


Re: [Cryptography] Hashes into Ciphers

2013-09-04 Thread Perry E. Metzger
On Wed, 4 Sep 2013 10:37:12 -0400 Perry E. Metzger
pe...@piermont.com wrote:
 Phil Karn described a construction for turning any hash function
 into the core of a Feistel cipher in 1991. So far as I can tell,
 such ciphers are actually quite secure, though impractically slow.
 
 Pointers to his original sci.crypt posting would be appreciated, I
 wasn't able to find it with a quick search.

Answering my own question

https://groups.google.com/forum/#!original/sci.crypt/tTWR2qIII0s/iDvT3ptY5CEJ

Note that Karn's construction need not use any particular hash
function -- he's more or less simply describing how to use a hash
function of any sort as the heart of a Feistel cipher.

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


Re: [Cryptography] Thoughts about keys

2013-09-02 Thread Perry E. Metzger
On Mon, 2 Sep 2013 03:00:42 +0200 Faré fah...@gmail.com wrote:
  At intervals, the trustworthy organization (and others like it)
  can send out email messages to Alice, encrypted in said key,
  saying Hi there! Please reply with a message containing this
  magic cookie, encrypted in our key, signed in yours.
 
 The cookie better not be a a value that the organization can
 skew with its own random source, but be based on a digest of
 consensual data, such as the date (with sufficiently coarse
 resolution), the top of the consensual database (if any),
 public weather measurements from previous day, etc.

I don't understand why. The security requirement is that third
parties must *not* be able to predict the token, because then they
could sign the token without controlling the email address. The only
organization that can know the cookie is actually the organization
sending the cookie out. You appear to have inverted the security
requirement...

 Then, each user can just broadcast his signature
 of the previously unpredictable consensual data,
 and various timestamping organizations can sign messages that say
 yes, I saw that at this time,
 maybe charging some tiny usage fee in the process.

But then *anyone* could broadcast the token because anyone could have
predicted it.

It is difficult to make the interchange of the token and the reply
itself widely witnessed -- the way around that is to have many
organizations doing the interchanges so that one would have to suborn
all of them.

 After a deadline, the organization publishes
 the definitive merkle tree digest of who was seen on time,
 together with the common salt.

That is part of the envisioned model. Currently I'm looking at how to
take advantage of the work already done on Certificate Transparency.

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

Re: [Cryptography] NSA and cryptanalysis

2013-09-02 Thread Perry E. Metzger
On Mon, 2 Sep 2013 00:06:21 -0400 Jerry Leichter leich...@lrw.com
wrote:
 - To let's look at what they want for TOP SECRET.  First off, RSA -
 accepted for a transition period for SECRET, and then only with
 2048 bit moduli, which until the last year or so were almost
 unknown in commercial settings - is completely out for TOP SECRET.
 So clearly they're faith in RSA is gone.

That is a misunderstanding.

If you look at the way that the NSA specs these things, they try to
keep all portions of a system of equal security so none is the weak
point. A 2048 bit RSA key is factored vastly more easily than a 256
bit AES key is brute forced (that's just public knowledge -- try doing
the back of the envelope yourself) so that size key would be
insufficient. However, a sufficiently large RSA key to be correctly
sized for 256 bit AES is totally impractical for performance reasons,
see:

http://www.nsa.gov/business/programs/elliptic_curve.shtml

So clearly the purpose of pushing ECC for this application is that
they want the public key algorithm and its key size to have comparable
security while both performing reasonably well.

 (Same for DH and DSA.)
 It looks as if they are betting that factoring and discrete logs
 over the integers aren't as hard as people had thought.

Not at all, and the rationale is public and seen above.

I believe you're incorrectly claiming that we know much less than we
actually do here.

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


Re: [Cryptography] Thoughts about keys

2013-09-02 Thread Perry E. Metzger
On Mon, 2 Sep 2013 19:53:03 +0200 Faré fah...@gmail.com wrote:
 On Mon, Sep 2, 2013 at 7:19 PM, Perry E. Metzger
 pe...@piermont.com wrote:
  On Mon, 2 Sep 2013 03:00:42 +0200 Faré fah...@gmail.com wrote:
   At intervals, the trustworthy organization (and others like
   it) can send out email messages to Alice, encrypted in said
   key, saying Hi there! Please reply with a message containing
   this magic cookie, encrypted in our key, signed in yours.
  
  The cookie better not be a a value that the organization can
  skew with its own random source, but be based on a digest of
  consensual data, such as the date (with sufficiently coarse
  resolution), the top of the consensual database (if any),
  public weather measurements from previous day, etc.
 
  I don't understand why. The security requirement is that third
  parties must *not* be able to predict the token, because then they
  could sign the token without controlling the email address. The
  only organization that can know the cookie is actually the
  organization sending the cookie out. You appear to have inverted
  the security requirement...
 
 In my scheme, no one can predict it, everyone can postdict it,
 *after* the trusted organization published its salt, at which
 point it's too late to send it signed confirmations.
 Therefore, neither side can cheat.

I don't see what threat this averts. If the sending organization is
cheating, this does not stop them from pretending that they received
a signed cookie in a round trip. It just seems to add complexity. The
only interesting form of cheating I can think of is pretending a
round trip existed when it did not.

 In particular, the trusted organization has precious little power
 to extract information by handing users carefully crafted cookies.

I don't see how that is an issue either, unless you are referring to
chosen plaintext attacks, but the encryption format had better
already defend against those.

 For even less power, the organization can publish digests of its
 salts years in advance.

Again, I don't understand the threat being defended against. Can you
articulate exactly what was possible before that is not possible in
the scheme you propose?

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

Re: [Cryptography] NSA and cryptanalysis

2013-09-02 Thread Perry E. Metzger
On Mon, 2 Sep 2013 15:09:31 -0400 Jerry Leichter leich...@lrw.com
wrote:
 On Sep 2, 2013, at 1:25 PM, Perry E. Metzger wrote:
 
  On Mon, 2 Sep 2013 00:06:21 -0400 Jerry Leichter
  leich...@lrw.com wrote:
  - To let's look at what they want for TOP SECRET.  First off,
  RSA - accepted for a transition period for SECRET, and then only
  with 2048 bit moduli, which until the last year or so were almost
  unknown in commercial settings - is completely out for TOP
  SECRET. So clearly they're faith in RSA is gone.
  
  That is a misunderstanding.
  
  If you look at the way that the NSA specs these things, they try
  to keep all portions of a system of equal security so none is the
  weak point. A 2048 bit RSA key is factored vastly more easily
  than a 256 bit AES key is brute forced (that's just public
  knowledge -- try doing the back of the envelope yourself) so that
  size key would be insufficient. However, a sufficiently large RSA
  key to be correctly sized for 256 bit AES is totally
  impractical for performance reasons, see:
  
  http://www.nsa.gov/business/programs/elliptic_curve.shtml
 a)  The very reference you give says that to be equivalent to 128
 bits symmetric, you'd need a 3072 bit RSA key - but they require a
 2048 bit key.

Only as a legacy you can do this for a while but please switch.

 And the same reference says that to be equivalent to
 256 bits symmetric, you need a 521 bit ECC key - and yet they
 recommend 384 bits.  So, no, even by that page, they are not
 recommending equivalent key sizes - and in fact the page says
 just that.

I'd say they're judging a balance between security and performance
while attempting not to leave particularly bad holes.

 b)  Those comparisons long ago became essentially meaningless.  On
 the symmetric size, it's using brute force attack strengths.  But
 no one is going to brute force a 128-bit key with any known or
 suggested technology, and brute force attacks against 256-bit keys
 are way beyond what physics says is even remotely possible.

I believe that is indeed a factor here, and is probably part of why
the asymmetric key lengths aren't a bit longer. It is also possible
they've been selected based on knowledge that AES keys are slightly
weaker than we expect, but not radically so.

As an aside, I'm reminded of the fact that there were certificational
weaknesses in Skipjack that meant it was only more or less as
potentially secure as the number of bits available in they key
length. When this was pointed out to someone in the know, the mumble
back I remember was in other words, they did the engineering
correctly.

Anyway, as I've said, I'm paranoid, but I operate under the
assumption the counterparty is a reasonably rational actor that
understands the very limited duration of secrets.

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


Re: [Cryptography] NSA and cryptanalysis

2013-09-02 Thread Perry E. Metzger
On Mon, 2 Sep 2013 14:45:00 -0400 Phillip Hallam-Baker
hal...@gmail.com wrote:
  Do we know they produced fake windows updates without assistance
  from Microsoft?
 
 Given the reaction from Microsoft, yes.
 
 The Microsoft public affairs people have been demonstrating real
 anger at the Flame attack in many forums.

But of course, sufficiently paranoid people might contend that
perhaps the Microsoft people who complained might not have been
briefed by the ones who cooperated.

The problem with all such exercises is that they involve too many
layers of recursive paranoia, but do not pay off with useful
information that tells me how to act going forward.

In the current case, the fact that they *could* potentially suborn
process inside a vendor is an interesting thing to consider when
doing design, and whether they *have* is less interesting to me.
Clearly, as things like bad vendor drivers updates have been sent out
using stolen keys in the past, and clearly vendors might simply make
mistakes in the future.

From there, I can consider whether the someone at vendor signs bad
updates security model component is productive to defend against or
not, and how one might defend against it. (In the current case, I'd
say only typed assembly language offers an interesting defense
against bad binaries that get executed in kernel mode, regardless of
why they are bad. Using typed assembly language effectively of
course requires that the code be written in a high level language
with strong typing to be preserved in the delivered machine code in
the first place.)

I leave speculation to pundits, and prefer to write code and design
protocols.

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


Re: [Cryptography] NSA and cryptanalysis

2013-09-02 Thread Perry E. Metzger
On Mon, 2 Sep 2013 13:14:00 -0700 Christian Huitema
huit...@huitema.net wrote:
Do we know they produced fake windows updates without
assistance from Microsoft?
   
   Given the reaction from Microsoft, yes.
   
   The Microsoft public affairs people have been demonstrating real
   anger at the Flame attack in many forums.
 
  But of course, sufficiently paranoid people might contend that
  perhaps the Microsoft people who complained might not have been
  briefed by the ones who cooperated.
 
 I would be very surprised if they had gotten any assistance from
 Microsoft.

As would I. Not my wider point. My wider point is that the
speculation is not helpful, and one probably wants to think about how
to make things trustworthy even in the presence of bugs, adversaries
who look like bugs for most viewpoints, etc. Paranoid speculation is
useless, concrete discussion of threat models and how to address them
is useful. (Thus why I mentioned things like typed assembly language
as being a more productive topic than infinitely recursive paranoia.
One can speculate endlessly on who is collaborating with whom
without ever terminating, but robust threat models with technical
solutions are something you can actually do something about.)

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


Re: [Cryptography] NSA and cryptanalysis

2013-09-02 Thread Perry E. Metzger
On Mon, 2 Sep 2013 17:44:57 -0400 Jerry Leichter leich...@lrw.com
wrote:
  ...Clearly, as things like bad vendor drivers updates have been
  sent out using stolen keys in the past, and clearly vendors might
  simply make mistakes in the future
 
 Except that that's not what happened in this case.
 
 Someone took an old, valid Microsoft license - which should never

Yes, certainly, but the end effect was that an untrustworthy piece of
code was then executing on the victim's machine. That can be happen
by many means, however, both intentional and accidental -- trojan
horses, vendor mistakes, bugs, rogue employees at a vendor, a vendor's
credentials being stolen, cryptographic breaks like this, etc.

Now, I do indeed find it interesting and exotic that someone involved
knows how to create MD5 collisions by a different method than we know
of in the open literature, and that tickles my fancy as a
person who loves cryptography, and probably tells us something about
who wrote that particular exploit.

What it does not do, however, is tell me much about how to
make systems robust against the wide variety of reasons why
untrustworthy software might appear on a machine.

As a security person, it is this latter problem that is vital
to me, since doubtless that will show up again in the future. Even
ignoring malice, bugs often happen in device drivers and other code
running in security critical environments like kernels.

I will again mumble things like: typed assembly language, proof
carrying code, microkernels, hardware assists, formal verification...
in the hopes that the mumbling might set some minds thinking.

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


Re: [Cryptography] NSA and cryptanalysis

2013-09-01 Thread Perry E. Metzger
On Sat, 31 Aug 2013 17:00:01 -0400 John Kelsey crypto@gmail.com
wrote:
 If I had to bet, I'd bet on bad rngs as the most likely source of a
 breakthrough in decrypting lots of encrypted traffic from different
 sources. 

This seems by far the most probable conclusion. Note, for example,
Heninger et al's recent work on the Taiwanese national smartcards. A
discovery that some commonly used randomness sources are dramatically
less random than supposed could dramatically lower the work factor on
an otherwise brute force attack.

That said, we simply can't know, and I think excessive speculation on
the basis of no actual concrete information isn't that productive.

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


Re: [Cryptography] NSA and cryptanalysis

2013-09-01 Thread Perry E. Metzger
On Sun, 1 Sep 2013 07:11:06 -0400 Jerry Leichter leich...@lrw.com
wrote:
 Meanwhile, just what evidence do we really have that AES is
 secure?

The fact that the USG likes using it, too.

That's also evidence for eliptic curve techniques btw.

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


Re: [Cryptography] NSA and cryptanalysis

2013-09-01 Thread Perry E. Metzger
On Sun, 1 Sep 2013 16:33:56 -0400 Jerry Leichter leich...@lrw.com
wrote:
 
 On Sep 1, 2013, at 2:11 PM, Perry E. Metzger wrote:
 
  On Sun, 1 Sep 2013 07:11:06 -0400 Jerry Leichter
  leich...@lrw.com wrote:
  Meanwhile, just what evidence do we really have that AES is
  secure?
  
  The fact that the USG likes using it, too.
 We know they *say in public* that it's acceptable.  But do we know
 what they *actually use*?

We know what they spec for use by the rest of the US government in
Suite B.

http://www.nsa.gov/ia/programs/suiteb_cryptography/

  AES with 128-bit keys provides adequate protection for classified
  information up to the SECRET level. Similarly, ECDH and ECDSA using
  the 256-bit prime modulus elliptic curve as specified in FIPS PUB
  186-3 and SHA-256 provide adequate protection for classified
  information up to the SECRET level. Until the conclusion of the
  transition period defined in CNSSP-15, DH, DSA and RSA can be used
  with a 2048-bit modulus to protect classified information up to the
  SECRET level.

  AES with 256-bit keys, Elliptic Curve Public Key Cryptography using
  the 384-bit prime modulus elliptic curve as specified in FIPS PUB
  186-3 and SHA-384 are required to protect classified information at
  the TOP SECRET level. Since some products approved to protect
  classified information up to the TOP SECRET level will only contain
  algorithms with these parameters, algorithm interoperability between
  various products can only be guaranteed by having these parameters as
  options.

We clearly cannot be absolutely sure of what they actually use, but
we know what they procure commercially. If you feel this is all a big
disinformation campaign, please feel free to give evidence for that. I
certainly won't exclude the possibility, but I find it unlikely.

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


[Cryptography] Keeping backups (was Re: Separating concerns

2013-08-29 Thread Perry E. Metzger
On Wed, 28 Aug 2013 20:04:34 +0200 Faré fah...@gmail.com wrote:
 One thing that irks me, though, is the problem of the robust, secure
 terminal: if everything is encrypted, how does one survive the
 loss/theft/destruction of a computer or harddrive?

So, as has been discussed, I envision people having small cheap
machines at home that act as their cloud, and the system prompting
them to pick a friend to share encrypted backups with.

Inevitably this means that said backups are going to either be
protected by a fairly weak password or that the user is going to have
to print the key out and put it in their desk drawer and risk having
it lost or stolen or destroyed in a fire.

I think I can live with either problem. Right now, most people
have very little protection at all. I think making the perfect the
enemy of the good is a mistake. If doing bad things to me requires
breaking in to my individual home, that's fine. If it is merely much
less likely that I lose my data rather than certain that I have no
backup at all, that's fine.

BTW, automation *does* do a good job of making such things invisible.
I haven't lost any real data since I started using Time Machine from
Apple, and I have non-technical friends who use it and are totally
happy with the results. I wish there was an automated thing in Time
Machine to let me trade backups with an offsite friend as well.

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

Re: [Cryptography] Why human-readable IDs (was Re: Email and IM are ideal candidates for mix networks)

2013-08-29 Thread Perry E. Metzger
On Thu, 29 Aug 2013 01:18:59 +1000 (EST) Dave Horsfall
d...@horsfall.org wrote:
 On Wed, 28 Aug 2013, Perry E. Metzger wrote:
 
  Anyway, I've already started implementing my proposed solution to
  that part of the problem. There is still a need for a distributed
  database to handle the lookup load, though, and one that is not
  the DNS.
 
 (Delurking)
 
 This suggests the use of LDAP.

I can think of no circumstances where I would voluntarily use LDAP as
the solution to any problem of any sort.

In any case, you will note that LDAP does not actually solve the
problem statement as I gave it: that is to say, users must be able to
join the system without the permission or assistance of systems
administrators.

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


Re: [Cryptography] Why not the DNS? (was Re: Implementations, attacks on DHTs, Mix Nets?)

2013-08-29 Thread Perry E. Metzger
On Wed, 28 Aug 2013 10:43:24 -0400 Jerry Leichter leich...@lrw.com
wrote:
 On Aug 28, 2013, at 8:34 AM, Perry E. Metzger wrote:
 
  On Tue, 27 Aug 2013 23:39:51 -0400 Jerry Leichter
  leich...@lrw.com wrote:
  It's not as if this isn't a design we have that we know works:
  DNS.
 Read what I said:  There's a *design* that works.
 
 I never suggested *using DNS* - either its current physical
 instantiation, or even necessarily the raw code.  In fact, I
 pointed out some of the very problems you mention.
 
 What defines the DNS model - and is in contrast to the DHT model -
 is:
 
 - Two basic classes of participants, those that track potentially
 large amounts of data and respond to queries and those that simply
 cache for local use;
 - Caching of responses for authoritative-holder-limited amounts of
 time to avoid re-querying;
 - A hierarchical namespace and a corresponding hierarchy of caches.
 
 DNS and DNSSEC as implemented assume a single hierarchy, and they
 map the hierarchy to authority.  These features are undesirable and
 should be avoided.

I'm unsure how to use a DNS-like model when there is no real linkage
between hierarchy in the names used and the storage location of
particular mappings. In particular, if I have names like
f...@example.com, and I want just anyone to be able to enroll at any
time without administrator input, and I don't want state
authorities to be able to shut down or alter the contents of the
system, I don't see how to accomplish all my goals with something
DNS-like.

That said, if you have a concrete proposal, I would of course find it
interesting to hear about.

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


[Cryptography] The Case for Formal Verification

2013-08-29 Thread Perry E. Metzger
 to proving the right thousand lines of code here and
there without much fuss, and that might make an incredible difference
in systems security if people actually take it seriously.


So, if you're interested, how do you get started doing such things?

At the moment, the best system for doing this sort of work is Coq:
http://coq.inria.fr/

Coq is sort of a programming language (although it is not quite Turing
equivalent -- all programs must be guaranteed to terminate for
technical reasons), sort of a form of constructivist logic (i.e. all
existence proofs construct examples, no law of the excluded middle).

It uses a neat trick called the Curry-Howard isomorphism that may take
some getting used to for people not exposed to modern type theory.  In
it, types and logical propositions are the same thing, and programs
and proofs are the same thing. You can write a function that adds two
numbers, or a function that proves that there are an infinite number
of primes. The type of the former is clearly an integer, but the type
of the latter is the theorem itself.

A proof that proposition A implies proposition B is function of type
A - B -- any function that takes a proof of A and yields a proof of B
is after all a proof that if A is true then B is true. (This is why
all functions in Coq itself must terminate -- otherwise all types
would be inhabited so all theorems would be true. That in no way
restricts one's ability to build verified non-terminating programs
using the system, you just have to build them by reasoning about
programs that Coq itself can't execute.)

Proofs in Coq are generally not written by hand, though. Instead one
uses a sublanguage called the tactic language in which one invokes
help from Coq to interactively assemble a proof, which makes doing the
proof far easier. For many theorems, you can almost completely
automate the proof, while for others, you need to help Coq along
more. (Some of the tactics are quite amazing, Omega for example will
prove any assertion about numbers that does not involve multiplication
by a variable, aka Presburger arithmetic.)

Often, one builds software using Coq by constructing a sort of
formally verified assertion about what the program would do, and then
using a built in Coq facility to mechanically extract that into a
working verified program written in OCaml, Haskell or Scheme. Nothing
in theory prevents you from doing things many in other ways, though --
the system is quite general.

Coq is, sadly, needlessly hard for the beginner. It has poor
documentation, bad error messages and bad error behavior. These are
not inherent problems, they're problems just with this instance of
things -- people could build better if there was enough interest, and
I hope that as these technologies become more popular people will
build far better versions of the tools.

However, bad documentation or no, at the moment, this is the right
place to go I think. It is the system Quark and CompCert were built
in, and not by accident. It is not for the faint of heart -- the
learning curve is very steep. Still, it is quite doable.

The right places to start with Coq are probably Benjamin Pierce's
online Software Foundations textbook:
http://www.cis.upenn.edu/~bcpierce/sf/
and, when one is done with that, possibly Adam Chlipala's online book
Certified Programming with Dependent Types
http://adam.chlipala.net/cpdt/

(There's also a manual for the system itself, as well as this book on
Coq: https://www.springer.com/computer/swe/book/978-3-540-20854-9 )

I'm happy to give help to anyone trying to learn how to do this sort
of thing -- we need more people in the world experimenting with
verification if we're going to get truly trustworthy software going
forward.

Let me assert that we *do* need truly trustworthy software, too. We've
been very, very good for years now at finding hole after hole in
running code and making the systems we depend on every day into a
minefield that we dare not take an unconsidered step in. Wouldn't it
be nice to make some progress in the other direction?


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


[Cryptography] Why not the DNS? (was Re: Implementations, attacks on DHTs, Mix Nets?)

2013-08-28 Thread Perry E. Metzger
On Tue, 27 Aug 2013 23:39:51 -0400 Jerry Leichter leich...@lrw.com
wrote:
 It's not as if this isn't a design we have that we know works:
 DNS.

As I said elsewhere: as a practical matter, almost no one using email
is a DNS administrator. This therefore cannot possibly deploy in
finite time for the average user. If your mailbox is in a domain name
controlled by someone else, you may wait effectively forever for
permission. Indeed, DNSSEC itself has waited forever as a result of
that.

Furthermore, this is unacceptable because the trust model is
unacceptable. If you are a user of gmail, for example, it implies
that Google is in the trust loop for telling the world security
critical information, like, for example, your key. Sovereign
threats can order Google to insert different keys at will.

As I've said elsewhere: the DNS is a very architecturally tempting
idea for all of this. I fully understand why people would want to do
it that way. It is not, however, practical if one wants to deploy in
months and not decades, and it makes trust entirely hierarchical.

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


[Cryptography] human readable IDs, revokable keys (Re: Email and IM are ideal candidates for mix networks)

2013-08-28 Thread Perry E. Metzger
First of all, I think systems that make people associate arbitrary
long strings with someone's email address aren't really acceptable.
I'll repeat that my model is give someone your email address on a
napkin in a bar. I do things like this often enough right now.

On Wed, 28 Aug 2013 06:41:27 -0400 Jerry Leichter leich...@lrw.com
wrote:
 On the underlying matter of changing my public key:  *Why* would I
 have to change it?

Because people make mistakes and reveal security critical information
to the world at intervals. Because computers are sometimes
compromised. A system that does not permit you to recover from rare
events is not going to deploy very well.

I think that to begin with, though, a system that requires people to
somehow associate arbitrary strings with their friends won't work
either.

Anyway, I proposed a system to handle id to key mappings with
reasonable trust in the first of my three messages on my proposed new
model -- it also happens to handle revocation reasonably well
(though imperfectly).

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


  1   2   3   4   5   6   7   >