Re: [Cryptography] PGP Key Signing parties

2013-10-10 Thread Paul Hoffman
On Oct 10, 2013, at 2:31 PM, John Gilmore g...@toad.com wrote:

 Does PGP have any particular support for key signing parties built in or is
 this just something that has grown up as a practice of use?
 
 It's just a practice.  I agree that building a small amount of automation
 for key signing parties would improve the web of trust.
 
 I have started on a prototype that would automate small key signing
 parties (as small as 2 people, as large as a few dozen) where everyone
 present has a computer or phone that is on the same wired or wireless
 LAN.

Phil Zimmerman and Jon Callas had started to work on that around 1998, they 
might still have some of that design around.

--Paul Hoffman

___
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 Paul Hoffman
Also see RFC 3766 from almost a decade ago; it has stood up fairly well.

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


Re: [Cryptography] Google's Public Key Size (was Re: NSA and cryptanalysis)

2013-09-05 Thread Paul Hoffman
On Sep 4, 2013, at 2:15 PM, Andy Steingruebl stein...@gmail.com wrote:

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

For some value of forbidden. :-)

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


Folly of looking at CA cert lifetimes

2010-09-14 Thread Paul Hoffman
At 10:57 AM -0400 9/14/10, Perry E. Metzger did not write, but passed on for 
someone else:
This suggests to me that even if NIST is correct that 2048 bit RSA
keys are the reasonable the minimum for new deployments after 2010,
much shorter keys are appropriate for most server certificates that
these CAs will sign.  The CA keys have lifetimes of 10 years or more;
the server keys a a quarter to a fifth of that.

No, no, a hundred times no. (Well, about 250 times, or however many CAs are in 
the current OS trust anchor piles.) The lifetime of a CA key is exactly as 
long as the OS or browser vendor keeps that key, usually in cert form, in its 
trust anchor pile. You should not extrapolate *anything* from the contents of 
the CA cert except the key itself and the proclaimed name associated with it.

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Folly of looking at CA cert lifetimes

2010-09-14 Thread Paul Hoffman
At 5:33 PM -0400 9/14/10, Thor Lancelot Simon wrote:
On Tue, Sep 14, 2010 at 08:14:59AM -0700, Paul Hoffman wrote:
 At 10:57 AM -0400 9/14/10, Perry E. Metzger did not write, but passed on for 
 someone else:
 This suggests to me that even if NIST is correct that 2048 bit RSA
 keys are the reasonable the minimum for new deployments after 2010,
 much shorter keys are appropriate for most server certificates that
 these CAs will sign.  The CA keys have lifetimes of 10 years or more;
 the server keys a a quarter to a fifth of that.

 No, no, a hundred times no. (Well, about 250 times, or however many
 CAs are in the current OS trust anchor piles.) The lifetime of a CA
 key is exactly as long as the OS or browser vendor keeps that key,
 usually in cert form, in its trust anchor pile. You should not
 extrapolate *anything* from the contents of the CA cert except the key
 itself and the proclaimed name associated with it.

I don't understand.  The original text seems to be talking about *server*
certificate lifetimes, and how much shorter they are than CA cert
lifetimes.  What does that have to do with a thousand times no about
some proposition to do with CA cert lifetimes?

In other words, if CA key lifetimes are longer than indicated by their
X.509 properties, it seems to me that just makes the quoted text about
the relationship between server and CA key lifetimes even more true.

Ah, I see what you are saying, and what Perry's anonymous forwarder meant. That 
is, if the CA keys have lifetimes of 10 years or more means because that's 
how long OSs and browsers leave them in the trust anchor pile, then it has 
nothing to do with the built-in notAfter dates in the server certificates.

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: 2048-bit RSA keys

2010-08-16 Thread Paul Hoffman
At 11:35 AM +1000 8/16/10, Arash Partow wrote:
Paul Hoffman wrote:
You are under the wrong impression, unless you are reading vastly different 
crypto literature than the rest of us are. RSA-1024 *might* be possible to 
break in public at some point in the next decade, and RSA-2048 is a few 
orders of magnitude harder than that.


Just out of curiosity, assuming the optimal use of today's best of breed 
factoring algorithms - will there be enough energy in our solar system to 
factorize a 2048-bit RSA integer?

We have no idea. The methods used to factor number continue to slowly get 
better, and it has been quite a while since there was a single large 
improvement. That could mean that there are no more improvements to be made, or 
that some smart cryptographer who isn't focused on the SHA-3 competition is 
about to make another big improvement, or something in between.

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


2048-bit RSA keys

2010-08-15 Thread Paul Hoffman
At 9:34 AM -0700 8/15/10, Ray Dillinger wrote:
I'm under the impression that 2048 keys are now insecure mostly due
to advances in factoring algorithms that make the attack and the
encryption effort closer to, but by no means identical to, scaling
with the same function of key length. 

You are under the wrong impression, unless you are reading vastly different 
crypto literature than the rest of us are. RSA-1024 *might* be possible to 
break in public at some point in the next decade, and RSA-2048 is a few orders 
of magnitude harder than that.

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: /dev/random and virtual systems

2010-08-03 Thread Paul Hoffman
At 10:38 PM +0300 8/2/10, Yaron Sheffer wrote:
the interesting thread on seeding and reseeding /dev/random did not mention 
that many of the most problematic systems in this respect are virtual 
machines. Such machines (when used for cloud computing) are not only 
servers, so have few sources of true and hard-to-observe entropy. Often the 
are cloned from snapshots of a single virtual machine, i.e. many VMs start 
life with one common RNG state, that doesn't even know that it's a clone.

In addition to the mitigations that were discussed on the list, such machines 
could benefit from seeding /dev/random (or periodically reseeding it) from the 
*host machine's* RNG. This is one thing that's guaranteed to be different 
between VM instances. So my question to the list: is this useful? Is this 
doable with popular systems (e.g. Linux running on VMWare or VirtualBox)? Is 
this actually being done?

It is certainly doable: put a file on the host whose contents are random and 
change every second. On the VM, read that file on wakeup or boot and mix it 
into /dev/random. This guarantees a different value for each wakeup/boot, but 
not that every cloned machine that starts will have a unique state (because 
they might start within the same refresh. If you need that, you probably want 
to automatically mix a microsecond-accurate time at the same time.

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Root Zone DNSSEC Deployment Technical Status Update

2010-07-17 Thread Paul Hoffman
At 9:52 AM -0400 7/17/10, Thierry Moreau wrote:
Incidentally, you say you [the design team] had good *documented* reasons for 
implementing DURZ *as*you*did*. Did you document why any of 
unknown/proprietary/foreign signature algorithm code(s) were not possible 
(this was an alternative)? This was my outstanding question.

Thierry, can you say how using one of those alternatives would look different 
than the DURZ that they used? Should they all be marked as unverfied in a 
compliant DNSSEC resolver? If not, I am interested in how you think the 
differences would have manifest in the real world.

Yes, they are - see http://data.iana.org/ksk-ceremony/. If there is anything 
missing, please let me know.


Thanks, great. The two key ceremony scripts are what I wanted to look at.

FWIW, this was *widely* publicized, particularly on mailing lists that Thierry 
is on. It even made the IT trade press.

As a side note, I find the IT press part disturbing, given that the key signing 
ceremonies were just as much security theater as many of the things we like to 
chide on this list.

I don't have a question. I will trust the DNSSEC root signatures. However, it 
seems obvious that formal dual-control rules should have been designed, e.g. a 
Trusted Courier Officer role with a 3 out of 4 (or 5) separation of duty. 
Without this, the key material has been protected only by the tamper-evident 
protection in transit from the ECF to the WCF. This role would have been 
limited in time.

insert chide about your criticism of the exact shade of red used on the 
curtains in the theater

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Quantum Key Distribution: the bad idea that won't die...

2010-04-20 Thread Paul Hoffman
At 11:31 AM -0400 4/20/10, Perry E. Metzger wrote:
I wonder why it is that, in spite of almost universal disinterest in the
security community, quantum key distribution continues to be a subject
of active technological development.

You hit it: almost. As long as a few researchers are interested, and there is 
money to be thrown down the drain^w^w^wat them, there will be active 
development.

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: AES-CBC + Elephant diffuser

2009-11-01 Thread Paul Hoffman
At 2:24 PM +0100 10/29/09, Eugen Leitl wrote:
We discuss why no existing cipher satisfies the requirements of this
application. Uh-oh.

Yeah, we all know what a light-weight and careless person Neils Ferguson is. 
Who would listen to him?

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Possibly questionable security decisions in DNS root management

2009-10-14 Thread Paul Hoffman
At 7:54 PM -0400 10/14/09, Perry E. Metzger wrote:
There are enough people here with the right expertise. I'd be interested
in hearing what people think could be done with a fully custom hardware
design and a budget in the hundreds of millions of dollars or more.

What part of owning a temporary private key for the root zone would be worth 
even 10% of that much? There are attacks, and there are motivations. Until we 
know the latter, we cannot put a price on the former.

Related question: if all the root keys were 2048 bits, who do you think would 
change the way they rely on DNSSEC?

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: SHA-1 and Git

2009-08-25 Thread Paul Hoffman
At 9:39 AM -0400 8/25/09, Perry E. Metzger wrote:
Ben Laurie b...@links.org writes:
  Perry E. Metzger wrote:
 Yet another reason why you always should make the crypto algorithms you
 use pluggable in any system -- you *will* have to replace them some day.

 In order to roll out a new crypto algorithm, you have to roll out new
 software. So, why is anything needed for pluggability beyond versioning?

For one example, it is not theoretical that some people will often want
to use different algorithms than others and will need negotiation. Some
things like SSH have approximately done this right. Others have done
this quite wrong.

When we were planning out IPSec, a key management protocol, SKIP, was
proposed that had no opportunity for negotiating algorithms at all --
they were burned into the metal. As it happens, by now we would have had
to completely scrap it.

Of course you can go too far in the other direction. IPSec is a total
mess because there are far too many choices -- the standard key
management protocols are so jelly-like as to be incomprehensible and
unconfigurable.

Perry is completely correct on the two previous paragraphs. Hard-coded 
algorithms, particularly asymmetric encryption/signing and hash algorithms, 
will lead to later scrapping and a transition for the entire protocol. But it 
is quite easy to build a protocol with too many knobs, and IPsec is living 
proof of that. TLS's fixed, registered ciphersuites are far from perfect, but 
in retropsect, they seem a lot better from an operations / deployment 
standpoint than IPsec.

  It seems to me protocol designers get all excited about this because
  they want to design the protocol once and be done with it. But software
  authors are generally content to worry about the new algorithm when they
  need to switch to it - and since they're going to have to update their
  software anyway and get everyone to install the new version, why should
  they worry any sooner?

You speak of beyond versioning as though introducing versioning or
algorithm negotiation were a trivial thing, but I don't think you can
generally tack such things on after the fact. You have to think about
them carefully from the start.

A different answer to Ben would be because not planning sooner causes your 
software users more grief. If you build in both algorithm agility and a few 
probably-good algorithms, the operational changes needed when one algorithm 
fails is low. Later software updates that contain other changes can also 
include new algorithms that are suspected to be good even if all of the 
original ones fail.

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Certainty

2009-08-23 Thread Paul Hoffman
At 7:10 PM -0700 8/19/09, james hughes wrote:
On Aug 19, 2009, at 3:28 PM, Paul Hoffman wrote:
I understand that creaking is not a technical cryptography term, but 
certainly is. When do we become certain that devastating attacks on one 
feature of hash functions (collision resistance) have any effect at all on 
even weak attacks on a different feature (either first or second preimages)?

This is a serious question. Has anyone seen any research that took some of 
the excellent research on collision resistance and used it directly for 
preimage attacks, even with greatly reduced rounds?

This is being done. What Perry said.


At 9:02 PM -0700 8/19/09, Greg Rose wrote:
Not directly, as far as I know. But some research and success on preimages, 
yes.

Getting a straight answer on whether or not the recent preimage work is 
actually related to the earlier collision work would be useful.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Certainty

2009-08-19 Thread Paul Hoffman
At 5:28 PM -0400 8/19/09, Perry E. Metzger wrote:
I believe attacks on Git's use of SHA-1 would require second pre-image
attacks, and I don't think anyone has demonstrated such a thing for
SHA-1 at this point. None the less, I agree that it would be better if
Git eventually used better hash functions. Attacks only get better with
time, and SHA-1 is certainly creaking.

I understand that creaking is not a technical cryptography term, but 
certainly is. When do we become certain that devastating attacks on one 
feature of hash functions (collision resistance) have any effect at all on even 
weak attacks on a different feature (either first or second preimages)?

This is a serious question. Has anyone seen any research that took some of the 
excellent research on collision resistance and used it directly for preimage 
attacks, even with greatly reduced rounds?

The longer that MD5 goes without any hint of preimage attacks, the less 
certain I am that collision attacks are even related to preimage attacks.

Of course, I still believe in hash algorithm agility: regardless of how 
preimage attacks will be found, we need to be able to deal with them 
immediately.

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Crypto '09 rump session summary?

2009-08-19 Thread Paul Hoffman
At 2:46 PM -0700 8/19/09, Greg Rose wrote:
...some summaries of some of the presentations...

More like this, please! The rump sessions have a lot of value (beyond the 
often-strained attempts at humor).

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: 112-bit prime ECDLP solved

2009-07-20 Thread Paul Hoffman
At 7:54 AM -0600 7/18/09, Zooko Wilcox-O'Hearn wrote:
This involves deciding whether a 192-bit elliptic curve public key is strong 
enough...

Why not just go with 256-bit EC (128-bit symmetric strength)? Is the 8 bytes 
per signature the issue, or the extra compute time?

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


RE: HSM outage causes root CA key loss

2009-07-14 Thread Paul Hoffman
At 11:09 PM +0200 7/14/09, Weger, B.M.M. de wrote:
Any other problems? Maybe something with key rollover or
interoperability?

Bingo. Key rollover has been thinly tested in relying parties.

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: MD6 withdrawn from SHA-3 competition

2009-07-06 Thread Paul Hoffman
At 10:39 AM -0700 7/4/09, Hal Finney wrote:
But how many other hash function candidates would also be excluded if
such a stringent criterion were applied? Or turning it around, if NIST
demanded a proof of immunity to differential attacks as Rivest proposed,
how many candidates have offered such a proof, in variants fast enough
to beat SHA-2?

The more important question, and one that I hope gets dealt with, is what is a 
sufficient proof. We know what proofs are, but we don't have a precise 
definition. We know what a proof should look like, sort of. Ron and his crew 
have their own definition, and they can't make MD6 work within that definition. 
But that doesn't mean that NIST wouldn't have accepted the fast-enough MD6 with 
a proof from someone else.

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: MD6 withdrawn from SHA-3 competition

2009-07-05 Thread Paul Hoffman
At 11:49 PM -0400 7/3/09, Steven M. Bellovin wrote:
Here's the essential paragraph:

   Thus, while MD6 appears to be a robust and secure cryptographic
   hash algorithm, and has much merit for multi-core processors,
   our inability to provide a proof of security for a
   reduced-round (and possibly tweaked) version of MD6 against
   differential attacks suggests that MD6 is not ready for
   consideration for the next SHA-3 round.

At 10:12 AM + 7/4/09, Brandon Enright wrote:
It wasn't entirely clear to me if it really was withdrawn.  Ron Rivest
posted on behalf of the MD6 team some thoughts on MD6 performance and
specifically suggested/requested that NIST ask for submitted algorithms
to be provably resistant to differential attacks.

I agree more with Brandon than with Steve, but who knows. I read Ron's message 
as a challenge to NIST about whether or not NIST would really rely on the 
proofs. It was clear they didn't want to withdraw MD6, but that they felt like 
they had to because of the speed requirement.




--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Factoring attack against RSA based on Pollard's Rho

2009-06-07 Thread Paul Hoffman
At 8:07 PM -0700 6/5/09, Greg Perry wrote:
Greetings list members,

I have published a unique factoring method related to Pollard's Rho that
is published here:

http://blog.liveammo.com/2009/06/factoring-fun/

Any feedback would be appreciated.

Is there any practical value to this work? That's a serious question. The main 
statement about the value is This is a factoring attack against RSA with an up 
to 80% reduction in the search candidates required for a conventional brute 
force key attack. Does that mean that it reduces the search space for a 
1024-bit RSA key to, at best 205 bits (0.2 * 1024) of brute force? That is a 
silly reduction; reducing it to anything less than the estimate for NFS (about 
80 bits) is not useful. Or, can this attack be combined with NFS? Or...?

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


End-of-chapter questions for Practical Cryptography?

2009-05-22 Thread Paul Hoffman
Greetings again. I'm helping someone new to the field learn cryptography. He's 
a book-learner, and is starting with Ferguson  Schneier Practical 
Cryptography. I would love to give him some things to think about after each 
chapter to make sure he's thinking about the big picture.

Has anyone on this list used the book to teach a class? If so, did you create a 
list of discussion questions? Or, do people know profs who have used the book 
to teach? Any pointers are appreciated.

--Paul Hoffman

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: 80-bit security? (Was: Re: SHA-1 collisions now at 2^{52}?)

2009-05-08 Thread Paul Hoffman
At 8:54 PM -0400 5/6/09, Steven M. Bellovin wrote:
On Thu, 30 Apr 2009 17:44:53 -0700
Jon Callas j...@callas.org wrote:

 The accepted wisdom
 on 80-bit security (which includes SHA-1, 1024-bit RSA and DSA keys,
 and other things) is that it is to be retired by the end of 2010.

That's an interesting statement from a historical perspective -- is it
true? 

That's an oddly-worded question.

It is true that NIST has specified that algorithms with 80 bits of effective 
strength should stop being used in US government systems after the end of 2010.

It is not true that the accepted wisdom is 80-bit crypto is to be retired by 
the end of 2010.

It is true that some uses of SHA-1 have 80 (now many fewer) bits of effective 
strength.

It is not true that SHA-1 gives 80-bit security; many uses of a hash rely on 
the preimage resistance, not the collision resistance.

It may be true that 1024-bit RSA and DSA gives 80 bits of effective strength, 
and it is true that this is the accepted wisdom. This is based on some wild 
hand-waving and scaling assumptions with very few data points, and particularly 
few in the past five years since that number became oft-repeated accepted 
wisdom.

And what does that say about our ability to predict the future,
and hence to make reasonable decisions on key length?

Bupkis. The best asymmetric attack published so far is about 700 bits. No one 
has produced a SHA-1 collision at 62 bits of effort (the previous estimated 
work). Our ability to extrapolate work effort to 80 bits is questionable indeed.

See, for example, the 1996 report on key lengths, by Blaze, Diffie,
Rivest, Schneier, Shimomura, Thompson, and Wiener, available at
http://www.schneier.com/paper-keylength.html -- was it right?

How could we tell? The whole point of the paper was estimating the strength 
needed to keep a secret *for a long time*. We are only 13 years into the 20 
years that they used as a basis for the estimate of 90 bits.

In 1993, Brickell, Denning, Kent, Maher, and Tuchman's interim report
on Skipjack (I don't believe there was ever a final report) stated that
Skipjack (an 80-bit cipher) was likely to be secure for 30-40 years.
Was it right?

Asking that question six years into the 30 years (if those were the numbers 
they used) is begging to make approximations on insufficient data.

The problem with SHA-1 is not its 80-bit security, but rather that it's
not that strong.

That's one problem. Another is that because it can also be used in environments 
where 160ish bits of security are needed and it's still believed to be fine 
there, people on this list and in the press are sloppy when they speak about 
its use. Another is that people on this list and in the press are sloppy about 
security decisions that involve periods of time longer than about a year.

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Has any public CA ever had their certificate revoked?

2009-05-08 Thread Paul Hoffman
At 6:02 PM +0200 5/8/09, R. Hirschfeld wrote:
  Date: Tue, 5 May 2009 10:17:00 -0700
 From: Paul Hoffman paul.hoff...@vpnc.org

  the CA fixed the problem and researched all related problems that it
 could find.

From what I've read of the incident (I think it's the one referred
to), Comodo revoked the bogus mozilla.com cert and got their reseller
Certstar (who issued it) to start performing validation. 

Correct.

Security
common sense might suggest that they validate all certs previously
issued by Certstar and check the validation procedures of their other
resellers.  Do you know whether they did so? 

Comodo publicly said they did. That's why I said researched all related 
problems that it could find.

The former seems a major
undertaking and commercially delicate.

And yet they appear to have done it.

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Has any public CA ever had their certificate revoked?

2009-05-06 Thread Paul Hoffman
At 1:02 AM +1200 5/7/09, Peter Gutmann wrote:
Paul Hoffman paul.hoff...@vpnc.org writes:

Peter, you really need more detents on the knob for your hyperbole setting.
nothing happened is flat-out wrong: the CA fixed the problem and researched
all related problems that it could find. Perhaps you meant the CA was not
punished: that would be correct in this case.

What I meant was that there were no repercussions due to the CA acting
negligently. 

We agree fully, then.

This is nothing happened as far as motivating CAs to exercise
diligence is concerned, you can be as negligent as you like but as long as you
look suitably embarassed afterwards there are no repercussions (that is,
there's no evidence that there was any exodus of customers from the CA, or any
other CA that's done similar things in the past).

This assertion is probably, but unprovably, wrong. I suspect the CA now has 
better mechanisms in place to check for the problem in the future, and I 
suspect that a few other CAs seeing the kerfuffle probably added their own 
automated checks. Note that these are checks that should have been in place 
before the error was found.

Imagine if a surgeon used rusty scalpels and randomly killed patients, or a
bank handed out money to anyone walking in the door and claiming to have an
account there, or a restaurant served spoiled food, or ... .  The
repercussions in all of these cases would be quite severe.  However when
several CAs exhibited the same level of carelessness, they looked a bit
embarassed and then went back to business as usual. 

...because not only did no one die, but also the CAs were able to fix the 
problem.

The CA-as-a-certificate-
vending-machine problem (or rogue CA if you want to call it that) had been
known for years (Verisign's Microsoft certificates of 2001 were the first
case that got widespread publicity) but since there are no repercussions for
CAs doing this there's no incentive for anything to change.

s/no/small/


This leads to the question: if a CA in a trust anchor pile does something
wrong (terribly wrong, in this case) and fixes it, should they be punished?

If a CA in a trust anchor pile does something terribly wrong and there are no
repercussions, why would any CA care about doing things right? 

Slight worry about making a more serious mistake than happened here.

All that does
is drive up costs.  The perverse incentive that this creates is for CAs to
ship as many certificates as possible while applying as little effort as
possible.  And thus we have the current state of commercial PKI.

Fully agree.

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Has any public CA ever had their certificate revoked?

2009-05-05 Thread Paul Hoffman
At 4:11 PM +1200 5/5/09, Peter Gutmann wrote:
Thierry Moreau thierry.mor...@connotech.com writes:

Now that the main question is answered, there are sub-questions to be asked:

1. Has any public CA ever encountered a situation where a revocation would
have been necessary?

Yes, several times, see e.g. the recent mozilla.org fiasco, as a result of
which nothing happened because it would have been politically inexpedient to
revoke the CA's cert.

Peter, you really need more detents on the knob for your hyperbole setting. 
nothing happened is flat-out wrong: the CA fixed the problem and researched 
all related problems that it could find. Perhaps you meant the CA was not 
punished: that would be correct in this case.

This leads to the question: if a CA in a trust anchor pile does something wrong 
(terribly wrong, in this case) and fixes it, should they be punished? If you 
say yes, you should be ready to answer who will benefit from the punishment 
and in what way should the CA be punished. (You don't have to answer these, 
of course: you can just mete out punishment because it makes you feel good and 
powerful. There is lots of history of that.)

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Has any public CA ever had their certificate revoked?

2009-05-05 Thread Paul Hoffman
At 6:44 PM -0400 5/5/09, Jerry Leichter wrote:
On May 5, 2009, at 1:17 PM, Paul Hoffman wrote:
...This leads to the question: if a CA in a trust anchor pile does something 
wrong (terribly wrong, in this case) and fixes it, should they be punished? 
If you say yes, you should be ready to answer who will benefit from the 
punishment and in what way should the CA be punished
The same question can be asked about *any* instance of criminal behavior, or 
of any other kind of behavior that is considered bad enough to be worthy of 
punishment.

Tautologically so.

As for what your punishment as a bad CA should be:  Realistically, in any 
industry based on trust, the major component of punishment should be loss of 
trust - which results in people refusing to do business with you any more, 
which will usually put you out of business. 

Even with this definition, there was no significant punishment in this case. 
I'm not saying there should be, particularly because the CA cleaned things up 
fairly rapidly, but only a few people probably have reduced their trust of the 
CA in question.

In egregious cases, we send people to jail (where they can spend time with 
Bernie Madoff).  We also have mechanisms that aren't punishments but deal with 
the equities of the situation:  They try to right the wrongs.  So if I can 
show that your malfeasance as a CA led to my losing money, you have to 
compensate me.

That has never been shown in a case of CAs not following their stated 
procedures.

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Obama's secure PDA

2009-01-26 Thread Paul Hoffman
At 2:49 AM -0500 1/26/09, Ivan Krstiç wrote:
There are still conflicting reports about whether the hardware is an altered 
RIM BlackBerry or a different device, though the most likely contender for the 
latter option appears to be the General Dynamics Sectéra Edge, which features 
a trusted [secondary] display and two buttons used to switch between 
classified and unclassified operation.

Government Computer News says it is definitely not a BlackBerry. However, GCN's 
reporters aren't always as good as they should be (or even as good as the 
regular IT press) on getting their facts straight on security issues.

http://gcn.com/articles/2009/01/23/obama-gets-super-secure-smartphone.aspx

I too would like to hear more information on this, particularly the crypto that 
is known to be used on the Edge.

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-20 Thread Paul Hoffman
At 1:38 PM + 1/19/09, Darren J Moffat wrote:
Can you state the assumptions for why you think that moving to SHA384 would be 
safe if SHA256 was considered vulnerable in some way please.

Sure. I need 128 bits of pre-image protection for, say, a digital signature. 
SHA2/256 is giving me that. Then, due to some weakness, it is only giving me 
112 bits of protection. The weakness is understood in the crypto community, and 
it's a straight-line loss of bits of protection.

SHA2/384 would then give me 168 bits of protection, which is more than the 128 
what I need.

Even if you don't trust that there is a straight-line loss of bits, you would 
have to be believing that the attack is much worse for SHA2/384 than it was for 
SHA2/256 in order to bring the output down to the level that I need.

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


RE: MD5 considered harmful today, SHA-1 considered harmful tomorrow

2009-01-18 Thread Paul Hoffman
At 12:24 PM +0100 1/12/09, Weger, B.M.M. de wrote:
When in 2012 the winner of the
NIST SHA-3 competition will be known, and everybody will start
using it (so that according to Peter's estimates, by 2018 half
of the implementations actually uses it), do we then have enough
redundancy?

No offense, Benne, but are serious? Why would everybody even consider it? 
Give what we know about the design of SHA-2 (too little), how would we know 
whether SHA-3 is any better than SHA-2 for applications such as digital 
certificates?

In specific, if most systems have implemented the whole SHA-2 family by the 
time SHA-3 is settled, and then there is a problem found in SHA-2/256, I would 
argue that it is probably much more prudent to change to SHA-2/384 than to 
SHA-3/256. SHA-2/384 will most likely be much than to SHA-3/256, but it will 
have had significantly more study.

It all depends on who you trust and why.

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Security by asking the drunk whether he's drunk

2009-01-02 Thread Paul Hoffman
At 10:19 PM -0500 12/30/08, Jerry Leichter wrote:
Robert Graham writes in Errata Security 
(http://erratasec.blogspot.com/2008/12/not-all-md5-certs-are-vulnerable.html) 
that the attack depends on being able to predict the serial number field that 
will be assigned to a legitimate certificate by the CA.  

That part is true.

Only a few CA's use predictable serial numbers

That part, I think, is wrong. I looked into this a bit earlier this month and 
found that most of the ones I looked at are still using sequential numbers.

- the field is actually arbitrary text

If by arbitrary text you mean a non-negative integer.

and need only be certainly unique among all certificates issued by a given CA.

True as well.

So:  The current attack is only effective against a very small number of CA's 
which both use MD5 *and* have predictable sequence numbers.  

The attack is on end users who trust a root store that has a trust anchor from 
*any single* CA that uses MD5 and has predictable sequence numbers. The attack 
lets the attacker become a subordinate CA for that CA. At that point, the 
attacker can issue their own certs for any purpose.

So the sky isn't falling

It never does. That's why it is the sky.

- though given how hard it is to decertify a CA (given that the known good 
CA's are known to literally billions of pieces of software, and that hardly 
anyone checks CRL's - and are there even CRL's for CA's?) this is certainly 
not a good situation.

There are not CRLs for CAs. That's why is it is a root store.

Oh, and how do you create a definitive list of CAs that use MD5 in their 
signatures?

This also doesn't mean that, now that the door has been opened, other attacks 
won't follow.  In fact, it's hard to imagine that this is the end of the 
story

Quite right.

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: TLS Server Name Indication and IDNA?

2008-10-24 Thread Paul Hoffman
RFC 4366 is somewhat of a mess. I do not remember the authors asking 
the authors of IDNA (of which I am one) about what they should do.


FWIW, I'm not sure why this would be on the cryptography list, but 
I'm not sure of that for most of the we can design a better UI 
threads either.



What should the SMTP client put in the RFC 4366 section 3.1 HostName:

- The ACE domain it is working with (xn--exmple-cua.com)?
- The underlying UTF8 domain name? (exämple.com)?


Hopefully, the former. But if that doesn't work, try the latter.


What should the server do when it receives the client's HostName?

- Convert ACE to UTF8?
- Convert UTF8 to ACE?


Hopefully, neither: leave it as an ACE.


What type of comparison is the server expected to perform?

- Convert UTF8 CommanName to ACE (also leave IA5 alone) and then compare?
- Convert ACE names in either subjectAltName or CN to UTF8 and then
  compare UTF8 strings (with NAMEPREP, STRINGPREP and all that jazz)?


Hopefully, neither: leave it as an ACE.


This can be (to say the least) rather unpleasant. If IDNA is only between
the user and the UI, with everything on the wire in ACE form,


Yes.


then all
the pain is avoided:


Yes+. That's why we designed IDNA that way.

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Cube cryptanalysis?

2008-09-14 Thread Paul Hoffman

At 11:08 AM -0700 8/21/08, Greg Rose wrote:
Adi mentioned that the slides and paper will go online around the 
deadline for Eurocrypt submission; it will all become much clearer 
than my wounded explanations then.


There now: http://eprint.iacr.org/2008/385

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: once more, with feeling.

2008-09-10 Thread Paul Hoffman

At 11:21 PM +0100 9/9/08, Dave Howe wrote:

Darren J Moffat wrote:

 Warnings aren't enough in this context [ whey already exists ] the
 only thing that will work is stopping the page being seen - replacing
 it with a clearly worded explanation with *no* way to pass through
 and render the page (okay maybe with a debug build of the browser but
 not in the shipped product).


One thing that concerns me is that in the new release of firefox, there
appears to be NO way to get to a site that has a bad certificate (or
self signed certificate) other than overriding the warning permanently -
no ok let me see it, I have seen the warning and want to look just this
once that the remember mismatched domains plugin for 2.x gave you.


That may concern you, but I consider it a feature. Instead of 
teaching users to always click through the damn dialog boxes, FF3 
says if you fell for it once, you're going to always fall for it so 
we won't teach you bad habits. There are arguments for either 
strategy.


Given that few or none of us on this list are actually trained 
interface experts, I'm sure we could debate this until Perry pulls 
the moderator switch again. The salient point is that people who have 
more stake in the game (Mozilla Inc.) have spent longer thinking 
about this than we give them credit for and come to the design 
decisions that they have.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: once more, with feeling.

2008-09-08 Thread Paul Hoffman

At 4:16 PM +0100 9/8/08, Darren J Moffat wrote:

Hopefully this is interesting enough to get forwarded on...


Ditto. :-)

Warnings aren't enough in this context [ whey already exists ] the 
only thing that will work is stopping the page being seen - 
replacing it with a clearly worded explanation with *no* way to pass 
through and render the page (okay maybe with a debug build of the 
browser but not in the shipped product).


It depends on how we think change can be achieved. Until now, people 
designing pages using bad security practices balanced their laziness 
with the fact that their content would be displayed anyway so 
whatever. You are proposing moving to the other extreme. Given how 
easy your solution would be for browser vendors to implement, we have 
to assume that they have considered it and rejected it.


A less extreme solution would be to make the warning the user sees on 
a mixed-content page more insulting to the bank. This page contains 
both encrypted and non-encrypted content and is inherently insecure. 
The owner of this web site has clearly made a very poor security 
decision in showing this page to you. It is likely that other pages 
on this site also have similarly poor security. Knowing this, do you 
wish to continue anyway?


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Voting machine security

2008-08-18 Thread Paul Hoffman

At 9:24 AM -0700 8/18/08, Eric Rescorla wrote:

(and because of the complexity of US elections,
hand counting is quite expensive)


This is quite disputable. Further, hand vs. machine counting is core 
to the way we think about the security of the voting system.


On a complex ballot, there are maybe 20 races or propositions, some 
of which may allow multiple votes per race. The pre-electronic method 
for hand-counting these was to start with race #1, have one person 
reading each vote out load from a large stack of ballots, and another 
person tabulating. In most districts, this is done twice with 
different people doing the counting and, often, those people coming 
from the opposite party in our wonderful two-party system.


The numbers I saw in the late 1970's said that each vote took 2.5 
seconds per ballot per race when done slowly; so that's 5 seconds 
when run twice. Per complex ballot, that's about 100 seconds, or 
roughly 2 minutes, or roughly 1/30 of an hour. At current labor rates 
of $12/hour for this type of work (that's high, but we want qualified 
people to count), that means it costs about US$0.40 per ballot for a 
complex ballot.


Essentially no one would argue that is is quite expensive. I 
suspect that nearly everyone in the country would be happy to pay an 
additional $1/election for more reliable results.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: OpenID/Debian PRNG/DNS Cache poisoning advisory

2008-08-08 Thread Paul Hoffman

At 1:47 PM -0500 8/8/08, Nicolas Williams wrote:

On Fri, Aug 08, 2008 at 02:08:37PM -0400, Perry E. Metzger wrote:

 The kerberos style of having credentials expire very quickly is one
 (somewhat less imperfect) way to deal with such things, but it is far
 from perfect and it could not be done for the ad-hoc certificate
 system https: depends on -- the infrastructure for refreshing all the
 world's certs every eight hours doesn't exist, and if it did imagine
 the chaos if it failed for a major CA one fine morning.


The PKIX moral equivalent of Kerberos V tickets would be OCSP Responses.

I understand most current browsers support OCSP.


...and only a tiny number of CAs do so.

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Kaminsky finds DNS exploit

2008-07-14 Thread Paul Hoffman

At 4:27 PM +0200 7/14/08, Florian Weimer wrote:

Implementors say that in many cases, their software as it's currently
implemented can't take the load.  It's not much worse than web traffic,
that's why I think it can be made to work (perhaps easier with kernel
support, who knows).  But code changes are apparently required.


That whole paragraph, taken together, makes no sense.


And once you need code changes, you can roll out DNSSEC--or some
extended query ID with 64 additional bits of entropy.


There is a difference between code changes in the kernel for some 
systems (which you allude to above), code changes and a universal 
rollout in all DNS software (which you allude to at the end), and 
stable rollout of the DNSSEC trust anchor system in every significant 
zone and all resolvers.


FWIW, only the latter has anything to do with this mailing list...

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Kaminsky finds DNS exploit

2008-07-09 Thread Paul Hoffman
First off, big props to Dan for getting this problem fixed in a 
responsible manner. If there were widespread real attacks first, it 
would take forever to get fixes out into the field.


However, we in the security circles don't need to spread the 
Kaminsky finds meme. Take a look at 
http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/. 
The first draft of this openly-published document was in January 
2007. It is now in WG last call.


The take-away here is not that Dan didn't discover the problem, but 
Dan got it fixed. An alternate take-away is that IETF BCPs don't 
make nearly as much difference as a diligent security expert with a 
good name.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Strength in Complexity?

2008-07-02 Thread Paul Hoffman

At 8:28 PM -0400 7/1/08, Perry E. Metzger wrote:

[EMAIL PROTECTED] (Peter Gutmann) writes:

 Perry E. Metzger [EMAIL PROTECTED] writes:


No. In fact, it is about as far from the truth as I've ever seen. No real
expert would choose to deliberately make a protocol more complicated.


 IPsec.  Anything to do with PKI.  XMLdsig.  Gimme a few minutes and I can
 provide a list as long as your arm.  Protocol designers *love* complexity.
 The more complex and awkward they can make a protocol, the better it has to
 be.


The problem, Peter, is that people who don't know you may mistake your
sarcasm for agreement with misconception in the article Arshad quoted.



The quote from the article was:

There are, of course, obstacles that must still be overcome by EKMI 
proponents. For example, the proposed components are somewhat simple 
by design, which concerns some encryption purists who prefer more 
complex protocols, on the logic that they're more difficult to break 
into.


It jumps from components to protocols. In general, encryption 
purists like simpler algorithms. OTOH, when encryption purists get 
involved in protocol design, the protocols usually become complex to 
the point of opacity.


So, I agree with Peter that that article is probably correct about protocols.

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Protection mail at rest

2008-06-02 Thread Paul Hoffman

At 11:36 AM -0400 6/1/08, Ivan Krstiç wrote:
The easiest thing for people who _do_ care is still running their 
own mail server.


Fully agree. You're in control, all the way to root of the box.

The emergence of reasonably priced VM hosting providers (e.g. 
slicehost.com) makes it fairly uncomplicated, modulo initial setup.


And, if you want to host on FreeBSD instead of Linux, see 
http://www.rootbsd.net/. Same price, good service.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: The perils of security tools

2008-05-22 Thread Paul Hoffman

I'm confused about two statements here:

At 2:10 PM +0100 5/13/08, Ben Laurie wrote:
The result of this is that for the last two years (from Debian's 
Edgy release until now), anyone doing pretty much any crypto on 
Debian (and hence Ubuntu) has been using easily guessable keys. This 
includes SSH keys, SSL keys and OpenVPN keys.


. . .

[2] Valgrind tracks the use of uninitialised memory. Usually it is 
bad to have any kind of dependency on uninitialised memory, but 
OpenSSL happens to include a rare case when its OK, or even a good 
idea: its randomness pool. Adding uninitialised memory to it can do 
no harm and might do some good, which is why we do it. It does cause 
irritating errors from some kinds of debugging tools, though, 
including valgrind and Purify. For that reason, we do have a flag 
(PURIFY) that removes the offending code. However, the Debian 
maintainers, instead of tracking down the source of the 
uninitialised memory instead chose to remove any possibility of 
adding memory to the pool at all. Clearly they had not understood 
the bug before fixing it.


The second bit makes it sound like the stuff that the Debian folks 
blindly removed was one, possibly-useful addition to the entropy 
pool. The first bit makes it sound like the stuff was absolutely 
critical to the entropy of produced keys. Which one is correct?


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: The perils of security tools

2008-05-22 Thread Paul Hoffman

At 10:25 AM +0100 5/15/08, Ben Laurie wrote:

Paul Hoffman wrote:

I'm confused about two statements here:

At 2:10 PM +0100 5/13/08, Ben Laurie wrote:
The result of this is that for the last two years (from Debian's 
Edgy release until now), anyone doing pretty much any crypto on 
Debian (and hence Ubuntu) has been using easily guessable keys. 
This includes SSH keys, SSL keys and OpenVPN keys.


. . .

[2] Valgrind tracks the use of uninitialised memory. Usually it is 
bad to have any kind of dependency on uninitialised memory, but 
OpenSSL happens to include a rare case when its OK, or even a good 
idea: its randomness pool. Adding uninitialised memory to it can 
do no harm and might do some good, which is why we do it. It does 
cause irritating errors from some kinds of debugging tools, 
though, including valgrind and Purify. For that reason, we do have 
a flag (PURIFY) that removes the offending code. However, the 
Debian maintainers, instead of tracking down the source of the 
uninitialised memory instead chose to remove any possibility of 
adding memory to the pool at all. Clearly they had not understood 
the bug before fixing it.


The second bit makes it sound like the stuff that the Debian folks 
blindly removed was one, possibly-useful addition to the entropy 
pool. The first bit makes it sound like the stuff was absolutely 
critical to the entropy of produced keys. Which one is correct?


They removed _all_ entropy addition to the pool, with the exception 
of the PID, which is mixed in at a lower level.


I take it that these are not 128-bit, non-monotonic PIDs. :-)

The bigger picture is that distributions who are doing local mods 
should really have an ongoing conversation with the software's 
developers. Even if the developers don't want to talk to you, a 
one-way conversation of we're doing this, we're doing that could be 
useful.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: The perils of security tools

2008-05-22 Thread Paul Hoffman
More interesting threadage about the issue here: 
http://taint.org/2008/05/13/153959a.html, particularly in the 
comments.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: SSL/TLS and port 587

2008-01-23 Thread Paul Hoffman

At 10:38 AM -0800 1/22/08, Ed Gerck wrote:
The often expressed idea that SSL/TLS and port 587 are somehow able 
to prevent warrantless wiretapping and so on, or protect any private 
communications, is IMO simply not supported by facts.


Can you point to some sources of this often expressed idea? It 
seems like a pretty flimsy straw man.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: SSL/TLS and port 587

2008-01-23 Thread Paul Hoffman

At 9:49 PM -0800 1/22/08, Ed Gerck wrote:
Can you point to some sources of this often expressed idea? It 
seems like a pretty flimsy straw man.


It is common with those who think that the threat model is
traversing the public Internet.


I'll take that as a no.


For examples on claiming that SSL/TLS can protect email
privacy,


That's not what I asked, of course.

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Fixing the current process

2007-10-10 Thread Paul Hoffman

At 10:55 PM +0200 10/8/07, Ian G wrote:
A slightly off-topic question:  if we accept that current processes 
(FIPS-140, CC, etc) are inadequate indicators of quality for OSS 
products, is there something that can be done about it?


Highly doubtful. The institutional inertia at DoD/NIST is too great. 
It has been suggested numerous times by numerous concerned parties 
for at least a decade.


Is there a reasonable criteria / process that can be built that is 
more suitable?


Yes. That part is easy, and some people in the system admit designing 
a much better system is quite tractable, as long as it is done in a 
vacuum. However, bureaucracy abhors a vacuum.


My feeling is that the only way that we can overturn the silliness of 
FIPS-140 / CC is for a major defense ally to implement a sane system. 
Five years later, and with a lot of vendor push, it could become a 
third process and the other two could wither over the ensuing 
decades. If we're lucky.



--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: more SHA-1 progress?

2007-08-22 Thread Paul Hoffman

At 10:17 AM -0400 8/22/07, Perry E. Metzger wrote:

Ekr's blog notes a rumor that more progress has been made on attacking SHA-1:

http://www.educatedguesswork.org/movabletype/archives/2007/08/sha1_rumors.html

Anyone know anything about this?


This is a continuation of the thread on this list from last week.

I watched the webcast of the rump session, and Christian Rechberger 
said that they think they will get 2^60ish with a new technique. He 
did not describe the technique in any detail. Offline, he has told me 
that there will be papers published.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fwd: Potential SHA 1 Hack Using Distributed Computing - Near Miss(es) May be Good Enough

2007-08-15 Thread Paul Hoffman

At 4:49 PM -0300 8/14/07, Mads Rasmussen wrote:

Have a look at

http://boinc.iaik.tugraz.at/sha1_coll_search


Did that, in specific 
http://www.iaik.tugraz.at/research/krypto/collision/SHA1Collision_Description.php


Note the lack of information about what they are actually doing. We 
developed new cryptanalytic methods... sounds great, but is 
meaningless without specifics.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fwd: Potential SHA 1 Hack Using Distributed Computing - Near Miss(es) May be Good Enough

2007-08-14 Thread Paul Hoffman

At 11:00 PM -0700 8/13/07, Aram Perez wrote:

Anyone know more about this?


I have the same question. I could not find any description of *why* 
they think that finding near-misses is going to help the research. 
It's not clear if they are taking their own path, or trying to 
improve Wang's path, or what.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: New article on root certificate problems with Windows

2007-07-21 Thread Paul Hoffman

At 7:58 PM +1200 7/20/07, [EMAIL PROTECTED] wrote:

Paul Hoffman [EMAIL PROTECTED] writes:

At 2:45 AM +1200 7/20/07, [EMAIL PROTECTED] wrote:
|From a security point of view, this is really bad.  From a 
usability point of

|view, it's necessary.

As you can see from my list of proposed solutions, I disagree. I see no
reason not to to alert a user *who has removed a root* that you are about to
put it back in.


It depends on what you mean by user.  You're assuming that direct action by
the wetware behind the keyboard resulted in its removal.


Correct, I was.


  However given how
obscure and well-hidden this capability is, it's more likely that a user agent
acting with the user's rights caused the problem.  So the message you end up
communicating to the user is:

  Something you've never heard of before has changed a setting you've never
  heard of before that affects the operation of something you've never heard
  of before and probably wouldn't understand no matter how patiently we
  explain it.

(those things are, in order some application or script, the cert trust
setting, certificates, and PKI).


Very good point.

Bigger picture takeaway: when both a user and an application can 
change a crypto setting in an application (or OS), any later messages 
relating to that event are likely to be confusing because they can't 
be directly linked to the action. This applies to all of our 
crypto-in-the-real-world, not just the trust anchor issue at hand.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: New article on root certificate problems with Windows

2007-07-19 Thread Paul Hoffman

At 2:45 AM +1200 7/20/07, [EMAIL PROTECTED] wrote:

From a security point of view, this is really bad.  From a usability point of
view, it's necessary.


As you can see from my list of proposed solutions, I disagree. I see 
no reason not to to alert a user *who has removed a root* that you 
are about to put it back in.


Note that I did not criticize the practice of starting with a zillion 
roots that Microsoft trusts.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Quantum Cryptography

2007-07-03 Thread Paul Hoffman

At 5:11 PM -0400 7/2/07, John Denker wrote:

By that I mean:
 -- the integrity of DH depends fundamentally on the algorithm, so you
  should verify the algorithmic theory, and then verify that the box
  implements the algorithm correctly; while
 -- in the simple case, the integrity of quantum cryptography depends
  fundamentally on the physics, so you should verify the physics
  theoretically and then verify that the box implements the physics
  correctly,
 ... and not vice versa.


This is a nice, calm analogy, and I think it is useful. But it misses 
the point of the snake oil entirely.


The fact that there is some good quantum crypto theory doesn't mean 
that there is any application in the real world. For the real world, 
you need key distribution. For the cost of a quantum crypto box (even 
after cost reductions after years of successful deployment), you 
could put a hardware crypto accelerator that could do 10,000-bit DH.


Going back to the theory, the only way that quantum crypto will be 
more valuable than DH (much less ECDH!) is if DH is broken *at all 
key lengths*. If it is not, then the balance point for cost will be 
when the end boxes for quantum crypto equals the cost of the end 
boxes for still-useful DH.


Oh, and all the above is ignoring that DH works over multiple hops of 
different media, and quantum crypto doesn't (yet, maybe ever).


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: ad hoc IPsec or similiar

2007-06-26 Thread Paul Hoffman

At 2:49 PM -0500 6/26/07, Nicolas Williams wrote:

On Fri, Jun 22, 2007 at 10:43:16AM -0700, Paul Hoffman wrote:
  This was discussed many times, and always rejected as not good

 enough by the purists. Then the IETF created the BTNS Working Group
 which is spending huge amounts of time getting close to purity again.


That's pretty funny, actually, although I don't quite agree with the
substance (surprise!)  :)


Why, are you some sort or purist? :-) (For those outside the IETF, 
Nico is one of the main movers and shakers in BTNS, and is probably 
one of the main reasons it looks like it will actually finish its 
work.)



Seriously, for those who merely want unauthenticated IPsec, MITMs and
all, then yes, agreeing on a globally shared secret would suffice.


Well, almost suffice. You also need a way of signalling before the 
Diffie-Hellman that this is what you are doing, but that's a trivial 
extension to both IKEv1 and IKEv2.



For all the other aspects of BTNS (IPsec connection latching [and
channel binding], IPsec APIs, leap-of-faith IPsec) agreeing on a
globally shared secret does not come close to being sufficient.


Fully agree. BTNS will definitely give you more than just one-off 
encrypted tunnels, once the work is finished. But then, it should 
probably be called MMTBTNS (Much More Than...).


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: ad hoc IPsec or similiar

2007-06-26 Thread Paul Hoffman

At 3:26 PM -0500 6/26/07, Nicolas Williams wrote:

I strongly dislike the WG's name.  Suffice it to say that it was not my
idea :); it created a lot of controversy at the time, though perhaps
that controversy helped sell the idea (why would you want this silly,
insecure stuff? because it enables this other actually secure stuff).


Whereas I was in the camp of liking the name very much for the very 
reason that this thread was started: because it lets you encrypt an 
arbitrary conversation with essentially no startup cost.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Quantum Cryptography

2007-06-22 Thread Paul Hoffman

At 10:59 AM -0700 6/21/07, Ali, Saqib wrote:

- Quantum Cryptography is fiction (strictly claims that it solves
  an applied problem are fiction, indisputably interesting Physics).


Well that is a broad (and maybe unfair) statement.

Quantum Key Distribution (QKD) solves an applied problem of secure key
distribution. It may not be able to ensure unconditional secrecy
during key exchange, but it can detect any eavesdropping. Once
eavesdropping is detected, the key can be discarded.


...whereas the key distribution systems we have aren't affected by 
eavesdropping unless the attacker has the ability to perform 2^128 or 
more operations, which he doesn't.


Which part of the word useless is not apparent here?

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: ad hoc IPsec or similiar

2007-06-22 Thread Paul Hoffman

At 11:52 PM +0800 6/22/07, Sandy Harris wrote:

On 6/22/07, Eugen Leitl [EMAIL PROTECTED] wrote:


So what's the state in ad hoc IPsec/VPN setup for any end points?


The Linux FreeS/WAN project was working on opportunistic encryption.

The general idea is that if you use keys in DNS to authenticate gateways
and IPsec for secure tunnels then any two machines can communicate
securely without their administrators needing to talk to each other or to
set up specific pre-arranged tunnels.

http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/glossary.html#carpediem
http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/quickstart.html

There is an RFC based on that work:
ftp://ftp.rfc-editor.org/in-notes/rfc4322.txt

The FreeS/WAN project has ended. I do no know if the follow-on projects,
openswan.org and strongswan.org, support OE.


Note that that RFC is Informational only. There were a bunch of 
perceived issues with it, although I think they were more purity 
disagreements than anything.


FWIW, if you do *not* care about man-in-the-middle attacks (called 
active attacks in RFC 4322), the solution is much, much simpler than 
what is given in RFC 4322: everyone on the Internet agrees on a 
single pre-shared secret and uses it. You lose any authentication 
from IPsec, but if all you want is an encrypted tunnel that you will 
authenticate all or parts of later, you don't need RFC 4322.


This was discussed many times, and always rejected as not good 
enough by the purists. Then the IETF created the BTNS Working Group 
which is spending huge amounts of time getting close to purity again.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Quantum Cryptography

2007-06-22 Thread Paul Hoffman

At 10:44 AM -0700 6/22/07, Ali, Saqib wrote:

...whereas the key distribution systems we have aren't affected by
eavesdropping unless the attacker has the ability to perform 2^128 or
more operations, which he doesn't.


Paul: Here you are assuming that key exchange has already taken place.


No, I'm not. I am talking about protocols that do their own key 
exchange. IPsec. SSL/TLS. Kerberos. Etc.



But key exchange is the toughest part.


No, requiring that the two ends have a fixed connection which QKD 
works over is far tougher than using a proven protocol that works 
over any connection.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


SSL certificates for SMTP

2007-05-24 Thread Paul Hoffman

At 6:34 PM +0200 5/23/07, Florian Weimer wrote:

* Victor Duchovni:


 That's good of you not to expect it, given that zero of the major CAs
 seem to support ECC certs today, and even if they did, those certs
 would not work in IE on XP.


 We are not talking about this year or next of course. My estimate is
 that Postfix releases designed this year, ship next year, are picked up
 by some O/S vendors the year after and shipped perhaps a year after that,
 then customers take a few years to upgrade, ... So for some users Postfix
 2.5 will be their MTA upgrade in 2011 or later. So we need to anticipate
 future demand by a few years to be current at the time that users begin
 to use the software.


But no one is issuing certificates which are suitable for use with
SMTP (in the sense that the CA provides a security benefit).


No one? I thought that VeriSign and others did, at least a few years ago.


  As far
as I know, there isn't even a way to store mail routing information in
X.509 certificates.


Why would you need to? SMTP-over-TLS only identifies the system to 
whom you are speaking. No routing inforation is needed or wanted.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: 307 digit number factored

2007-05-23 Thread Paul Hoffman
For the math weenies on the list, see the full announcement here: 
http://listserv.nodak.edu/cgi-bin/wa.exe?A2=ind0705L=nmbrthryT=0P=1019.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: 307 digit number factored

2007-05-22 Thread Paul Hoffman
FWIW, according to Arjen Lenstra, there should be a better paper than 
the physorg.com article on the eprint.iacr.org site next week, 
hopefully.


At 4:32 PM -0400 5/21/07, Victor Duchovni wrote:

When do the Certicom patents expire?


Which ones? They have many. Using EC depends on how brave you are and 
which country you are in.



I really don't see ever longer RSA
keys as the answer, and the patents are I think holding back adoption...


Because I agree with the latter, I disagree with the former, at least 
for a few more years and until a few people are braver than I am.



The other issue is that sites will need multiple certs during any
transition from RSA to ECC, because the entire Internet won't upgrade
overnight. I am not expecting public CAs to cooperate by charging the
same price for two certs (RSA and ECC) for the same subject name(s),
this also may significantly impede migration.


That's good of you not to expect it, given that zero of the major CAs 
seem to support ECC certs today, and even if they did, those certs 
would not work in IE on XP.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: 0wned .gov machines (was Re: Russian cyberwar against Estonia?)

2007-05-21 Thread Paul Hoffman

At 6:34 PM + 5/20/07, John Levine wrote:

 I've heard nothing formal, but my strong understanding is a lot of US

government machines, at least if we're talking workstations on
non-classified nets, are in fact 0wn3d at this point.


Well, here's an anecdote: at last year's CEAS conference, Rob Thomas
of Team Cymru gave the keynote on the underground economy, with a most
horrifying set of both live demos and selected snapshots of the online
bazaars where online warez are traded, everything from zombie farms to
spamware to stolen credit cards.  One of the more amusing was a guy
who offered a zombie in some part of the government that you'd hope
would be moderately secure, NASA or someplace like that, at a higher
than normal price.  The immediate response was ridicule, bots on
government nets are a dime a dozen, and aren't worth any more than any
other bot.


Oh, goodie. I get to the same source to show the opposite. At Rob's 
talk at the AOTA summit, he talked about someone offering some botted 
machines in a particular US government subnet at a normal prices and 
someone quickly over-bid by a suspiciously high amount. The 
assumption is that it was for the possible data on those machines.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: More info in my AES128-CBC question

2007-04-22 Thread Paul Hoffman

At 2:04 PM -0700 4/21/07, David Wagner wrote:

Hagai Bar-El writes:

What Aram wrote is many of the attendees have very little security
experience, not: there are no attendees with security experience.
There are people at the relevant OMA group who know enough about
security, but just like in the real world -- they are outnumbered by
plain feature-set people, and thus have to come up with very clear
arguments to get their way.


So the people who don't know anything about security are reluctant to
listen to those who do?  That's not a good sign. It may be standard
operating procedure in groups like this, but that doesn't make it right.
It's still dysfunctional and dangerrous.  If the committee doesn't have
a commitment to security and is reluctant to listen to the experts,
that's a risk factor.


In a typical standards-setting environment, non-security people are 
usually only willing to listen to security people up to a certain 
threshold. There are three normal scenarios:


- A security person proposes a good way to do security for the 
proposed protocol. A non-security person says (incorrectly) I heard 
that doesn't work. The security person argues that it does work 
here, and the non-security person, not wanting to look foolish, digs 
in his heels. People get bored of hearing an argument they don't 
understand and make an arbitrary decision.


- A non-security person proposes a bad way to do security for the 
proposed protocol. A security person explains why that is insecure. 
The non-security person argues (sometimes correctly) that they did it 
in this other protocol so we should copy that, and the security 
person tries to explain why this is bad security. People get bored of 
hearing an argument they don't understand and make an arbitrary 
decision.


- A security person proposes two different ways to do security for 
the proposed protocol. The second is significantly faster than the 
first, but has worse security properties. People say the first is 
good enough for our scenario and pick it, often not even bothering 
to document the diminished security properties.


FWIW, this can happen when designing pure security protocols, 
swapping non-security person with security novice or security 
tourist or security hobbiest or security poser.



So why do people with no training in security think
that they can freely ignore the advice of security professionals without
any negative consequences?


Because doing so can get things finished earlier and/or make a more 
efficient protocol.


Same as it ever was.

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: DNSSEC to be strangled at birth.

2007-04-06 Thread Paul Hoffman

At 7:26 PM -0400 4/5/07, Thor Lancelot Simon wrote:

On Thu, Apr 05, 2007 at 07:32:09AM -0700, Paul Hoffman wrote:


 Control: The root signing key only controls the contents of the root,
 not any level below the root.


That is, of course, false,


This is, of course false. In order to control the contents of the 
second level of the DNS, they have to either change the control of 
the first level (it's kinda obvious when they take .net away from 
VeriSign) or they have to sign across the hierarchy (it's kinda 
obvious when furble.net is signed by someone other than .net).



and presumably is _exactly_ why DHS wants
the root signing key:


Um, since when are you (or I) so good at figuring out what DHS wants? 
For that matter, assuming that a massive bureaucracy like DHS has one 
thing that it wants also seems silly. For all we know, this could be 
one clue-deprived dork who can write press releases after not really 
listening to the one technical person whom he asked. Or it could be a 
conspiracy to take over the Department of Commerce. Or ...



because, with it, one can sign the appropriate
chain of keys to forge records for any zone one likes.


If the owner of any key signs below their level, it is immediately 
visible to anyone doing active checking. The root signing furble.net 
instead of .net signing furble.net is a complete giveaway to a 
violation of the hierarchy and an invitation for everyone to call 
bullshit on the signer. Doing so would completely negate the value of 
owning the root-signing key.



Plus, now that applications are keeping public keys for services in
the DNS, one can, in fact, forge those entries and thus conduct man in
the middle surveillance on anyone dumb enough to use DNS alone as a
trust conveyor for those protocols (e.g. SSH and quite possibly soon
HTTPS).


...again assuming that the users of those keys don't bother to look 
who signed them. Given that this thread is about an entity whom 
almost no one trusts being the key holder, that scenario seems 
unlikely.



I know you understand this stuff well enough to know these risks exist.
I'm curious why you'd minimize them.


Because I believe that ISPs, not just security geeks, will be 
vigilant in watching whether there is any layer-hopping signing and 
will scream loudly when they see it. AOL and MSN have much more to 
lose if DHS decides to screw with the DNS than anyone on this list 
does. Having said that, it is likely that we will be the ones to 
shoot the signal flares if DHS (or ICANN, for that matter) misuses 
the root signing key. But it won't be us that causes DHS to stand 
down or, more likely, get thrown off the root: it's the companies who 
have billions of dollars to lose if the DNS becomes untrusted.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: DNSSEC to be strangled at birth.

2007-04-06 Thread Paul Hoffman

At 7:54 PM -0400 4/5/07, Thor Lancelot Simon wrote:

On Thu, Apr 05, 2007 at 04:49:33PM -0700, Paul Hoffman wrote:


 because, with it, one can sign the appropriate
 chain of keys to forge records for any zone one likes.

 If the owner of any key signs below their level, it is immediately
 visible to anyone doing active checking. The root signing furble.net
 instead of .net signing furble.net is a complete giveaway to a
 violation of the hierarchy and an invitation for everyone to call
 bullshit on the signer. Doing so would completely negate the value of
 owning the root-signing key.


You're missing the point.  The root just signs itself a new .net key,
and then uses that to sign a new furble.net key, and so forth.  No
unusual key use is required.


And you seem to be missing my point. If the root signs itself a new 
.net key, it will be completely visible to the entire community using 
DNSSEC. The benefit of doing so in order to forge the key for 
furble.net (or microsoft.com) will be short-lived, as will the 
benefit of owning the root key.



It's a hierarchy of trust: if you have the top, you have it all, and
you can forge anything you like, including the keys used to sign the
application key records used to encrypt user data, where they are
present in the system.


The only reason for concern is if the top of the hierarchy can forge 
without people noticing, or if people notice that they won't care. I 
claim that that isn't possible, particularly if the root owner is 
someone as unloved as USDHS.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: DNSSEC to be strangled at birth.

2007-04-06 Thread Paul Hoffman

[[ Agree with Nico's MITM arguments; different point below ]]

At 10:49 AM -0500 4/6/07, Nicolas Williams wrote:

The DHS would get real value in terms of veto power over new TLDs, IFF
it is the only one to possess the root private key.  But that's not what
the story said, IIRC.


Whoever owns the root key would only get to veto the inclusion of new 
or current TLDs in the DNSSEC-protected namespace, not in the root 
itself. No one expects that ICANN will be signing the zone keys for 
most of the TLDs for many, many years, if for no other reason than 
those TLDs don't even want to be responsible for protecting their 
zone key.



The real problem with DHS having these keys in _addition_ to ICANN is
that the more fingers in the pie the more likely it is that the key will
be breached, leading to key rollover.


Fully agree. It also means that, if there is a breach, the first few 
days / months will be spent finger-pointing instead of fixing.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: DNSSEC to be strangled at birth.

2007-04-05 Thread Paul Hoffman

anti-rant

At 5:51 PM +0100 4/4/07, Dave Korn wrote:

  Can anyone seriously imagine countries like Iran or China signing up to a
system that places complete control, surveillance and falsification
capabilities in the hands of the US' military intelligence?


No.

But how does having the root signing key allow those?

Control: The root signing key only controls the contents of the root, 
not any level below the root.


Surveillance: Signing keys don't permit any surveillance.

Falsification: This is possible but completely trivially detected (it 
is obvious if the zone for furble.net is signed by . instead of 
.net). Doing any falsification will cause the entire net to start 
ignoring the signature of the root and going to direct trust of the 
signed TLDs.



 Surely if this goes ahead, it will mean that DNSSEC is doomed to widespread
non-acceptance.


More than it is now?


And unless it's used everywhere, there's very little point
having it at all.


Fully disagree. Many ISPs and individuals will be happy to do direct 
trust of the significant zones (com/net/org plus maybe their local 
ccTLD) and simply ignore signatures on the rest. This has already 
been well-discussed in the ISP community even before this event: many 
are not sure they trust ICANN itself, much less its current sponsor.


Note that I'm not supporting the US signing the root in the least. 
I'm just saying that predicting doom is grossly premature.


/anti-rant

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: more on NIST hash competition

2007-01-26 Thread Paul Hoffman

At 9:30 PM +1300 1/25/07, Peter Gutmann wrote:

=?UTF-8?B?SXZhbiBLcnN0acSH?= [EMAIL PROTECTED] writes:

Perry E. Metzger wrote:

 http://www.csrc.nist.gov/pki/HashWorkshop/index.html


I'm completely unfamiliar with the way NIST operates, but I've been wondering
for years why they haven't organized this competition already. Do we have a
list veteran who can shed some light on why it took them this long? My
curiosity demands to know.


The AES competition was already a severe resource drain, running another one
for an AHS would have been prohibitive, until the clear signs that SHA was in
real trouble made it more palatable.


This is an incorrect interpretation, I believe. The NIST folks at the 
workshop said a few times that they were not worried about SHA-1 
because they have already deprecated it beginning at the end of 2010. 
That leaves only SHA-2, in which they said they had sufficient 
confidence. Further, no one publicly expressed worry at the workshop 
that SHA-2 would have any significant breaks in the near future.


The dates on the competition timeline shows that AHS (cute name, 
Peter!) is not meant as a replacement for SHA-2, given that it won't 
be selected until after SHA-1 needs to stop being used.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: more on NIST hash competition

2007-01-25 Thread Paul Hoffman

At 8:22 PM -0500 1/23/07, Ivan Krstiç wrote:

Perry E. Metzger wrote:

 http://www.csrc.nist.gov/pki/HashWorkshop/index.html


I'm completely unfamiliar with the way NIST operates, but I've been
wondering for years why they haven't organized this competition already.
Do we have a list veteran who can shed some light on why it took them
this long? My curiosity demands to know.


At the Second Hash Workshop this summer, NIST explained this a bit. 
(There were a bunch of regulars from this list there who can correct 
me if I'm wrong.)


First, there is SHA-2 (SHA-256, -384, and -512). Nearly everyone 
thinks they are good enough unless there is an unexpected attack. So 
NIST was not hot to create something that competes with this.


More important, however, is the lack of sureness in the community 
that we know what will make a good hash function, much less one that 
is better than SHA-2. See 
http://www.proper.com/lookit/hash-futures-panel-notes.html for much 
more on that.


Also, remember that we don't know much about the design of SHA-2. In 
fact, unless the NSA tells the world a whole lot more, it will not be 
able to compete in the NIST competition due to requirement B1 in the 
proposal.


At the end of the workshop, there were at least two camps: those who 
wanted a competition in case Wang-esque attacks degrade SHA-2, and 
those who didn't want a competition until we knew more about how to 
judge it because we don't know enough now. Some of the Big Names In 
Crypto are in the second group. It looks like NIST sided with the 
first group, but it will be interesting if the folks in the second 
group are vocal during the coming few years.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: SC-based link encryption

2007-01-05 Thread Paul Hoffman

At 7:58 PM -0800 1/3/07, Steve Schear wrote:
I haven't been following the smartcard scene for a while.  I'm 
looking to create a low-cost and portable link encryptor, with D-H 
or similar key exchange, for lower 100kbps data speeds. Is this 
possible?


You could take an IPsec stack and repurpose it down one layer in the 
stack. At least that way you'll know the security properties of what 
you create.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: How important is FIPS 140-2 Level 1 cert?

2006-12-22 Thread Paul Hoffman

At 11:25 AM -0500 12/21/06, Saqib Ali wrote:

I would like to know how much weight people usually give to the FIPS
140-2 Level 1 certification.


US federal agencies are supposed to require that certification for 
any system they buy that uses crypto.


Sometimes, US state agencies require it as well.

Sometimes, clueless corporations require it because it has the word 
certification in it and, well, if it's good enough for the feds, it 
should be good enough for everyone.



If two products have exactly same feature set, but one is FIPS 140-2
Level 1 certified but cost twice. Would you go for it, considering the
Level 1 is the lowest.


Assuming that the two products use Internet protocols (as compared to 
proprietary protocols): no. Probably the only thing that could 
differentiate the two is if the cheaper one has a crappy random 
number generator, the more expensive one will have a good one.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: How important is FIPS 140-2 Level 1 cert?

2006-12-22 Thread Paul Hoffman

At 8:15 PM -0500 12/21/06, Saqib Ali wrote:

Assuming that the two products use Internet protocols (as compared to
proprietary protocols):


I don't understand this statement. What do you mean by internet
protocol vs proprietary protocol???


Now seeing what your company does, I can see where you might have 
that question. An overly-simple but sufficient answer comes from 
whether or not you need to be able to interoperate with other vendors 
over a non-secured network. If so, call it an internet protocol. In 
your case (local disk encryption), it is fine to be proprietary.



And also we are looking at FDE solutions, so there are no internet
protocols involved in that.


Right.


no. Probably the only thing that could
differentiate the two is if the cheaper one has a crappy random
number generator, the more expensive one will have a good one.


well I think FIPS 140-2 Level 1 ensures more than just a good PRNG.
Even if a public crypto (e.g. AES) is used in a product, there are
many mistakes that can be made during the implementation.


... and essentially all of those mistakes are caught by even mild 
interop testing. Again, this is not valid in your case. You could 
completely mis-implement AES and never know it, but a FIPS 140-2 test 
would find that.



And FIPS
140-2 Level 1 is expected to catch these egregious mistakes.


You can catch such mistakes for a lot less money than it will cost 
for a FIPS certificate. Assuming that you are using a standard 
encryption algorithm like AES, there are probably a dozen people on 
this mailing list who could sanity check your product's 
implementation of AES (and probably even of key storage) in less than 
50 hours of consulting time,


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: signing all outbound email

2006-09-09 Thread Paul Hoffman

At 7:02 AM +1000 9/8/06, James A. Donald wrote:

I do not seem to be able to use DKIM to for spam
filtering.


Correct. It is for white-listing. It tells the recipient (MTA or MUA) 
that the message received was sent from the domain name it says it 
was, and that parts of the message were not altered.



I would like to whitelist all validly signed
DKIM from well known domains.


Good; that's what the protocol is designed to do.


One way of doing this would be for the MTA to insist on
a valid signature when talking to certain well known
MTAs, and then my MUA could whitelist mail sent from
those well known MTAs


Yes, if you are willing to throw out messages whose signatures are 
broken during transit. (This is the same risk that others face with 
insisting on valid S/MIME or OpenPGP signatures be on every message 
from particular parties.)



In short, I am not able to get any advantage out of
using this protocol, which means that there is no
advantage in sending me signed mail.


And there is no disadvantage either. There is advantages for sending 
signed mail to users who have a different threat model than you have, 
and there are certainly administrative advantages to signing all 
outgoing mail, not looking to see oh, if it is James, don't sign it 
because he won't like it.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: signing all outbound email

2006-09-07 Thread Paul Hoffman

At 11:40 AM +0200 9/5/06, Massimiliano Pala wrote:

Jon Callas wrote:


On 4 Sep 2006, at 4:13 AM, Travis H. wrote:


Has anyone created hooks in MTAs so that they automagically

[...]

Go look at http://www.dkim.org/ for many more details.


This approach is MTA-to-MTA...


No, it's not. The receiving MTA *and/or* MUA can verify signatures. 
That is clearly covered in the protocol document.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Phil Zimmerman and voice encryption; a Skype problem?

2006-05-22 Thread Paul Hoffman

At 10:19 AM -0400 5/22/06, Steven M. Bellovin wrote:

There's an article in today's NY Times (for subscribers, it's at
http://www.nytimes.com/2006/05/22/technology/22privacy.html?_r=1oref=slogin )
on whether Phil Zimmerman's Zfone -- an encrypted VoIP package -- will
invite government scrutiny.  There doesn't seem to be any imminent threat
in the U.S.; the one concrete example mentioned -- the British plan to
give police the power to compel individuals to disclose keys -- doesn't
threaten Zfone, because it uses Diffie-Hellman for (among other things)
perfect forward secrecy and doesn't even have any long-term keys.  (See
draft-zimmermann-avt-zrtp-01.txt for protocol details.)

The fascinating thing, though, was this sentence near the end of the
article:

But at a conference last week in Cyprus, German officials said
they had technology for intercepting and decrypting Skype phone
calls, according to Anthony M. Rutkowski, vice president for
regulatory affairs and standards for VeriSign, a company that
offers security for Internet and phone operations.

The Berson report says that Skype uses AES-256.  NSA rates that as
suitable for Top Secret traffic, so it's presumably not the cipher.
Berson analyzed a number of other possible attack scenarios; the only one
that seems to be possible is an active attack plus forged certificates.
If Berson's analysis was correct -- and we all know how hard it is to
verify cryptographic protocols -- that leaves open the possibility of a
protocol change that implemented some sort of Clipper-like functionality.


Please don't forget that the VeriSign spokesperson may be mistaken, 
or purposely lying (possibly in order to drum up business for the 
company). Neither would be a first for VeriSign.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: NPR : E-Mail Encryption Rare in Everyday Use

2006-02-24 Thread Paul Hoffman

At 4:31 PM -0800 2/23/06, Ed Gerck wrote:

Usability should by now be recognized as the key issue for security -


Fully agree.


namely, if users can't use it, it doesn't actually work.


We disagree on the meaning of the phrase actually work.


And what I heard in the story is that even savvy users such as Phil Z
(who'd have no problem with key management) don't use it often.


Phil *does* have a problem with key management. He knows how to do 
it, but his communications partners are not as good as he is.



BTW, just to show that usability is king, could you please send me an
encrypted email -- I even let you choose any secure method that you want.


Yes, I could. But I won't bother. :-)

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: NPR : E-Mail Encryption Rare in Everyday Use

2006-02-23 Thread Paul Hoffman

At 1:56 PM -0800 2/23/06, Ed Gerck wrote:

This story (in addition to the daily headlines) seems to make the case that
the available techniques for secure email (hushmail, outlook/pki and pgp) do
NOT actually work.


That's an incorrect assessment of the short piece. The story says 
that it does actually work but no one uses it. They briefly say why: 
key management. Not being easy enough to use is quite different than 
NOT actually working.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: general defensive crypto coding principles

2006-02-12 Thread Paul Hoffman

At 5:40 PM + 2/12/06, Ben Laurie wrote:

It also defends against the MD5 crack, and is one of the recommended
IETF solutions to hash problems.


s/recommended/proposed/

The IETF has not recommended any solutions to hash problems. The 
sense of the room at the Hash BOF and the SAAG discussion at the 
Paris IETF meeting was that the IETF should *not* propose solutions 
to the problem. That is why the BOF did not turn into a Working Group 
and why there has been little discussion of the proposed solutions in 
the relevant IETF working groups.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: crypto wiki -- good idea, bad idea?

2005-12-12 Thread Paul Hoffman

At 9:57 AM -0600 12/12/05, Travis H. wrote:
Would a wiki specifically for crypto distribute the burden enough to 
be useful?

Or should we just stick to wikipedia?  Is it doing a satisfactory job?


I cannot answer the first question: I am leery of wikis that have 
open posting rights, and I am leery of trusting anyone to maintain 
the posting rights and document quality of a wiki without being paid 
(either in money or whuffie) to do so.


The second and third questions can be answered with no. Someone 
wrote a fairly poor article on VPNs. That article has been flagged as 
needing a lot of work. I proposed a few weeks ago (in the 
meta-discussion) to do it, but was concerned that doing so would step 
on toes and seem invasive. No one has responded to that, not even the 
people who flagged the article as needing work.


In other words, Wikipedia is trying to correct problems, but doesn't 
have the personpower to do so in a predictable fashion.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: RNG implementations and their problems

2005-12-04 Thread Paul Hoffman

At 10:54 PM -0600 12/3/05, Travis H. wrote:

I'm dissatisfied with the state of /dev/random devices on Unix.


Depends on what you mean by Unix. FreeBSD 5 and 6 have much of what you want.


So far I haven't seen any userland tools for updating the entropy count.


From 'man 4 random':
 If the device has is using the software generator, writing data to random
 would perturb the internal state.  This perturbation of the internal
 state is the only userland method of introducing extra entropy into the
 device.  If the writer has superuser privilege, then closing the device
 after writing will make the software generator reseed itself.  This can
 be used for extra security, as it immediately introduces any/all new
 entropy into the PRNG.


The entropy harvesting and estimation code is bound too tightly to the
entropy pool.

It is in kernelspace so cannot do floating point, like measuring
chi-square or Shannon entropy to estimate the amount of randomness.


 The software random device may be controlled with sysctl(8).

 To see the devices' current settings, use the command line:

   sysctl kern.random

 which results in something like:

   kern.random.sys.seeded: 1
   kern.random.sys.burst: 20
   kern.random.sys.harvest.ethernet: 0
   kern.random.sys.harvest.point_to_point: 0
   kern.random.sys.harvest.interrupt: 0
   kern.random.yarrow.gengateinterval: 10
   kern.random.yarrow.bins: 10
   kern.random.yarrow.fastthresh: 100
   kern.random.yarrow.slowthresh: 160
   kern.random.yarrow.slowoverthresh: 2

 (These would not be seen if a hardware generator is present.)

 All settings are read/write.

Thus, you can do your own calculations and change the paramters to 
your heart's content (assuming you have root privs).


(...Other Linux-specific complaints elided...)

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: [Clips] Banks Seek Better Online-Security Tools

2005-12-03 Thread Paul Hoffman

At 11:05 PM -0500 12/2/05, [EMAIL PROTECTED] wrote:

You know, I'd wonder how many people on this
list use or have used online banking. 


To start the ball rolling, I have not and won't.


I have, and it's nice for making Quicken data entry faster, but 
that's about all. The rest gives me the willies when I see the 
security clue of the folks running the site.


FWIW, I have never had a problem changing my password to something 
very long and all-alphabetic, even if I don't include at least one 
capital letter and one digit or whatever the CYA rules for passwords 
are these days.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: ISAKMP flaws?

2005-11-17 Thread Paul Hoffman

At 11:20 AM +0100 11/17/05, Florian Weimer wrote:

These bugs have been uncovered by a PROTOS-style test suite.  Such
test suites can only reveal missing checks for boundary conditions,
leading to out-of-bounds array accesses and things like that.  In
other words, trivial implementation errors which can be easily avoided
using proper programming tools.


Which proper programming tools would check for a logic path failure 
when a crafted packet includes Subpacket A that is only supposed to 
be there when Subpacket B is there, but the packet doesn't include 
Subpacket B? There are no programming tools that check for this, or 
for related issues: it has to be the implementer who has enough 
understanding of the protocol and enough time (and program space) to 
code against such issues.


Throw in PKIX certificates in certificate chains, and it gets much worse.

IKE is a very complicated protocol with many within-packet and 
within-stream dependencies. These cannot be resolved by proper 
programming tools unless those tools are specifically crafted for 
IKE. SSL/TLS probably suffers the same fate.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: ISAKMP flaws?

2005-11-15 Thread Paul Hoffman

At 10:14 AM -0500 11/15/05, Perry E. Metzger wrote:

Some articles have been appearing in various web sites about flaws in
IPSec key negotiation protocols, such as this one:

http://news.com.com/VPN+flaw+threatens+Internet+traffic/2100-1002_3-5951916.html

I haven't been following the IPSec mailing lists of late -- can anyone
who knows details explain what the issue is?


The advisory itself is at 
http://www.uniras.gov.uk/niscc/docs/br-20051114-01013.html?lang=en. 
Note that the abstract is Multiple Vulnerability Issues in 
Implementation of ISAKMP Protocol, with emphasis on Implementation 
of. It appears that this is *not* a problem with ISAKMP or IKE, but 
instead only a problem with some implementations. A summary would be 
when some IKEv1 implementations are sent certain malformed messages, 
they stop, reboot, or possibly do other bad things.


Given that they started this research with sending malformed SNMP 
packets to SNMP-aware systems (with similar results), it is safe to 
extrapolate the results to implementations of nearly any protocol to 
varying extents. It is likely that this applies to IKEv2 as well, but 
using differently-malformed packets. It is also likely that it 
applies to some SSL/TLS implementations, of course using very 
different malformed packets.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: ISAKMP flaws?

2005-11-15 Thread Paul Hoffman

At 2:29 PM -0500 11/15/05, Steven M. Bellovin wrote:

I mostly agree with you, with one caveat: the complexity of a spec can
lead to buggier implementations.


Well, then we fully agree with each other. Look at the message 
formats used in the protocols they have attacked successfully so far.


Humorously, security folks seem to have ignored this when designing 
our protocols.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: PKI too confusing to prevent phishing, part 28

2005-09-26 Thread Paul Hoffman

At 8:53 AM +0200 9/26/05, Amir Herzberg wrote:

Is PKI the cause of this? I think not. This is a usability problem.

We try to fix this problem (and similar problems) with TrustBar. 
Indeed we even had incidents where people on the TrustBar team 
itself, and some security experts using TrustBar, thought there is a 
bug - why does TrustBar display `Bad Certificate` warning, when 
FireFox says the site is protected fine? But then we found out it 
was simply a self-signed site, or a site signed by a CA not in the 
list of the browser, or the most hard-for-users: a site with a 
certificate whose issuer is specified as Verisign (say), but with a 
wrong public key... this last one is really tricky; even expert 
users get confused in identifying this, even when using the 
certificate details dialogs (I checked for FireFox and IE).


To me, the first paragraph contradicts the second paragraph. 
Actually, the third sentence of the first paragraph contradicts the 
first two sentences of that paragraph.


A technology that cannot be made usable, but is widely used anyway, 
is the cause of its own problems.


There are many problems with PKI, and certainly with its 
implementation in browsers. But secure usability problems are worse. 
I think our community should try to be constructive. I definitely 
try myself, hence TrustBar. Please help me: try it and give me 
feedback, if you are a good programmer, lend a hand improving it; or 
find other ideas and implement them.


Looking at decades of experience with PC software, it seems unlikely 
that TrustBar or anything like it will be deployed and understood by 
typical users. It is fine to help increase the security for a small 
(possibly tiny) audience, but please do not conflate that with making 
the whole market more noticeably secure.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: ECC patents?

2005-09-14 Thread Paul Hoffman

At 12:18 PM +0300 9/14/05, Alexander Klimov wrote:

This hints that indeed only some particular curves are patented.


It's not just curves. Certicom has patents for some optimizations and 
methods for validating the strength of some uses of ECC.



Grepping -list_curves of the new openssl (0.9.8) which has a list of
curves from SECG, WTLS, NIST, and X9.62 gives not that much:

  secp256k1 : SECG curve over a 256 bit prime field
  secp384r1 : NIST/SECG curve over a 384 bit prime field
  secp521r1 : NIST/SECG curve over a 521 bit prime field
  prime256v1: X9.62/SECG curve over a 256 bit prime field

Alternatively, this coverage can be interpreted that NSA is not
interested in curves which provide less security than 128-bit AES.

Any idea, which alternative is true?


Both are probably true. Why would anybody be interested in curves 
that do not support their minimum strength ciphers?


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: ECC patents?

2005-09-13 Thread Paul Hoffman

At 9:32 AM -0700 9/12/05, James A. Donald wrote:

It has been a long time, and no one has paid out
money on an ECC patent yet.


That's pretty bold statement that folks at Certicom might disagree 
with, even before 
http://www1.ietf.org/proceedings_new/04nov/slides/saag-2/sld1.htm.


--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Another entry in the internet security hall of shame....

2005-09-01 Thread Paul Hoffman

At 9:39 AM +0200 9/1/05, Stephan Neuhaus wrote:

Are we now at a point where we must admit that PKI isn't going to happen


s/happen/happen in a widely useful fashion/


 for the Web


s/Web/Web and email/

 and that we therefore must face the rewriting of an unknown (but 
presumably large) number of lines of code to accomodate PSKs?


Self-signed certificates that are fingerprinted out-of-band are 
better than PSKs in some situations, worse in others.


  If that's so, I believe that PSKs will have deployment problems as 
large as PKI's that will prevent their widespread acceptance.


Bingo.

--Paul Hoffman, Director
--VPN Consortium

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]