Re: [Cryptography] SSH small RSA public exponent

2013-10-12 Thread Peter Gutmann
Tim Hudson t...@cryptsoft.com writes:

Does anyone recollect the history behind and the implications of the (open)
SSH choice of 35 as a hard-wired public exponent?

/* OpenSSH versions up to 5.4 (released in 2010) hardcoded e = 35, which is
   both a suboptimal exponent (it's less efficient that a safer value like 257
   or F4) and non-prime.  The reason for this was that the original SSH used
   an e relatively prime to (p-1)(q-1), choosing odd (in both senses of the
   word) numbers  31.  33 or 35 probably ended up being chosen frequently so
   it was hardcoded into OpenSSH for cargo-cult reasons, finally being fixed
   after more than a decade to use F4.  In order to use pre-5.4 OpenSSH keys
   that use this odd value we make a special-case exception for SSH use */

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


Re: [Cryptography] Key stretching

2013-10-11 Thread Peter Gutmann
Phillip Hallam-Baker hal...@gmail.com writes:

Quick question, anyone got a good scheme for key stretching?

http://lmgtfy.com/?q=hkdfl=1

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


Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?

2013-10-10 Thread Peter Gutmann
Watson Ladd watsonbl...@gmail.com writes:

The obvious solution: Do it right the first time.

And how do you know that you're doing it right?  PGP in 1992 adopted a
bleeding-edge cipher (IDEA) and was incredibly lucky that it's stayed secure
since then.  What new cipher introduced up until 1992 has had that
distinction?  Doing it right the first time is a bit like the concept of
stopping rules in heuristic decision-making, if they were that easy then
people wouldn't be reading this list but would be in Las Vegas applying the
stopping rule stop playing just before you start losing.

This is particularly hard in standards-based work because any decision about
security design tends to rapidly degenerate into an argument about whose
fashion statement takes priority.  To get back to an earlier example that I
gave on the list, the trivial and obvious fix to TLS of switching from MAC-
then-encrypt to encrypt-then-MAC is still being blocked by the WG chairs after
nearly a year, despite the fact that a straw poll on the list indicated
general support for it (rough consensus) and implementations supporting it are
already deployed (running code).  So do it right the first time is a lot
easier said than done.

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


[Cryptography] Universal security measures for crypto primitives

2013-10-07 Thread Peter Gutmann
Given the recent debate about security levels for different key sizes, the
following paper by Lenstra, Kleinjung, and Thome may be of interest:

  Universal security from bits and mips to pools, lakes and beyond
  http://eprint.iacr.org/2013/635.pdf  

From now on I think anyone who wants to argue about resistance to NSA attack
should be required to rate their pet scheme in terms of
neerslagverdampingsenergiebehoeftezekerheid (although I'm tempted to suggest
the alternative tausendliterbierverdampfungssicherheit, it'd be too easy to
cheat on that one).

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


Re: [Cryptography] encoding formats should not be committee'ized

2013-10-04 Thread Peter Gutmann
d...@geer.org writes:

The (U.S.) medical records system that started at the Veterans'
Administration and has now spread to all but all parts of the U.S. Federal
government that handle electronic health records is ASCII encoded, and
readable.  Called The Blue Button,[1] there is even an HL7-Blue Button
file converter.[2]

Score one for human readable.

Things like HL7 and EDIFACT/X12 (and ASN.1 in DER/BER form) were never meant
to be human-readable, they're meant to be easily machine readable and
processable.  This is why you have viewers to turn them into human-readable
form in any format you want.  The problem with formats like XML is that it's
never been quite sure what it wants to be, so that the result is neither
easily human-readable nor easily machine-readable.

Trying to get back on track, I think any attempt at TLS 2 is doomed.  We've
already gone through, what, about a million messages bikeshedding over the
encoding format and have barely started on the crypto.  Can you imagine any
two people on this list agreeing on what crypto mechanism to use?  Or whether
identity-hiding (at the expense of complexity/security) should trump
simplicity/security 9at the expense of exposing identity information)?

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


Re: [Cryptography] encoding formats should not be committee'ized

2013-10-03 Thread Peter Gutmann
Jerry Leichter leich...@lrw.com writes:

My favorite more recent example of the pitfalls is TL1, a language and
protocol used to managed high-end telecom equipment.  TL1 has a completely
rigorous syntax definition, but is supposed to be readable.

For those not familiar with TL1, supposed to be readable here means encoded
in ASCII rather than binary.  It's about as readable as EDIFACT and HL7.

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


Re: [Cryptography] RSA recommends against use of its own products.

2013-09-29 Thread Peter Gutmann
Phillip Hallam-Baker hal...@gmail.com writes:

Quite, who on earth thought DER encoding was necessary or anything other than
incredible stupidity?

At least some X.500/LDAP folks thought they could do it.  Mind you, we're
talking about people who believe in X.500/LDAP here...

Peter.

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


Re: [Cryptography] RSA recommends against use of its own products.

2013-09-26 Thread Peter Gutmann
=?iso-8859-1?Q?Kristian_Gj=F8steen?= kristian.gjost...@math.ntnu.no writes:

(For what it's worth, I discounted the press reports about a trapdoor in
Dual-EC-DRBG because I didn't think anyone would be daft enough to use it. I
was wrong.)

+1.  It's the Vinny Gambini effect (from the film My Cousin Vinny):

  Judge Haller: Mr. Gambini, didn't I tell you that the next time you appear
in my court that you dress appropriately?
  Vinny: You were serious about dat? 

And it's not just Dual-EC-DRBG that triggers the You were serious about dat? 
response, there are a number of bits of security protocols where I've been... 
distinctly surprised that anyone would actually do what the spec said.

(Having said that, I've also occasionally been pleasantly surprised when, by 
unanimous unspoken consensus among implementers, everyone ignored the spec and 
did the right thing).

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


Re: [Cryptography] RSA recommends against use of its own products.

2013-09-26 Thread Peter Gutmann
ianG i...@iang.org writes:

Well, defaults being defaults, we can assume most people have left it in
default mode.  I suppose we could ask for research on this question, but I'm
going to guess:  most.

“Software Defaults as De Facto Regulation: The Case of Wireless APs”, Rajiv
Shah and Christian Sandvig, Proceedings of the 33rd Research Conference on
Communication, Information and Internet Policy (TPRC’07), September 2005,
reprinted in Information, Communication, and Society, Vol.11, No.1 (February
2008), p.25.

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

Re: [Cryptography] forward-secrecy =2048-bit in legacy browser/servers? (Re: RSA equivalent key length/strength)

2013-09-26 Thread Peter Gutmann
Adam Back a...@cypherspace.org writes:

Is there a possibility with RSA-RSA ciphersuite to have a certified RSA
signing key, but that key is used to sign an RS key negotiation?

Yes, but not in the way you want.  This is what the 1990s-vintage RSA export
ciphersuites did, but they were designed so you couldn't use them to provide
strong security.

I imagine that ciphersuite is widely disabled at this point.

That'd be the other problem :-).

Peter.

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


Re: [Cryptography] RSA equivalent key length/strength

2013-09-25 Thread Peter Gutmann
Stephen Farrell stephen.farr...@cs.tcd.ie writes:

That's a mischaracterisation I think. Some folks (incl. me) have said that
1024 DHE is arguably better that no PFS and if current deployments mean we
can't ubiquitously do better, then we should recommend that as an option,
while at the same time recognising that 1024 is relatively short.

+1.

Peter.


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


Re: [Cryptography] RSA equivalent key length/strength

2013-09-25 Thread Peter Gutmann
Peter Fairbrother zenadsl6...@zen.co.uk writes:
On 24/09/13 05:27, Peter Gutmann wrote:
 Peter Fairbrother zenadsl6...@zen.co.uk writes:
 If you just want a down-and-dirty 2048-bit FS solution which will work 
 today,
 why not just have the websites sign a new RSA-2048 sub-certificate every 
 day?
 Or every few hours? And delete the secret key, of course.

 ... and I guess that puts you firmly in the theoretical/impractical camp.
 Would you care to explain how this is going to work within the TLS protocol?

I'm not sure I understand you.

Something that can sign a new RSA-2048 sub-certificate is called a CA.  For 
a browser, it'll have to be a trusted CA.  What I was asking you to explain is 
how the browsers are going to deal with over half a billion (source: Netcraft 
web server survey) new CAs in the ecosystem when websites sign a new RSA-2048 
sub-certificate.

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


Re: [Cryptography] RSA equivalent key length/strength

2013-09-24 Thread Peter Gutmann
Patrick Pelletier c...@funwithsoftware.org writes:

I'm inclined to agree with you, but you might be interested/horrified in the
1024 bits is enough for anyone debate currently unfolding on the TLS list:

That's rather misrepresenting the situation.  It's a debate between two
groups, the security practitioners, we'd like a PFS solution as soon as we
can, and given currently-deployed infrastructure DH-1024 seems to be the best
bet, and the theoreticians, only a theoretically perfect solution is
acceptable, even if it takes us forever to get it.

(You can guess from that which side I'm on).

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


Re: [Cryptography] RSA equivalent key length/strength

2013-09-24 Thread Peter Gutmann
Peter Fairbrother zenadsl6...@zen.co.uk writes:

If you just want a down-and-dirty 2048-bit FS solution which will work today,
why not just have the websites sign a new RSA-2048 sub-certificate every day?
Or every few hours? And delete the secret key, of course.

... and I guess that puts you firmly in the theoretical/impractical camp.
Would you care to explain how this is going to work within the TLS protocol?
It's easy enough to throw out these hypothetical what-if's (gimme ten minutes
and I'll dream up half a dozen more, all of them theoretically OK, none of
them feasible), but they need to actually be deployable in the real world, and
that's what's constraining the current debate.

Peter.

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


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

2013-09-19 Thread Peter Gutmann
Phillip Hallam-Baker hal...@gmail.com writes:

I have not spent a great deal of time looking at the exact capabilities of
PRISM vs the other programs involved because from a design point they are
irrelevant. The objective is to harden/protect the infrastructure from any
ubiquitous, indiscriminate intercept capability like the one Gen Alexander
appears to have constructed.

Precisely.  I made the same point recently in an interview about PRISM, that a
well-designed, well-engineered protocol will be NSA-proof (or at least as NSA-
proof as you can get within reason).  It'll also be Russian mafia-proof,
Chinese-government-proof, and your-mother-proof.  There isn't some exotic
class of protocol or mechanism that's needed to resist the NSA, anything well-
designed and implemented can do it.

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


Re: [Cryptography] Gilmore response to NSA mathematician's make rules for NSA appeal

2013-09-18 Thread Peter Gutmann
Walter van Holst walter.van.ho...@xs4all.nl writes:

These are not rights that are solely vested in the exceptional Americans. The
Bill of Tights [...]

For people unfamiliar with this one, it's the bit that reads:

  Congress shall make no law respecting the wearing of hosiery, or prohibiting
  the free exercise thereof; or abridging the freedom of colour selection, or
  of the material used; or the right of the people peaceably to assemble, and
  to petition the manufacturers for a redress of manufacturing defects.

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


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

2013-09-17 Thread Peter Gutmann
Tony Arcieri basc...@gmail.com writes:
On Mon, Sep 16, 2013 at 9:44 AM, Bill Frantz fra...@pwpconsult.com wrote:
 After Rijndael was selected as AES, someone suggested the really paranoid
 should super encrypt with all 5 finalests in the competition. Five level
 super encryption is probably overkill, but two or three levels can offer
 some real advantages.

I wish there was a term for this sort of design in encryption systems beyond
just defense in depth. AFAICT there is not such a term.

How about the Failsafe Principle? ;)

How about Stannomillinery?

Peter.


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


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

2013-09-12 Thread Peter Gutmann
zooko zo...@zooko.com writes:

I agree that randomness-reuse is a major issue. Recently about 55 Bitcoin 
were stolen by exploiting this, for example:

http://emboss.github.io/blog/2013/08/21/openssl-prng-is-not-really-fork-safe/

Was that the change that was required by FIPS 140, or a different vuln?

Peter.


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


Re: [Cryptography] Radioactive random numbers

2013-09-12 Thread Peter Gutmann
Dave Horsfall d...@horsfall.org writes:

Given that there is One True Source of randomness to wit radioactive
emission, has anyone considered playing with old smoke detectors?

The ionising types are being phased out in favour of optical (at least in
Australia) so there must be heaps of them lying around.

If you're in Australia you don't need to use smoke detectors, you've got 
direct access to the real stuff.  I've used a lump of Australian uranium ore 
with my geiger counter in the past.  Problem is that this is hardly scalable.

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


Re: [Cryptography] Suite B after today's news

2013-09-11 Thread Peter Gutmann
Ben Laurie b...@links.org writes:

Feel free to argue the toss with IANA:
http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml

Hmm, I talked to person involved in the process earlier this year to let him 
know that 0x10 was already being used, I'd assumed it'd be marked as RFU, but 
I guess not.  Maybe we could use 36, which follows on from the SessionTicket 
one at 35 and is far enough up that it won't be overrun for awhile.

Annoying though, there are already deployed implementations that use 0x10.

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


Re: [Cryptography] Suite B after today's news

2013-09-10 Thread Peter Gutmann
Ben Laurie b...@links.org writes:

We need to get an extension number allocated, since the one it uses clashes
with ALPN.

It does?  draft-ietf-tls-applayerprotoneg-01 doesn't mention ID 0x10 anywhere.

(In any case -encrypt-then-MAC got there first, these Johnny-come-lately's can
find their own ID to squat on :-).

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


Re: [Cryptography] Market demands for security (was Re: Opening Discussion: Speculation on BULLRUN)

2013-09-09 Thread Peter Gutmann
Phillip Hallam-Baker hal...@gmail.com writes:

People buy guns despite statistics that show that they are orders of
magnitude more likely to be shot with the gun themselves rather than by an
attacker.

Some years ago NZ abolished its offensive (fighter) air force (the choice was 
either to buy all-new, meaning refurbished, jets at a huge cost or abolish the 
capacity).  Lots of people got very upset about this, because it was leaving 
us defenceless.

(For people who are wondering why this position is silly, have a look at the
position of New Zealand on a world map.  The closest country with direct
access to us (in other words that wouldn't have to go through other countries
on the way here) is Peru, and they don't have any aircraft carriers).

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


Re: [Cryptography] Protecting Private Keys

2013-09-08 Thread Peter Gutmann
Jeffrey I. Schiller j...@mit.edu writes:

If I was the NSA, I would be scavenging broken hardware from “interesting”
venues and purchasing computers for sale in interesting locations. I would be
particularly interested in stolen computers, as they have likely not been
wiped.

Just buy second-hand HSMs off eBay, they often haven't been wiped, and the
PINs are conveniently taped to the case.  I have a collection of interesting
keys (or at least keys from interesting places, including government
departments) obtained in this way.

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

Re: [Cryptography] Suite B after today's news

2013-09-08 Thread Peter Gutmann
Ralph Holz ralph-cryptometz...@ralphholz.de writes:

I've followed that list for a while. What I find weird is that there should
be much dissent at all. This is about increasing security based on adding
quite well-understood mechanisms. What's to be so opposed to there?

There wasn't really much dissent (there was some discussion, both on and off-
list, which I've tried to address in updates of the draft), it's just that the
WG chairs don't seem to want to move on it.

Does adding some ciphersuites really require an extension, maybe even on the
Standards Track? I shouldn't think so, looking at the RFCs that already do
this, e.g. RFC 5289 for AES-GCM. Just go for an Informational. FWIW, even
HTTPS is Informational.

I've heard from implementers at Large Organisations that having it non-
standards-track makes it hard to get it adopted there.  I guess I could go for
Informational if all else fails.

I don't think it hurts to let users and operators vote with their feet here.

That's what's already happened/happening, problem is that without an RFC to
nail down at least the extension ID it's a bit hard for commercial vendors to
commit to it.

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-06 Thread Peter Gutmann
ianG i...@iang.org writes:

 And, controlling processes is just what the NSA does.

 https://svn.cacert.org/CAcert/CAcert_Inc/Board/oss/oss_sabotage.html

How does '(a) Organizations and Conferences' differ from SOP for these sorts
of things?

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


Re: [Cryptography] Suite B after today's news

2013-09-06 Thread Peter Gutmann
Ralph Holz ralph-cryptometz...@ralphholz.de writes:

But for right now, what options do we have that are actually implemented
somewhere? Take SSL. CBC mode has come under pressure for SSL (CRIME, BEAST,
etc.), and I don't see any move towards TLS  1.0.

http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-02 fixes all of
these, I just can't get any traction on it from the TLS WG chairs.  Maybe
they're following
http://svn.cacert.org/CAcert/CAcert_Inc/Board/oss/oss_sabotage.html :-).

Peter.

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


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

2013-09-05 Thread Peter Gutmann
John Denker j...@av8n.com writes:

To say the same thing the other way, I was always amazed that the Nazis were
unable to figure out that their crypto was broken during WWII.  There were
experiments they could have done, such as sending out a few U-boats under
strict radio silence and comparing their longevity to others.

Cognitive dissonance.  We have been..., sorry Ve haff been reassured zat
our cipher is unbreakable, so it must be traitors, bad luck, technical issues,


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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

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

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

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

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

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

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

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

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


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

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

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

Our direct competitor has asked us to recommend a technology for whatever it 
is that LDAP is meant to be the solution for.  What should we recommend to 
them?.

(Bit of an artificial example, but between that and Corba you can really mess
up someone's business).

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


Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?

2013-09-05 Thread Peter Gutmann
[Apparently a pile of my mail got dropped, the following few messages are 
re-sends]

The Doctor dr...@virtadpt.net writes:

It might be a reasonable way of protecting PGP key information in DNS records
so that someone doesn't try inserting their own when it's looked up.

And that's the problem with DNS, it's the only global distributed database
that we've got, so everyone wants to use it as the universal substrate for,
well, anything.  We'd just need to get draft-ietf-dnsind-kitchen-sink-02.txt
adopted and people could cram anything they liked into the DNS.

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


Re: [Cryptography] NSA and cryptanalysis

2013-09-05 Thread Peter Gutmann
John Kelsey crypto@gmail.com writes:

If I had to bet, I'd bet on bad rngs as the most likely source of a
breakthrough in decrypting lots of encrypted traffic from different sources.

If I had to bet, I'd bet on anything but the crypto.  Why attack when you can
bypass [1].

Peter.

[1] From Shamir's Law [2], crypto is bypassed, not penetrated.
[2] Well I'm going to call it a law, because it deserves to be.
[3] This is a recursive footnote [3].
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] Keeping backups (was Re: Separating concerns

2013-09-05 Thread Peter Gutmann
Phillip Hallam-Baker hal...@gmail.com writes:

To backup the key we tell the device to print out the escrow data on paper.
Let us imagine that there there is a single sheet of paper which is cut into
six parts as follows:

You read my mind :-).  I suggested more or less this to a commercial provider
a month or so back when they were trying to solve the same problem.
Specifically it was if you lose your key/password/whatever, you can't call
the helpdesk to get your data back, it's really gone, which was causing them
significant headaches because users just weren't expecting this sort of thing.
My suggestion was to generate a web page in printable format with the key
shares in standard software-serial-number form (X-X-X etc) and
tell people to keep one part at home and one at work, or something similar,
and to treat it like they'd treat their passport or insurance documentation.

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

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

At the very least, anyone whining at a standards meeting from now on that
they don't want to implement a security fix because it isn't important to
the user experience or adds minuscule delays to an initial connection or
whatever should be viewed with enormous suspicion.

I think you're ascribing way too much of the usual standards committee
crapification effect to enemy action.  For example I've had an RFC draft for a
trivial (half a dozen lines of code) fix for a decade of oracle attacks and
whatnot on TLS sitting there for ages now and can't get the TLS WG chairs to
move on it (it's already present in several implementations because it's so
simple, but without a published RFC no-one wants to come out and commit to
it).  Does that make them NSA plants?  There's drafts for one or two more
fairly basic fixes to significant problems from other people that get stalled
forever, while the draft for adding sound effects to the TLS key exchange gets
fast-tracked.  It's just what standards committees do.

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

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


Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

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

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

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

  k = G(t,KKEY) mod q

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

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

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

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


Re: [Cryptography] Suite B after today's news

2013-09-05 Thread Peter Gutmann
Jon Callas j...@callas.org writes:

My opinion about GCM and GMAC has not changed. I've never been a fan.

Same here.  AES is, as far as we know, pretty secure, so any problems are
going to arise in how AES is used.  AES-CBC wrapped in HMAC is about as solid
as you can get.  AES-GCM is a design or coding accident waiting to happen.
This isn't the 1990s, we don't need to worry about whether DES or FEAL or IDEA
or Blowfish really are secure or not, we can just take a known-good system off
the shelf and use it.  What we need to worry about now is deployability.  AES-
CTR and AES-GCM are RC4 all over again, it's as if we've learned nothing from
the last time round.

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


Re: [Cryptography] Suite B after today's news

2013-09-05 Thread Peter Gutmann
Jon Callas j...@callas.org writes:

How do you feel (heh, I typoed that as feal) about the other AEAD modes?

If it's not a stream cipher and doesn't fail catastrophically with IV reuse
then it's probably as good as any other mode.  Problem is that at the moment
modes like AES-CTR are being promulgated as fashion statements without any
consideration about operational deployment, when what we should be promoting
is something that's safely and effectively deployable.  Someblockcipher-CBC +
HMAC is a nice safe bet, run your HMAC, do a constant-time compare of the
result, toss the encrypted data if you get a verify failure, otherwise
decrypt, it's pretty straightforward.

Peter.

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


Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?

2013-08-26 Thread Peter Gutmann
Ralph Holz ralph-cryptometz...@ralphholz.de writes:

There is a host of older literature, too - P2P research, however, has become
a cold topic. Although I expect that it will see a revival in the face of
surveillance.

For people who are interested, the list I have (for a year or two back) is:

Security Considerations for Peer-to-Peer Distributed Hash Tables, Emil Sit
and Robert Morris, Proceedings of the 1st International Workshop on Peer-to-
Peer Systems (IPTPS'01), Springer-Verlag LNCS No.2429, March 2002, p.261.

A Survey of Peer-to-Peer Security Issues, Dan Wallach, Proceedings of the
2002 International Symposium on Software Security (ISSS'02), Springer-Verlag
LNCS No.2609, November 2002, p.42.

Eclipse Attacks on Overlay Networks: Threats and Defenses, Atul Singh,
Tsuen-Wan Ngan, Peter Druschel and Dan Wallach, Proceedings of the 25th
International Conference on Computer Communications (INFOCOM'06), April 2006,

The Index Poisoning Attack in P2P File Sharing Systems, Jian Liang, Naoum
Naoumov and Keith Ross, Proceedings of the 25th Conference on Computer
Communications (INFOCOM'06), April 2006,

Conducting and Optimizing Eclipse Attacks in the Kad Peer-to-Peer Network,
Michael Kohnen, Mike Leske and Erwin Rathgeb, Proceedings of the 8th IFIP-TC 6
Networking Conference (Networking'09), Springer-Verlag LNCS No.5550, May 2009,
p.104.

Combating Index Poisoning in P2P File Sharing, Lingli Deng, Yeping He and
Ziyao Xu, Proceedings of the 3rd Conference and Workshops on Advances in
Information Security and Assurance (ISA'09), Springer-Verlag LNCS No.5576,
June 2009, p.358.

Hashing it out in public: Common failure modes of DHT-based anonymity
schemes, Andrew Tran, Nicholas Hopper and Yongdae Kim, Proceedings of the 8th
Workshop on Privacy in the Electronic Society (WPES'09), November 2009, p.71.

Poisoning the Kad Network, Thomas Locher, David Mysicka, Stefan Schmid and
Roger Wattenhofer, Proceedings of the 11th International Conference on
Distributed Computing and Networking (ICDCN'10), Springer-Verlag LNCS No.5935,
January 2010, p.195.

If there's anything significant I've missed, feel free to fill in the gaps.

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


Re: Computer health certificate plan: Charney of DoJ/MS

2010-10-08 Thread Peter Gutmann
Before people get too far into conspiracy theories with this, I should point
out that health certificates have been part of corporate Windows environments
for years (I don't know how many exactly, I think it's been since at least
Server 2003).  The intent of health certs is that it allows the IT department
to manage PCs by allowing checks that they have the latest AV updates
installed, the corporate desktop background and Windows theme, the corporate
mail client in an up-to-date version, and so on.  In other words it's a
configuration management solution.  Think cfengine with certs.

In this case it looks like a MS spokesperson has decided that the existing
cfengine-with-certs approach used in corporate environments would work on an
ISP-wide or even nation-wide level.  It's no conspiracy theory, just a case of
either cluelessness about scaling issues or misreporting of a blue-sky, what-
if proposal.  I'd guess it's the latter.

Peter.

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


Re: Formal notice given of rearrangement of deck chairs on RMS PKItanic

2010-10-07 Thread Peter Gutmann
Victor Duchovni victor.ducho...@morganstanley.com writes:

What are EE certs, did you mean EV?

End-entity certs, i.e. non-CA certs.  This means that potentially after the 
end of this year and definitely after 2013 it will not be possible to use any 
key shorted than 2048 bits with Firefox.  Anyone using, for example, an 
embedded device adminstered via SSL will have to use another browser.

From the discussion on the Mozilla policy list I get the impression that this 
move has been given pretty much zero thought beyond we need to do what NIST 
wants.

Peter.

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


Re: What if you had a very good entropy source, but only practical at crypto engine installation time?

2010-10-07 Thread Peter Gutmann
Thierry Moreau thierry.mor...@connotech.com writes:

The PUDEC (Practical Use of Dice for Entropy Collection) scheme has been 
advanced. The new web page is at http://pudec.connotech.com

Plus the PUDEC dice sets are now offered for sale.

Hmm, they're somewhat expensive... a cheaper alternative, even if they require 
a bit more manual effort, are these:

  http://www.amazon.com/Gamestation-d16-Hexidice/dp/B0012YVYXU

(16-sided dice numbered 0...F, $1 each, although shipment outside the US is 
damn expensive).

Peter.

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


Re: Formal notice given of rearrangement of deck chairs on RMS PKItanic

2010-10-07 Thread Peter Gutmann
Matt Crawford craw...@fnal.gov writes:

EE = End Entity, but I don't read the first sentence the way Peter did. 

As I mentioned in my previous followup, it's badly worded, but the intent is 
to ban any keys  2K bits of any kind (currently with evolving weasel-words 
about letting CAs certify them up to 2013 or so if the user begs really hard).

Peter.

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


Formal notice given of rearrangement of deck chairs on RMS PKItanic

2010-10-06 Thread Peter Gutmann
From https://wiki.mozilla.org/CA:MD5and1024:

  December 31, 2010 - CAs should stop issuing intermediate and end-entity
  certificates from roots with RSA key sizes smaller than 2048 bits [0]. All
  CAs should stop issuing intermediate and end-entity certificates with RSA
  key size smaller than 2048 bits under any root.

  Under no circumstances should any party expect continued support for RSA key
  size smaller than 2048 bits past December 31, 2013. This date could get
  moved up substantially if necessary to keep our users safe. We recommend all
  parties involved in secure transactions on the web move away from 1024-bit
  moduli as soon as possible.

Right, because the problem with commercial PKI is all those attackers who are
factoring 1024-bit moduli, and apart from that every other bit of it works
perfectly.

Peter.

[0] This is ambiguously worded, but it's talking about key sizes in EE certs.

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


Re: 'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps

2010-10-03 Thread Peter Gutmann
Jerry Leichter leich...@lrw.com writes:

By the way, the don't acknowledge whether it was the login ID or the
password that was wrong example is one of those things everyone knows -
along with change your password frequently - that have long passed their
use by date.  

You got there before I did - real-world studies of users have shown that a
common failure mode for this is that when users get their user name wrong they
then try every password they can think of under the assumption that they've
remembered the wrong password for the site.  So not only does not
distinguishing between incorrect username and incorrect password not help [0],
it actually makes things much, much worse by training users to enter every
password for every site they know.

Peter.

[0] Well, it helps the attackers I guess...

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


Something you have, something else you have, and, uh, something else you have

2010-09-17 Thread Peter Gutmann
From the ukcrypto mailing list:

  Just had a new Lloyds credit card delivered, it had a sticker saying I have
  to call a number to activate it. I call, it's an automated system.

  It asks for the card number, fair enough. It asks for the expiry date, well
  maybe, It asks for my DOB, the only information that isn't actually on the
  card, but no big secret. And then it asks for the three-digit-security-code-
  on-the-back, well wtf?

  AIUI, and I may be wrong, the purpose of activation is to prevent lost-in-
  the-post theft/fraud - so what do they need details which a thief who has
  the card in his hot sweaty hand already knows for?

Looks like it's not just US banks whose interpretation of n-factor auth is n
times as much 1-factor auth.

Peter.

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


More on padding oracles

2010-09-16 Thread Peter Gutmann
Brian Holyfield has created another implementation of the padding oracle
exploitation tool first described by Juliano Rizzo and Thai Duong, as well as
providing a step-by-step, easy-to-understand explanation of how the attack
works, you can find it at:

http://www.gdssecurity.com/l/b/2010/09/14/automated-padding-oracle-attacks-with-padbuster/

Peter.

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


Re: 'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps

2010-09-15 Thread Peter Gutmann
Tom Ritter t...@ritter.vg writes:

What's weird is I find confusing literature about what *is* the default for
protecting the viewstate.

I still haven't seen the paper/slides from the talk so it's a bit hard to
comment on the specifics, but if you're using .NET's FormsAuthenticationTicket
(for cookie-based auth, not viewstate protection) then you get MAC protection
built-in, along with other nice features like sliding cookie expiration (the
cookie expires relative to the last active use of the site rather than an
absolute time after it was set).  I've used it in the past as an example of
how to do cookie-based auth right

Peter.

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


A mighty fortress is our PKI, Part III

2010-09-15 Thread Peter Gutmann
Some more amusing anecdotes from the world of PKI:

- A standard type of fraud that's been around for awhile is for scammers to
  set up an online presence for a legit offline business, which appears to
  check out when someone tries to verify it.  A more recent variation on this
  is to buy certs for legit businesses.  One of these certs was traced back by
  a security researcher who found that the scammers had obtained it through
  the incredibly devious trick of shopping round commercial CAs until they
  found one that was prepared to sell them a certificate.

- In a repeat of the original race to the bottom with non-EV certs, CA's have
  issued EV certs for RFC 1918 addresses (!!!).  What makes this particularly
  entertaining is that in combination with a router warkitting attack and
  Moxie Marlinspike's OCSP faking it allows an attacker to spoof any EV-cert
  site.

- The list of people who have bought certificates for Apple from commercial
  CAs keeps on growing (I guess Microsoft is just so five minutes ago :-).
  For example one SMTP admin needed a cert for his server and wondered what
  would happen if he asked for one for *.apple.com instead of his actual
  domain name.  $100 and a cursory check later he had a wildcard cert for
  Apple.  At least two more users have reported buying certificates for Apple,
  and there are probably even more lurking out there - if you too have a
  certificate from a certificate vending machine saying that you're Apple, do
  get in touch

- There's malware out there that pokes fake Verisign certificates into the
  Windows trusted cert store, allowing the malware authors to be their own
  Verisign.

- CAs have issued certs to cybercrime web sites like
  https://www.pay-per-install.com (an affiliate program for malware
  installers), because hey, the Russian mafia's money is as good as anyone
  else's.

- One of the most important things a CA needs to manage is certificate serial
  numbers, because the combination { CA name, cert serial number } is a unique
  identifier used in lots of security protocols to identify certs.  Without
  this uniqueness, you can't tell who signed something, you can't revoke a
  cert, you can't... well, you get the idea.  Not only have commercial CAs
  issued certs with duplicate serial numbers, they've issued *CA certs* with
  duplicate serial numbers.  Ouch!

  (When this was pointed out to the CA who did this - oops, my bad, we'll get
  those re-issued for you - someone else pointed out that their OCSP
  responder certs had expired, which none of the CA's clients appeared to have
  noticed until then.  Yeah, we'll look into fixing those too.  Anything else
  while we're at it?).

If anyone has any further amusing PKI stories, please get in touch, I'd love
to add a Part IV to this series.

Peter.

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


Re: Debian encouraging use of 4096 bit RSA keys

2010-09-14 Thread Peter Gutmann
Perry E. Metzger pe...@piermont.com writes:

One wonders what security model indicated 4096 bits is the ideal length

The one that says that if you wind things up past 11 (4096 bits), various
things break.

(D'you really think they applied any kind of security analysis to the choice
of key size?  They just wound it up until they got to 11, then declared that
the new key size).

Peter.

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


Re: Intel plans crypto-walled-garden for x86

2010-09-14 Thread Peter Gutmann
John Gilmore g...@toad.com writes:

Let me guess -- to run anything but Windows, you'll soon have to jailbreak
even laptops and desktop PC's?

Naah, we're perfectly safe, like every other similar attempt after 5-10 years
of effort and several hundred million dollars down the drain it'll come to
nothing.  I guess that's one silver lining of the corollary to We can't
secure PCs against the bad guys, which is We can't 'secure' them against
their owners either (with the rider ... although we can cause a lot of cost
and inconvenience in trying).

Peter.

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


Re: Fw: [IP] Malware kills 154

2010-08-23 Thread Peter Gutmann
Perry E. Metzger pe...@piermont.com forwards:

 Authorities investigating the 2008 crash of Spanair flight 5022
 have discovered a central computer system used to monitor technical
 problems in the aircraft was infected with malware

 http://www.msnbc.msn.com/id/38790670/ns/technology_and_science-security/?gt1=43001

Sigh, yet another attempt to use the dog ate my homework of computer
problems, if their fly-by-wire was Windows XP then they had bigger things to
worry about than malware.

Peter.

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


RE: Has there been a change in US banking regulations recently?

2010-08-15 Thread Peter Gutmann
Ray Dillinger b...@sonic.net writes:
On Fri, 2010-08-13 at 14:55 -0500, eric.lengve...@wellsfargo.com wrote:

 The big drawback is that those who want to follow NIST's recommendations
 to migrate to 2048-bit keys will be returning to the 2005-era overhead.
 Either way, that's back in line with the above stated 90-95% overhead.
 Meaning, in Dan's words 2048 ain't happening.

I'm under the impression that 2048 keys are now insecure mostly due to
advances in factoring algorithms 

Insecure against what?  Given the million [0] easier attack vectors against
web sites, which typically range from trivial all the way up to relatively
easy, why would any rational attacker bother with factoring even a 1024-bit
key, with a difficulty level of quite hard?  It's not as if these keys have
to remain secure for decades, since the 12-month CA billing cycle means that
you have to refresh them every year anyway.  Given both the state of PKI and
the practical nonexistence of attacks on crypto of any strength because it's
not worth the bother, would the attackers even notice if you used a 32-bit RSA
key?  How would an adversary effectively scale and monetise an attack based on
being able to break an RSA key, even if it was at close to zero cost?

The unfortunate effect of such fashion-statement crypto recommendations as
you must use 2K bit keys, regardless of the threat environment is that what
it actually says is you must not use SSL on your web site.  Le mieux est
l'ennemi du bien strikes again.

Peter.

[0] Figure exaggerated slightly for effect.

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


Has there been a change in US banking regulations recently?

2010-08-13 Thread Peter Gutmann
As part of a thread on another list, I noticed that Bank of America, who until
recently didn't bother protecting the page where users are expected to enter
their credentials with anything more substantial than a GIF of a padlock, now
finally use HTTPS on their home page, and redirect HTTP to HTTPS (this only
took them, what, about ten years to get right?  Or is it fifteen?  When did
BofA first get a web presence?).  Wachovia now do it too.  And Citibank at
least redirect you to an HTTPS page.  And so does US Bank, after asking for
your ID.

What on earth happened?  Was there a change in banking regulations in the last
few months?

Peter.

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


Re: A mighty fortress is our PKI, Part II

2010-08-11 Thread Peter Gutmann
Thor Lancelot Simon t...@rek.tjls.com writes:

If you want to see a PKI tragedy in the making, have a look at the CRLs used
by the US DoD.

Only in the making?

Actually it's all relative, in Japan the Docomo folks turned off CRLs because
they found that even a relatively modest CRL (not just the DoD monsters)
presented a nice DoS when sent over cellular data links.  What happened was
that as the CRLs grew, performance got worse and worse as the phone downloaded
the CRL.  It took them quite some time to diagnose that they were being DoS'd
by their own PKI.

Peter.

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


Re: A mighty fortress is our PKI, Part II

2010-08-05 Thread Peter Gutmann
David-Sarah Hopwood david-sa...@jacaranda.org writes:

Huh? I don't understand the argument being made here.

It's a bogus argument, the text says:

  He took a legitimate software package and removed the signature of the
  digital certificate it contained, then installed the package on his
  computer. The Installer application didn't indicate that the certificate had
  been modified.

The certificate wasn't modified, they just stripped the signature from the
executable.

  Only an expert will be able to detect a problem, Schouwenberg said. And
  all Microsoft will tell you is that the file is not signed.

And what else should Windows say?  We put this through our time machine and
noticed that at some time in the past it was signed and now it isn't?

The rest of the story isn't much better:

  The Stuxnet worm, which surfaced last month, used fake Verisign digital
  certificates

No, they were genuine certs, just in the wrong hands.

Peter.

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


Re: A mighty fortress is our PKI, Part II

2010-08-05 Thread Peter Gutmann
Jon Callas j...@callas.org writes:

But S.J. Perleman's Three Shares in a Boat

Uhh. minor nitpick, it was Jerome K.Jerome who wrote Three Shares in a Boat. 
He followed it up with Three Certificates on the Bummel, a reference to the 
sharing of commercial vendors' code-signing keys with malware authors.

Peter.

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


Preventing a recurrence of the Realtek/JMicron fiasco

2010-08-05 Thread Peter Gutmann
I've been having an off-list discussion with someone about how you'd prevent
the recent Realtek/JMicron certificate fiasco.  My thoughts on this:

  Since many development shops see the signing process as nothing more than an
  annoying speed-bump that stands in the way of application deployment, not
  helped by the fact that code-signing tools like Windows SignTool and Unix'
  GPG are hard to use and poorly integrated into the development process,
  developers have generally used the most expedient means possible to sign
  their code, with signing keys left unprotected or with easy-to-guess
  passwords (trivial variations of password are a favourite in web advice
  columns that give examples of how to do code signing [0]), or passwords
  hard-coded into the scripts that are needed in order to integrate the
  signing into the build process.  Combine this with the existence of entire
  families of malware such as Adrenalin, Nuklus/Apophis, Ursnif, and Zeus that
  integrate key-stealing functionality and it's inevitable that legitimate
  code-signing keys will end up in the hands of malware authors.

  [0] p...@ssw0rd is the password1 of code signing.

So my advice would be to keep the signing key on a dedicated, non-network-
connected machine that takes to-be-signed input from a USB drive with autorun
turned off (or, better, Didier Stevens' USB-protection driver installed,
http://blog.didierstevens.com/programs/ariad/) and sign that.  For test
purposes during development you can always sign with test keys, and then only
sign the final release once it's passed QA.  Even if you don't want to go that
far, just getting rid of the current worst practice would be a start, where
code-signing keys are just random data to be copied onto every developer's
machine with no password or a fixed password coded into batch files.

Potential issues/discussion topics:

- The signing tools should include a test key along the lines of the EICAR
  test virus sig. that's included by default and recognised everywhere as
  being purely a test key, to create a zero-overhead way of leaping the
  signing hurdle during development.

- As an extension of the above, the development environment should have some
  checkbox option to test-sign debug builds of binaries so developers don't
  have to google + cutpaste obscure command-line strings and batch files into
  equally obscure config dialogs in their IDE.

- Developers may need to repeatedly sign test releases and beta releases.  How
  do you distinguish signature for testing purposes from signature for live
  release?  Pretty much anything you do, e.g. throw up a warning every time a
  test-signed version is run, is going to cause enough discomfort eventually
  that developers will go back to using the release key.

Any other issues that anyone can think of?

Peter.

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


Using file-hiding rootkits for good

2010-08-03 Thread Peter Gutmann
I recently came across an example of a file-hiding rootkit for Windows that's
used for good instead of evil: It's a minifilter that hides (or at least
blocks, the files are still visible) access to executables on removable media,
with user-configurable options to block autorun.inf and/or all executables, as
well as making files on the media non-executable (although you could still map
them into memory and then execute them from there if you really wanted to).
This is a neat idea, since it stops a pile of exploits that take advantage of
the autorun capability.  More at http://blog.didierstevens.com/programs/ariad/.

Peter.

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


Re: Is this the first ever practically-deployed use of a threshold scheme?

2010-08-02 Thread Peter Gutmann
Jerry Leichter leich...@lrw.com writes:

One could certainly screw up the design of a recovery system, but one  
would have to try.  There really ought not be that much of difference  
between recovering from m pieces and recovering from one.

There's a *huge* difference, see my previous posting on this the last time the 
topic came up, 
http://www.mail-archive.com/cryptography@metzdowd.com/msg07671.html:

  the cognitive load imposed is just so high that most users can't cope with 
  it, particularly since they're already walking on eggshells because they're 
  working on hardware designed to fail closed (i.e. lock everything out) if 
  you as much as look at it funny.

The last time I went through this exercise for a high-value key, after quite 
some time going through the various implications, by unanimous agreement we 
went with lock an encrypted copy in two different safes (this was for an 
organisation with a lot of experience with physical security, and their threat 
assessment was that anyone who could compromise their physical security would 
do far more interesting things with the capability than stealing a key).

For the case of DNSSEC, what would happen if the key was lost?  There'd be a 
bit of turmoil as a new key appeared and maybe some egg-on-face at ICANN, but 
it's not like commercial PKI with certs with 40-year lifetimes hardcoded into 
every browser on the planet is it?  Presumably there's some mechanism for 
getting the root (pubic) key distributed to existing implementations, could 
this be used to roll over the root or is it still a manual config process for 
each server/resolver?  How *is* the bootstrap actually done, presumably you 
need to go from no certs in resolvers to certs in resolvers through some 
mechanism.

Peter.

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


Re: Is this the first ever practically-deployed use of a threshold scheme?

2010-08-02 Thread Peter Gutmann
Jerry Leichter leich...@lrw.com writes:

Here's how I would do it:  Key segments are stored on USB sticks. There's a
spot on the device with m USB slots, two buttons, and red and green LED's.
You put your USB keys into the slots and push the first button.  If the red
LED lights - you don't have enough sticks, or they aren't valid.  If the
green LED lights, you have a valid key. If the green LED lights, you push the
second button (which is otherwise disabled), and the device loads your key.

That's a good start, but it gets a bit more complicated than that in practice
because you've got multiple components, and a basic red light/green light
system doesn't really provide enough feedback on what's going on.  What you'd
need in practice is (at least) some sort of counter to indicate how many
shares are still outstanding to recreate the secret (We still need two more
shares, I guess we'll have to call Bob in from Bratislava after all).  Also
the UI for recreating shares if one gets lost gets tricky, depending on how
much metadata you can assume if a share is lost (e.g. We've lost share 5 of
7 vs. We've lost one of the seven shares), and suddenly you get a bit
beyond what the UI of an HSM is capable of dealing with.

With a two-share XOR it's much simpler, two red LEDs that turn green when the
share is added, and you're done.  One share is denoted 'A' and the other is
denoted 'B', that should be enough for the shareholder to remember.

If you really wanted to be rigorous about this you could apply the same sort
of analysis that was used for weak/stronglinks and unique signal generators to
see where your possible failure points lie.  I'm not sure if anyone's ever
done this [0], or whether it's just build in enough redundancy that we should
be OK.

Peter.

[0] OK, I can imagine scenarios where it's quite probably been done, but
anyone involved in the work is unlikely to be allowed to talk about it.

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


Re: Is this the first ever practically-deployed use of a threshold scheme?

2010-08-01 Thread Peter Gutmann
Thierry Moreau thierry.mor...@connotech.com writes:

With the next key generation for DNS root KSK signature key, ICANN may have
an opportunity to improve their procedure.

What they do will really depend on what their threat model is.  I suspect that
in this case their single biggest threat was lack of display of sufficient
due diligence, thus all the security calisthenics (remember the 1990s Clipper
key escrow procedures, which involved things like having keys generated on a
laptop in a vault with the laptop optionally being destroyed afterwards, just
another type of security theatre to reassure users).  Compare that with the
former mechanism for backing up the Thawte root key, which was to keep it on a
floppy disk in Mark Shuttleworth's sock drawer because no-one would ever look
for it there.  Another example of this is the transport of an 1894-S dime
(worth just under 2 million dollars) across the US, which was achieved by
having someone dress in somewhat grubby clothes and fly across the country in
cattle class with the slabbed coin in his pocket, because no-one would imagine
that some random passenger on a random flight would be carrying a ~$2M coin.
So as this becomes more and more routine I suspect the accompanying
calisthenics will become less impressive.

(What would you do with the DNSSEC root key if you had it?  There are many 
vastly easier attack vectors to exploit than trying to use it, and even if you 
did go to the effort of employing it, it'd be obvious what was going on as 
soon as you used it and your fake signed data started appearing, c.f. the 
recent Realtek and JMicron key issues.  So the only real threat from its loss 
seems to be acute embarassment for the people involved, thus the due-diligence 
exercise).

Peter.

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


Is this the first ever practically-deployed use of a threshold scheme?

2010-07-31 Thread Peter Gutmann
Apparently the DNS root key is protected by what sounds like a five-of-seven
threshold scheme, but the description is a bit unclear.  Does anyone know
more?

(Oh, and for people who want to quibble over practically-deployed, I'm not
 aware of any real usage of threshold schemes for anything, at best you have
 combine-two-key-components (usually via XOR), but no serious use of real n-
 of-m that I've heard of.  Mind you, one single use doesn't necessarily count
 as practically deployed either).

Peter (who has two more Perry-DoS-ing conversation-starter posts to make, but
   will leave them for awhile now :-).

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


Re: Five Theses on Security Protocols

2010-07-31 Thread Peter Gutmann
Perry E. Metzger pe...@piermont.com writes:

Inspired by recent discussion, these are my theses, which I hereby nail upon
the virtual church door:

Are we allowed to play peanut gallery for this?

1 If you can do an online check for the validity of a key, there is no
  need for a long-lived signed certificate, since you could simply ask
  a database in real time whether the holder of the key is authorized
  to perform some action.

Based on the ongoing discussion I've now had, both on-list and off, about
blacklist-based key validity checking [0], I would like to propose an
addition:

  The checking should follow the credit-card authorised/declined model, and
  not be based on blacklists (a.k.a. the second dumbest idea in computer
  security, see
  http://www.ranum.com/security/computer_security/editorials/dumb/).

(Oh yes, for a laugh, have a look at the X.509 approach to doing this.  It's
eighty-seven pages long, and that's not including the large number of other
RFCs that it includes by reference: http://tools.ietf.org/html/rfc5055).

 The signed certificate is completely superfluous.

This is, I suspect, the reason for the vehement opposition to any kind of
credit-card style validity checking of keys, if you were to introduce it, it
would make both certificates and the entities that issue them superfluous.

Peter.

[0] It's kinda scary that it's taking this much debate to try and convince
people that blacklists are not a valid means of dealing with arbitrarily
delegatable capabilities.

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


Re: A mighty fortress is our PKI

2010-07-30 Thread Peter Gutmann
Paul Tiemann paul.tiemann.use...@gmail.com writes:

What if... Firefox (or other) could introduce a big new feature (safety
controls) and ask you up front: Do you want to be safer on the internet?

The problem is that neither the browser vendor nor the users will see it like
this.  For the user its:

  Do you want to have lots of sites that you normally use break?

For the browser vendor its:

  Do you want lots of your users to become frustrated when things stop
  working for them so that they switch to another browser?

Is there a good reason Firefox and other browsers shouldn't just get tough
about [various sensible security measures]

None of the non-IE browsers can afford to do this because people will just
switch back to IE, and this has been observed in usability testing of proposed
browser security features by HCI researchers, as soon as anything goes wrong
the users switch back to IE, which allows pretty much anything through.  You
can even get IE as a plugin for other browsers (shudder) in order to make
things work.

So you'd need to get the change made in IE (or at least get it made in such a
manner that fallback-to-IE is no longer an option).  I don't know what size
hammer you'd need to wield in order to get that done.

This isn't true for all OCSP services.  For example, DigiCert's is not CRL
based, so it really can say Yes

It can't say yes because the only thing OCSP can say is not revoked (and
in more general terms the only thing a blacklist can say is not on the
blacklist).  Not revoked doesn't mean valid, it just means not in the
blacklist.

and it really can say Unknown meaningfully.

Unknown is generally treated by client apps as good, because if revoked
maps to bad then anything else must map to good (OCSP's muddle of non-
orthogonal response types is yet another perpetual motion-machine debate topic
among PKI people).

It might not be hard to determine whose OCSP responders are CRL based and
whose are database backed instead.

How can you do this?  Note that the various timestamps in OCSP responses are
as big a mess as the rest of OCSP, and can't be relied upon for any decision-
making.

More importantly, how can you possibly make any meaningful decisions in time-
critical protocols based on a system for which your responses can have come
from any time in the past?  As one security architect commented some years
ago, learning in 80ms that the certificate was good as of a week ago and to
not hope for fresher information for another week seems of limited, if any,
utility to us or our customers.

The problem here is best seen by looking at certificates as capabilities.

1. You have an abitrary and unknown number of capabilities floating around out
   there.

2. Some of those capabilities (CA certs) have the ability to mint new
   capabilities.

2a. These capabilities can impersonate existing capabilities, and because of
(1) the real issuer of the capabilities has no idea that they exist.

And the means of dealing with these unknown numbers of arbitraily-identified
capabilities is... a blacklist.

There's no way this can possibly, ever work.  It's the 1960s credit-card model
that Perry mentioned with the added twist that there are an unknown number of
cards and issuers involved, and some of the cards can invent new cards
whenever they feel like it.

Peter.

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


Re: A mighty fortress is our PKI, Part II

2010-07-30 Thread Peter Gutmann
Steven Bellovin s...@cs.columbia.edu writes:

When I look at this, though, little of the problem is inherent to PKI.
Rather, there are faulty communications paths.

Oh no my Lord, I assure you that parts of it are excellent! :-).

[...] how should the CA or Realtek know about the problem? [...]

That was the whole point, that the whole system doesn't work, and it's the 
system as a whole that has to work, not just some parts of it.  Here's another 
description, without the possibly confusing 't +/- x' stuff:

Shortly after the malware appeared (or at least got noticed) it was added to
anti-virus vendor databases and pushed out to users via updates.  Some time
later when it made headlines because of its use of the Realtek certificate,
the CA that had issued it read about it in the news, contacted the certificate
owner, and revoked it.  However due to the dysfunctional nature of revocation
handling, the certificate was still regarded as valid by Windows systems after
it had been revoked, and of a range of machines running Windows 7, Vista, and
XP, all with the latest updates and hotfixes applied and with automatic
updates turned on, the first machine to notice the revocation and treat the
signature as invalid didn't do so until a full week after the revocation had
occurred, and some machines still regard the signature as valid even now (I've
heard this before a number of times in software developer forums and mailing
lists, plaintive complaints from users to the effect that I know this
certificate is revoked, but no matter what I do I can't get the software to
stop using it!).

So while PKI and code-signing promise the user a fairly deterministic series
of events in which A occurs, the B occurs, then C occurs, and then the user is
safe, what actually happens in practice is that A occurs, then a comedy of
errors ensues [0], and then the user is still unsafe while possibly being
under the mistaken impression that they're actually safe.

[0] I've never understood why this is a comedy of errors, it seems more like
a tragedy of errors to me.

A real-world demonstration of the relative effectiveness of various protection
mechanisms occurred when I wanted to evaluate the ability of code-signing to
protect users.  A researcher sent me a copy of the signed malware (thanks!),
and because of its nature encrypted it with AES using the RAR archiver.
Because RAR (and indeed most other archivers) don't protect file metadata, the
message was blocked by email scanners that identified the overall contents
from the metadata even though the file contents themselves were encrypted.
After some discussion with the IT people (yes, I am certain what the file is,
it's a rather nasty piece of Windows malware, and I trust the sender to have
sent me malware) they forwarded the email to the PowerPC Linux machine on
which I read email, and which is rather unlikely to be affected by x86 Windows
malware.

Unfortunately I never could check it on the Windows system that I wanted to
test it on because the instant it appeared on there the resident malware
protection activated and deleted it again, despite various attempts to bypass
the protection.  Eventually I got it onto a specially-configured Windows
system, which reported that both the signature and its accompanying
certificate were valid (this is now two weeks after the CA had declared the
certificate revoked).  So it actually proved quite difficult to see just how
ineffective PKI and code-signing actually was in protecting users from malware
because the real protection mechanisms were so effective at doing their job.

(It's also rather an eye-opener about the effectiveness, at least in some
cases, of malware-protection software, no matter what I did I couldn't get the
malware files onto a Windows PC in order to have the code-signing declare them
valid and, by implication, perfectly safe).

What's interesting here is the claim that AV companies could respond much
faster.

I'd say it's more than just a claim, the malware was first detected around 1
1/2 months ago and added to AV vendor databases, a full month later the
certificate was declared revoked by the CA, and currently the majority of
Windows systems still regard the signature as valid (I've had a report from
someone else of one machine that records it as revoked, so at least one
machine has been belatedly protected by the code signing, assuming the user
doesn't just click past the warning as pretty much all of them will).

So yes, I'd say the AV companies respond a helluva lot faster, and a helluva
lot more effectively. The bigger lesson, for people who ever believed this to
be the case, is don't rely on code signing to protect you from malware.

Peter.

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


Re: A mighty fortress is our PKI, Part II

2010-07-28 Thread Peter Gutmann
Ben Laurie b...@links.org writes:
On 24/07/2010 18:55, Peter Gutmann wrote:
 - PKI dogma doesn't even consider availability issues but expects the
   straightforward execution of the condition problem - revoke cert.  For a
   situation like this, particularly if the cert was used to sign 64-bit
   drivers, I wouldn't have revoked because the global damage caused by that 
 is
   potentially much larger than the relatively small-scale damage caused by 
 the
   malware.  So alongside too big to fail we now have too widely-used to
   revoke.  Is anyone running x64 Windows with revocation checking enabled 
 and
   drivers signed by the Realtek or JMicron certs?

One way to mitigate this would be to revoke a cert on a date, and only reject 
signatures on files you received after that date.

This wouldn't make any difference, except for the special case of x64, 
signatures are only verified on install, so existing installed code isn't 
affected and anything new that's being installed is, with either form of 
sig-checking.

In any case though the whole thing is really a moot point given the sucking 
void that is revocation-handling, the Realtek certificate was revoked on the 
16th but one of my spies has informed me that as of yesterday it was still 
regarded as valid by Windows.  Previous experience with revoked certs has been 
that they remain valid more or less indefinitely (which would be really great 
if CAs offered something like domain-tasting for certs, you could get as many 
free certs as you wanted).

The way to revoke a cert for signed malware is to wait 0-12 hours for the 
malware signature to be added to AV databases, not to actually expect PKI to 
work.

Peter.

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


Re: A mighty fortress is our PKI, Part II

2010-07-28 Thread Peter Gutmann
Ben Laurie b...@links.org writes:

I find your response strange. You ask how we might fix the problems, then you 
respond that since the world doesn't work that way right now, the fixes won't 
work. Is this just an exercise in one-upmanship? You know more ways the world 
is broken than I do?

It's not just that the world doesn't work that way now, it's quite likely that 
it'll never work that way (for the case of PKI/revocations mentioned in the 
message, not the original SNI).  We've been waiting for between 20 and 30 
years (depending on what you define as the start date) for PKI to start 
working, and your reponse seems to indicate that we should wait even harder.  
If I look at the mechanisms we've got now, I can identify that commercial PKI 
isn't helping, and revocations aren't helping, and work around that.  I'm 
after effective practical solutions, not just a solution exists, QED 
solutions.

Peter.

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


Re: A mighty fortress is our PKI, Part II

2010-07-28 Thread Peter Gutmann
Steven Bellovin s...@cs.columbia.edu writes:

For the last issue, I'd note that using pki instead of PKI (i.e., many 
different per-realm roots, authorization certificates rather than identity 
certificates, etc.) doesn't help: Realtek et al. still have no better way or 
better incentive to revoke their own widely-used keys.

I think the problems go a bit further than just Realtek's motivation, if you 
look at the way it's supposed to work in all the PKI textbooks it's:

  Time t: Malware appears signed with a stolen key.
  Shortly after t: Realtek requests that the issuing CA revoke the cert.
  Shortly after t': CA revokes the cert.
  Shortly after t'': Signature is no longer regarded as valid.

What actually happened was:

  Time t: Malware appears signed with a stolen key.
  Shortly after t: Widespread (well, relatively) news coverage of the issue.

  Time t + 2-3 days: The issuing CA reads about the cert problem in the news.
  Time t + 4-5 days: The certificate is revoked by the CA.
  Time t + 2 weeks and counting: The certificate is regarded as still valid by
the sig-checking software.

That's pretty much what you'd expect if you're familiar with the realities of 
PKI, but definitely not PKI's finest hour.  In addition you have:

  Time t - lots: Stuxnet malware appears (i.e. is noticed by people other than
the victims)
  Shortly after t - lots: AV vendors add it to their AV databases and push out
updates

(I don't know what lots is here, it seems to be anything from weeks to
months depending on which news reports you go with).

So if I'm looking for a defence against signed malware, it's not going to be 
PKI.  That was the point of my previous exchange with Ben, assume that PKI 
doesn't work and you won't be disappointed, and more importantly, you now have 
the freedom to design around it to try and find mechanisms that do work.

Peter.

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


Re: A mighty fortress is our PKI

2010-07-28 Thread Peter Gutmann
Paul Tiemann paul.tiemann.use...@gmail.com writes:

I like the idea of SSL pinning, but could it be improved if statistics were 
kept long-term (how many times I've visited this site and how many times it's 
had certificate X, but today it has certificate Y from a different issuer and 
certificate X wasn't even near its expiration date...)

That's the key-continuity model, which has been proposed a number of times for 
Firefox, for example here's a discussion by a FF developer from over two years 
ago on this, http://blog.johnath.com/2008/04/16/security-ui-in-firefox-3plus1/ 
(that's specific to FF, I don't know what the IE, Opera, Safari, ... guys talk 
about).  There's no sign of it gaining any traction.

I hate to be the perpetual wet blanket here but the problem isn't a lack of 
ideas (many backed by extensive real-world research) but a lack of motivation 
in browsers to change the security mechanisms and UI, most of which have 
remained essentially unchanged (except for cosmetic rearrangement of the 
chrome every release or so) since the debut of SSL in 1995.  That's the 
mastodon in the room, we can debate ideas pretty much forever but if no 
browser vendor is interested in adopting any of them it isn't going to help 
secure users.

(Having said that, it's fun to throw around ideas, so I'm not complaining 
about that bit).

Peter.

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


Re: A mighty fortress is our PKI, Part II

2010-07-28 Thread Peter Gutmann
Nicolas Williams nicolas.willi...@oracle.com writes:

Exactly.  OCSP can work in that manner.  CRLs cannot.

OCSP only appears to work in that manner.  Since OCSP was designed to be 100% 
bug-compatible with CRLs, it's really an OCQP (online CRL query protocol) and 
not an OCSP.  Specifically, if I submit a freshly-issued, valid certificate to 
an OCSP responder and ask is this a valid certificate then it can't say yes, 
and if I submit an Excel spreadsheet to an OCSP responder and ask is this a 
valid certificate then it can't say no.  It takes quite some effort to design 
an online certificate status protocol that's that broken.

(For people not familiar with OCSP, it can't say yes because a CRL can't say 
yes either, all it can say is not on the CRL, and it can't say no for 
the same reason, all it can say is not on the CRL.  The ability to say 
vslid certificate or not valid certificate was explicitly excluded from 
OCSP because that's not how things are supposed to be done).

Peter.

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


Re: A mighty fortress is our PKI, Part II

2010-07-28 Thread Peter Gutmann
Nicolas Williams nicolas.willi...@oracle.com writes:

Sorry, but this is wrong.  The OCSP protocol itself really is an online
certificate status protocol.  

It's not an online certificate status protocol because it can provide neither
a yes or a no response to a query about the validity of a certificate.

(For an online status protocol I want to be able to submit a cert and get back
a straight valid/not valid response, exactly as I can for credit cards with
their authorised/declined response.  Banks were doing this twenty years ago
with creaky mainframes over X.25 and (quite probably) wet bits of string, but
we still can't do this today with multicore CPUs and gigabit links if we're
using OCSP).

Responder implementations may well be based on checking CRLs, but they aren't
required to be.

They may be, or they may not be, but you as a relying party have no way of 
telling.  OCSP covers not only the three incompatible business models of the 
different authors' employers but, for good measure, an extra anything else 
you may care to do option if the first three aren't enough.  A decade after 
it was published, PKI experts are still arguing over what various bits of the 
OCSP spec actually mean (the PKIX list has only just gone through yet another 
round of this... *ten years* later and domain experts still can't agree on how 
it's supposed to work).  So given the schizophrenic nature of the RFC you can 
easily claim but you can do X because chances are if you read it just right 
you probably can.  Unfortunately this doesn't give a relying party much to 
rely on, because they have absolutely no idea what they're getting, it could 
be anything from a live database query to a value from a month-old CRL to 
(thanks to the removal of nonces from the protocol a few years ago) an 
attacker replaying an old not-revoked value (although I don't know why 
they'd even bother with that, given the state of revocation checking in client 
software).

In any event though since OCSP can't say yes or no, it doesn't matter whether 
the response is coming from a live database or a month-old CRL, since it's 
still a fully CRL-bug-compatible blacklist I can trivially avoid it with a 
manufactured-cert attack.

Peter.

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


Re: A mighty fortress is our PKI

2010-07-27 Thread Peter Gutmann

Paul Tiemann paul.tiemann.use...@gmail.com writes:

[...]

This is kind of a long message to reply to so I'll just post a meta-reply to
avoid getting bogged down in nitpicking, the message, as the subject line
indicated, was intended to start a discussion on some of the weaknesses
inherent in the SSL and commercial PKI model.  I consciously worded it to
avoid mentioning any CA names, and only mentioned Edgecast because it was
impossible not to (I had to provide a URL for the cert), and even then
included a disclaimer that it wasn't a criticism of Edgecast.  I actually
agree with a lot of the points made in the response, since this wasn't a
failing of Edgecast or a CA but a problem in the way SSL's PKI (or more
generally just PKI as a whole) works.  Because it was designed for the
purposes of authenticating a single user to the global X.500 directory it
really doesn't have any provision for Sybil certs (I'm going to keep calling
them that because we need some sort of label for them :-).

The intent with posting it to the list was to get input from a collection of
crypto-savvy people on what could be done.  The issue had previously been
discussed on a (very small) private list, and one of the members suggested I
post it to the cryptography list to get more input from people.  The follow-up
message (the Part II one) is in a similar vein, a summary of a problem and
then some starters for a discussion on what the issues might be.

So a general response to the several well, what would you do? questions is
I'm not sure, that's why I posted this to the list.  For example should an
SSL cert be held to higher standards than the server it's hosted on?  In other
words if it's easier to compromise a CDN host or (far more likely) a web app
on it, does it matter if you're using a Sybil cert?  I have no idea, and I'm
open to arguments for and against.

I've spoken with my contacts at Edgecast, and they expressed that they're
very willing to consider alternate approaches.

I'm not actually sure what the fix would be for this, or even if there is a
fix that needs to be made.  Thus the hope to get it discussed on the list.

(Oh, and a comment on the XS* bit, that was based on an earlier off-list
discussion on messing with Firefox' same-origin policy protection mechanism
and isn't relevant here, the real issue is the more obvious one of a single
cert acting for large numbers of totally unrelated domains with very different
security requirements).

Peter.

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


Re: A mighty fortress is our PKI

2010-07-27 Thread Peter Gutmann
Ian G i...@iang.org writes:

**  But talking about TLS/SNI to SSL suppliers is like talking about the
lifeboats on the Titanic ... we don't need it because SSL is unsinkable.

... or talking to PKI standards groups about adding a CRL reason code for
certificate issued in error (e.g. to an imposter).  This was turned down
because CA's never make mistakes, so there's no need to have such a reason
code.

Peter.

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


A mighty fortress is our PKI, Part II

2010-07-25 Thread Peter Gutmann
Have you ever wondered what would happen if malware started appearing that was
authenticated by signing keys belonging to major hardware or software vendors?
Over the last week or two we've had a chance to find out:

One of the scariest scenarios for code signing is when the malware authors
manage to get their hands on a legitimate developer's code-signing key.  Since
many development shops see the signing process as nothing more than an
annoying speedbump that stands in the way of application deployment, not
helped by the fact that code-signing tools like Windows SignTool and Unix' GPG
are hard to use and poorly integrated into the development process, developers
have generally used the most expedient means possible to sign their code, with
signing keys left unprotected or with easy-to-guess passwords (password is a
favourite in web advice columns that give examples of how to do code signing),
or passwords hard-coded into the scripts that are needed in order to integrate
the signing into the build process.  Combine this with the existence of entire
families of malware such as Adrenalin, Nuklus/Apophis, Ursnif, and Zeus, with
key-stealing functionality and it's inevitable that legitimate code-signing
keys will end up in the hands of malware authors.

The most serious case of this occurred in mid-2010 when malware signed with a
key belonging to the major semiconductor manufacturer Realtek started to
appear [Rootkit.TmpHider, discussion thread, 12 July 2010,
http://www.wilderssecurity.com/showthread.php?p=1712134.][Signed Malware Used
Valid Realtek Certificate, Lucian Constantin, 16 July 2010,
http://news.softpedia.com/news/Signed-Malware-Used-Valid-Realtek-
Certificate-147942.shtml.].  Although PKI dogma states that a certificate
belonging to such a key should be immediately revoked, the fact that vast
numbers of Realtek drivers had already been signed by it and could now no
longer be installed without unsigned-driver warnings or, in the case of 64-bit
Windows, used at all, would no doubt have given both Realtek and the issuing
CA cause for concern.  After several days the certificate was revoked
[VeriSign working to mitigate Stuxnet digital signature theft, Steve Ragan,
21 July 2010,
http://www.thetechherald.com/article.php/201029/5921/VeriSign-working-to-
mitigate-Stuxnet-digital-signature-theft.], although the CA had to wait until
the story started to appear in news reports before they became aware of the
need for the revocation.  The decision to revoke the certificate was probably
influenced by a combination of the fact that the majority of users will simply
click through a driver install warning and that the hit-and-miss nature of
revocation checking meant that many systems would keep on using the
certificate regardless (if the certificate had only been used to sign 32-bit
code so that the worst that could happen was a warning dialog on install for
users to click past then this would have made the decision to revoke even
easier).  In any case since antivirus vendors had added the malware signature
to their scanners as soon as it was discovered, the revocation likely had
little actual effect in protecting users from harm.

A few days later a new version of the malware appeared, this time signed with
a key from another semiconductor manufacturer, JMicron [Win32/Stuxnet Signed
Binaries, Pierre-Marc Bureau, 19 July 2010,
http://blog.eset.com/2010/07/19/win32stuxnet-signed-binaries.][Another Signed
Stuxnet Binary, Sean Sullivan, 20 July 2010,
http://www.f-secure.com/weblog/archives/1993.html.][New Stuxnet-Related
Malware Signed Using Certificate from JMicron, Lucian Constantin, 20 July
2010,
http://news.softpedia.com/news/New-Stuxnet-Related-Malware-Signed-Using-
Certificate-from-JMicron-148213.shtml.].  Making the debacle even more
entertaining was the fact that one of the principal systems targeted by the
malware is a Siemens SCADA (industrial control) system that uses a hardcoded
password 2WSXcder that can't be changed because doing so causes the system
to stop working [Siemens warns users: Don't change passwords after worm
attack, Robert McMillan, 20 July 2010,
http://www.infoworld.com/d/security-central/siemens-warns-users-dont-change-
passwords-after-worm-attack-915.] and that had been circulating on the
Internet for years, including being posted to a Siemens online forum in Russia
[SCADA System.s Hard-Coded Password Circulated Online for Years, Kim Zetter,
19 July 2010, http://www.wired.com/threatlevel/2010/07/siemens-scada/.] and
online lists of default passwords [default password list,
http://www.defaultpassword.com/?action=dplchar=s.] (the reason for this poor
level of security is that SCADA systems rate availability above everything
else, so that anything that affects, or potentially affects, security is
strongly avoided.  In addition SCADA systems often use thoroughly out-of-date
hardware and software that no-one wants to change for fear of breaking things
and for which there's no way to 

Re: A mighty fortress is our PKI

2010-07-23 Thread Peter Gutmann
From an off-list discussion: Can someone who knows more about how these CDNs
handle certs provide a brief summary for the list?  From looking at Sybil
certs grabbed from a few CDN sites there doesn't seem to be any rhyme or
reason to them.  Also, how and under what conditions can you get access to the
CDN as an insider?  I'd found ads like
http://www.webhostingtalk.com/showthread.php?t=873555, Resell the Edgecast
CDN and make a killing!, which seem to imply that anyone with a chequebook
can play.

Peter.

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


Re: A mighty fortress is our PKI

2010-07-23 Thread Peter Gutmann
Looks like the CDN certificate is already causing security problems, although
not the kind that I was expecting:

  While trying to import a server certificate for a CDN service, a segv bug
  was found in [PKI app].  It is likely that this bug is exploitable by
  sending a special crafted signed message and having a user verify the
  signature.

Hmm, I wonder if this particular certificate happened to be one with 107
subjectAltName entries?

  Description

  Importing a certificate with more than 98 Subject Alternate Names via import
  command or implicitly while verifying a signature causes [...].

Yup :-).  So if nothing else it's a good stress test for your certificate-
parsing code...

Peter.

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


A mighty fortress is our PKI

2010-07-22 Thread Peter Gutmann
Readers are cordially invited to go to https://edgecastcdn.net and have a look 
at the subjectAltName extension in the certificate that it presents.  An 
extract is shown at the end of this message, this is just one example of many 
like it.  I'm not picking on Edgecast specifically, I just used this one 
because it's the most Sybilly certificate I've ever seen.  You'll find that 
this one Sybil certificate, among its hundred-and-seven hostnames, includes 
everything from Mozilla, Experian, the French postal service, TRUSTe, and the 
Information Systems Audit and Control Association (ISACA), through to 
Chainlove, Bonktown, and Dickies Girl (which aren't nearly as titillating as 
they sound, and QuiteSFW).  Still, who needs to compromise a CA when you have 
these things floating around on multihomed hosts and CDNs.

Ian Grigg pointed out that this is also an EV certificate, I'm guessing that 
CDNs and multihomed hosts run into the same system-high problem that dogged 
MLS systems in the 1980s, they have to use the certificate at the highest 
level of any of the constituent domains.  So if you compromise (say) 
inpath-static.iseatz.com (which consists of a page that says We're sorry, but 
something went wrong) or images.vrbo.com (Directory Listing Denied) then 
you have an EV-validated site.  So the overall EV security becomes that of the 
least secure co-hosted domain.

I've tried connecting to the above site with HTTPS and get a normal non-EV 
Sybil certificate even though it's rooted in an EV CA... well, pseudo-rooted, 
the root is then signed by an old Entrust certificate, and the certificate 
itself is another multi-domain one, for Delta, Amtrak, Air France, KLM, Alaska 
Air, and others.  I wonder if they have some context-specific way to override 
EV on a per-site basis when it's used with Sybil certificates?  At the moment 
it's rather hard to test because depending on where you are in the world you 
get different views of servers and certificates (for example when I connect to 
ISACA, which is an EV site, I get a standard non-Sybil certificate that's only 
valid for ISACA), and finding a particular hostname in a Sybil certificate 
doesn't mean that you'll see that particular certificate when you connect to 
the server.

(Again, not wanting to pick on ISACA here, but finding a security audit 
organisation sharing a certificate with Dickies Girl is kinda funny.  You'd 
think there'd be a security audit process to catch this :-).

What a mess!  A single XSS/XSRF/XS* attack, or just a plain config problem,
and the whole house of cards comes down.

(For the TLS folks, SNI (a client-supplied Server Name Indication when it 
 connects) won't fix this because (a) it's not widely-enough supported yet and 
 (b) the server admin would have to buy 107 separate certificates to do the 
 job that's currently done by one Sybil certificate, and then repeat this for 
 every other Sybil certificate they use).

 666 2633: SEQUENCE {
 6703:   OBJECT IDENTIFIER subjectAltName (2 5 29 17)
 675 2624:   OCTET STRING, encapsulates {
 679 2620: SEQUENCE {
 683   15:   [2] 'edgecastcdn.net'
 700   18:   [2] 'ne.edgecastcdn.net'
 720   21:   [2] 'minitab.fileburst.com'
 743   30:   [2] 'cdn.montimbrenligne.laposte.fr'
 775   27:   [2] 'zeroknowledge.fileburst.com'
 804   23:   [2] 'images.goldstarbeta.com'
 829   25:   [2] 'radialpoint.fileburst.com'
 856   19:   [2] 'wac.edgecastcdn.net'
 877   22:   [2] 'ne.wac.edgecastcdn.net'
 901   19:   [2] 'images.goldstar.com'
 922   15:   [2] 'images.vrbo.com'
 939   12:   [2] 'cdn.vrbo.com'
 953   18:   [2] 'content.truste.com'
 973   13:   [2] 'e1.boxcdn.net'
 988   13:   [2] 'e2.boxcdn.net'
1003   13:   [2] 'e3.boxcdn.net'
1018   25:   [2] 'privacy-policy.truste.com'
1045   13:   [2] 'www.sonos.com'
1060   19:   [2] 'www.dickiesgirl.com'
1081   26:   [2] 'static-cache.tp-global.net'
1109   29:   [2] 'images.homeawayrealestate.com'
1140   14:   [2] 'cdn.verint.com'
1156   13:   [2] 'swf.mixpo.com'
1171   21:   [2] 'cdn.traceregister.com'
1194   14:   [2] 's.tmocache.com'
1210   17:   [2] 's.my.tmocache.com'
1229   23:   [2] 'ne1.wpc.edgecastcdn.net'
1254   23:   [2] 'gp1.wpc.edgecastcdn.net'
1279   23:   [2] 'gs1.wpc.edgecastcdn.net'
1304   23:   [2] 'ne1.wac.edgecastcdn.net'
1329   23:   [2] 'gp1.wac.edgecastcdn.net'
1354   23:   [2] 'gs1.wac.edgecastcdn.net'
1379   24:   [2] 'c1.socialcastcontent.com'
1405   21:   [2] 'www.steepandcheap.com'
1428   22:   [2] 'www.whiskeymilitia.com'
1452   17:   [2] 'www.chainlove.com'

Re: Intel to also add RNG

2010-07-13 Thread Peter Gutmann
Paul Wouters p...@xelerance.com writes:

Which is what you should do anyway, in case of a hardware failure. I know the 
Linux intel-rng and amd-rng used to produce nice series of zeros.

Do you have any more details on this?  Was it a hardware problem, software
problem, ...?  How was it caught?

Peter.

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


Re: Fwd: Anyone make any sense out of this skype hack announcement?

2010-07-13 Thread Peter Gutmann
Christian Collberg collb...@gmail.com writes:

I don't know if the new crack reveals anything new. We have a writeup about 
the Skype protection techniques in Surreptitious Software, our book on 
security-through-obscurity. (Sorry for the blatant self-promotion).

No need to apologise, it's a damn good read.  For people not familiar with it, 
the title is a bit misleading (it sounds like a book about malware), it's 
actually a book on software obfuscation and tamperproofing, IMHO it's the 
definitive reference on the topic.

Peter.

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


Re: Intel to also add RNG

2010-07-12 Thread Peter Gutmann
Ben Laurie b...@google.com writes:
On 2 July 2010 13:19, Eugen Leitl eu...@leitl.org wrote:

http://www.technologyreview.com/printer_friendly_article.aspx?id=25670channel=Briefingssection=Microprocessors

Tuesday, June 29, 2010

Nanoscale Random Number Circuit to Secure Future Chips

Intel unveils a circuit that can pump out truly random numbers at high speed.

Have they forgotten the enormous amount of suspicion last time they tried this?

You mean rampant paranoia from a small group of people... if you are genuinely
worried about this, just use it as another input to mix into your entropy pool
(which you should be doing anyway, never trust a single source of entropy).
I'd be quite happy to use the RNG on a Loongson CPU (if there was one) in this
manner, let alone an Intel CPU.

What killed it wasn't paranoia about Intel but their almost total lack of
interest in supporting it once the initial media attention waned.  This
doesn't look any different, note that it's not saying This will be in Core2's
starting August but We've done this in the lab.

Peter.

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


Re: Question w.r.t. AES-CBC IV

2010-07-10 Thread Peter Gutmann
Ralph Holz ralph-cryptometz...@ralphholz.de writes:

CTR mode seems a better choice here. Without getting too technical, security
of CTR mode holds as long as the IVs used are fresh whereas security of CBC
mode requires IVs to be random.

Unfortunately CTR mode, being a stream cipher, fails completely if the
IV's/keys aren't fresh (as you could force them to be for SRTP under SIP by
attacking the crypto handshake that preceded it, a nice example of attacking
across a protocol boundary, taking advantage of a weakness in one protocol to
break a second), while CBC only becomes a bit less secure.  In addition CTR
mode fails trivially to integrity attacks, while with CBC it's often more
obvious (you get at least some total corruption before the self-healing takes
effect).

The problem with CTR is that, like RC4, it's very brittle, make a tiny mistake
anywhere and you're toast.

Peter.

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


Re: Question w.r.t. AES-CBC IV

2010-07-10 Thread Peter Gutmann (alt)
Ralph Holz ralph-cryptometz...@ralphholz.de writes:

CTR mode seems a better choice here. Without getting too technical, security
of CTR mode holds as long as the IVs used are fresh whereas security of CBC
mode requires IVs to be random.

Unfortunately CTR mode, being a stream cipher, fails completely if the
IV's/keys aren't fresh (as you could force them to be for SRTP under SIP by
attacking the crypto handshake that preceded it, a nice example of attacking
across a protocol boundary, taking advantage of a weakness in one protocol to
break a second), while CBC only becomes a bit less secure.  In addition CTR
mode fails trivially to integrity attacks, while with CBC it's often more
obvious (you get at least some total corruption before the self-healing takes
effect).

The problem with CTR is that, like RC4, it's very brittle, make a tiny mistake
anywhere and you're toast.

Peter.

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


Spy/Counterspy

2010-07-09 Thread Peter Gutmann (alt)
GPS tracking units that you can fit to your car to track where your kids are
taking it (or *cough* other purposes) have been around for awhile now.  It's
interesting to see that recently the sorts of places that'll sell you card
skimmers and RFID cloners have started selling miniature GPS jammers that plug
into cigarette-lighter sockets on cars (general-purposes ones using internal
batteries have been around for awhile).  In other words these are specifically
designed to stop cars from being tracked.

(Some of the more sophisticated trackers will fall back to 3G GSM-based
tracking via UMTS modems if they lose the GPS signal, it'll be interested to
see how long it takes before the jammers are updated to deal with 3G signals
as well, hopefully while leaving 2G intact for phonecalls).

Peter.

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


Re: Against Rekeying

2010-03-26 Thread Peter Gutmann (alt)
Nicolas Williams nicolas.willi...@sun.com writes:

I made much the same point, but just so we're clear, SSHv2 re-keying has been
interoperating widely since 2005.  (I was at Connectathon, and while the
details of Cthon testing are proprietary, I can generalize and tell you that
interop in this area was very good.)

Whose SSH rekeying though?  I follow the support forums for a range of non-
mainstream (i.e. not the usual suspects of OpenSSH, ssh.com, or Putty) SSH
implementations and why does my connection die after an hour with [decryption
error/invalid packet/unrecognised message type/whatever] (all signs of
rekeying issues) is still pretty much an FAQ across them at the current time.

(There's also the mass of ancient copies of the usual suspects, principally
the ssh.com implementation dating back up to ten years, baked into networking
devices and whatnot that will never be updated, or at least if significant
security holes present in the older versions haven't convinced the vendors
using them to update them then I don't think the fact that they drop the
connection after an hour will).

Peter.

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


Phone company phishes its own users

2009-11-21 Thread Peter Gutmann
There have been numerous posts to this list about banks phishing their own
users so I figured I'd start a new thread about other companies who are
potential phishing-targets doing this as well, in this case a phone company.
From the fraud-alert support forum of Vodafone:

 
http://forum.vodafone.co.nz/topic/3631-phone-call-from-vodafone-for-check-on-plan-and-confirming-contact-details-including-vf-pin-number/

  User:

  Not sure if this is genuine or not - just had a call from a blocked number
  caller saying they were from Vodafone doing a 'courtesy' call checking I'm
  happy on my plan and updating contact details. First thing they ask for is
  my Date of Birth and Vodafone pin number.  Is this genuine?

  Vodafone staff:

  I would not be giving out my date of Birth

  User:

  So thats a no to it being official then?

  Vofafone staff:

  Call was all good nothing to worry about

So next time you get a call from a caller-ID-blocked number asking for your
PIN, it's OK, it's only your phone company.

Peter.

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


Why the onus should be on banks to improve online banking security

2009-11-21 Thread Peter Gutmann
There's been a near-neverending debate about who should be responsible for
improving online banking security measures: the users, the banks, the
government, the OS vendor, ... .  Here's an interesting perspective from Peter
Benson peter.ben...@codescan.com, reposted with permission, on why the onus
should be on banks to provide appropriate security measures:

  One of the main reasons to target the banks with accountability is because
  you can. There is a lot of historical regulation and controls around
  banking, which makes it *relatively* easy to hold them to account. The
  bigger problem, and the next logical step, is how the banks hold suppliers /
  vendors of software accountable for flaws in their systems and software that
  enable the problems to occur in the first place.

  Anyone recognise the following?

  This software is provided as is, and any expressed or implied warranties,
  including, but not limited to, the implied warranties of merchantability and
  fitness for a particular purpose are disclaimed. In no event shall the
  contributors be liable for any direct, indirect, incidental, special,
  exemplary, or consequential damages (including, but not limited to,
  procurement of substitute goods or services; loss of use, data, or profits;
  or business interruption) however caused and on any theory of liability,
  whether in contract, strict liability , or tort (including negligence or
  otherwise) arising in any way out of the use of this software, even if
  advised of the possibility of such damage.

  Accountability is great, and I fully support it, and would like to somehow
  find the way to push a level of accountability back to various software
  developers / manufacturers. Unfortunately in the current state of Contract
  and Tort law, there is so much protection(ism) of the software industry,
  that its still going to be time consuming and expensive to get a couple of
  decent case studies out there or to change anything. So from a public good
  perspective, unfortunately (realistically), it is the banks that should
  carry the onus.

Peter

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


Re: Crypto dongles to secure online transactions

2009-11-21 Thread Peter Gutmann
John Levine jo...@iecc.com writes:

I told him about an approach to use a security dongle that puts the display
and confirmation outside the range of the malware, and although I thought it
was fairly obvious, he'd apparently never heard it before.

Some general thoughts on this, there have been attempts going back at least
ten years to bring devices like this to market (for example I have a nice
device that does exactly this built in the late 90s sitting in a drawer
somewhere), but they always die for the same reason, lack of interest and, for
the few who are interested, lack of interest in paying the cost.

I've made it an entry in my blog at

http://weblog.johnlevine.com/Money/securetrans.html

[...]

I don't understand why banks aren't using this approach already.

Because (apart from the reasons given above) with business use specifically
you run into insurmountable PC - device communications problems.  Many
companies who handle large financial transactions are also ones who, due to
concern over legal liability, block all access to USB ports to prevent
external data from finding its way onto their corporate networks (they are
really, *really* concerned about this).  If you wanted this to work, you'd
need to build a device with a small CMOS video sensor to read data from the
browser via QR codes and return little more than a 4-6 digit code that the
user can type in (a MAC of the transaction details or something).  It's
feasible, but not quite what you were thinking of.

Peter.

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


Interesting way of protecting credit card data on untrusted hosts

2009-09-28 Thread Peter Gutmann
A Canadian company called SmartSwipe has come up with an interesting way to
protect credit card numbers from most man-in-the-browser attacks.  What they
do is install a Windows CSP (cryptographic service provider) that acts as a
proxy to an external mag-stripe reader with built-in crypto processing, so the
CSP on the host PC does nothing more than forward data to be encrypted out to
the external device.  There's also a browser plug-in that pre-populates the
credit-card field in web forms with a cookie.  When the page is sent to the
CSP for encryption for SSL, the software running on the reader recognises the
cookie in the web-form content, reads the card data via the mag-stripe reader,
inserts it into the web-form field, and returns the encrypted result to the
host PC to forward to the remote server.  As a result, the CC data is never
present on the host PC.

The downsides are obvious: not secure against phishing (which is a killer),
only works with MSIE because of the requirement for use of a CSP (although you
could do it with Firefox as well by creating a PKCS #11 soft-token), and not
secure against page-rewrite trojans which have the web page show one thing and
do another, but it's an interesting concept.  You can find a description of
the technology under the name Dynamic SSL(tm)(c)(p), a start point is:

http://www.smartswipe.ca/en/dynamic-ssl/600-dynamic-ssl-a-practical-solution-for-endpoint-to-endpoint-encryption

Peter.

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


Re: Bringing Tahoe ideas to HTTP

2009-09-18 Thread Peter Gutmann
Alexandre Dulaunoy adu...@gmail.com writes:

On the same idea, there is an expired Internet-Draft called Link
Fingerprints :
http://www.potaroo.net/ietf/idref/draft-lee-uri-linkfingerprints/

Although the draft has expired, the concept lives on in various tools.  For
example DownThemAll for Firefox supports this.  There was some discussion
about including it into FF3, but then the draft was dropped and the FF support
never appeared, does anyone know what happened?

(The cynic in me would say it's such a simple, straightforward, easy-to-
implement idea, of course it'll never be adopted when there are things like EV
certs to be pushed instead, but who knows...).

Peter.

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


Re: [tahoe-dev] Bringing Tahoe ideas to HTTP

2009-09-18 Thread Peter Gutmann
Brian Warner war...@lothar.com writes:

From what I can tell, the Sparkle update framework (for OS-X)[1] is doing
something like what I want for firefox: the Sparkle-enabled application will
only accept update bundles which are signed by a DSA privkey that matches a
pubkey embedded in the app.

You can extend this further to make it tolerant of key loss by embedding
multiple public keys and allowing a quorum of them to replace an existing key.
So say you have five keys, you can decide that any three of them can vote out
an existing key, allowing compromised keys to be replaced and existing keys to
be rolled over.  This creates a kind of fault-tolerant PKI which does away
with the need to have a CA vouch for key replacements, once you've got the
initial keys established (for example on first install) you can recover from
anything short of a total compromise, upgrade to larger keys sizes and hashes,
and so on.

It'd be nice if Firefox could do the same. And if Firefox were to establish a
quietly-backwards-compatible convention (i.e. the hash-mark trick) for strong
URL-based authentication of HTTP resources, then other applications could
start using it too, and a significant class of current web security problems
(like the mixed-content one where an HTTPS page loads a javascript library via
HTTP) could be fixed.

See my previous post, there was an attempt made to do this in the past but it
never got anywhere.  It'd be interesting to hear the reasons why.

Peter.

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


Re: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI

2009-09-17 Thread Peter Gutmann
Kevin W. Wall kevin.w.w...@gmail.com writes:

(Obviously some of these padding schemes such as OAEP are not suitable with
symmetric ciphers. Or at least I don't think they are.)

You'd be surprised at what JCE developers will implement just because they
can, and what therefore gets used by application developers.  I've seen 
RSA-CBC used on more than one occasion.

(No, that's not a typo, RSA in CBC mode.  The app developers wondered why it
was so slow).

Peter.

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


Re: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI

2009-09-16 Thread Peter Gutmann
David Wagner d...@cs.berkeley.edu writes:

(You could replace AES-CMAC with SHA1-HMAC, but why would you want to?)

The answer to that depends on whether you need to support an existing base of
crypto software and hardware.  Even though (in this case) it's a new standard,
it still requires support from the underlying crypto libraries.  If little or
none of those do AES-CMAC yet (I don't think Windows CryptoAPI does, only very
recent versions of OpenSSL do... it's not looking good) then you'd want to
stick with HMAC-SHA1.

(Forestalling the inevitable but developers can implement AES-CMAC themselves 
from raw AES that I'm sure someone will follow up with, the target audience 
for this is web application developers, not cryptographers, so you need to 
give them something that works as required out of the box).

Peter.

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


Re: RNG using AES CTR as encryption algorithm

2009-09-14 Thread Peter Gutmann
Damien Miller d...@mindrot.org writes:

The seems unlikely, since we don't use OpenSSL for AES-CTR in OpenSSH. I
don't think OpenSSL even supports a CTR mode through its EVP API.

I first saw it reported on the Putty bugs list [0], a good place to track
interop problems with implementations since it's so widely used, which in turn
points to https://bugzilla.mindrot.org/show_bug.cgi?id=1291:

  Connections from OpenSSH_4.5p1, OpenSSL 0.9.8d 28 Sep 2006 to
  OpenSSH_4.5p1, OpenSSL 0.9.8e 23 Feb 2007 using aes256-ctr fail with
  Bad packet length.  The same problem occurs when using PuTTY 0.59 against
  the newer server.

  PuTTY users have reported this problem too, with servers on both FreeBSD and
  Linux, and with OpenSSH versions back to 4.0.

In fact it was listed as closed and resolved by, uh, one Damien Miller :-).

Peter.

[0] Meaing bugs encountered while using Putty, not necessarily bugs in
Putty.

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


Re: RNG using AES CTR as encryption algorithm

2009-09-09 Thread Peter Gutmann
David Johnston d...@deadhat.com writes:

Convincing yourself that you have implemented AES-CTR correctly usually
involves first checking that your AES-ECB is correct, then putting the output
of you counter construction into some other known good AES-CTR implementation
and comparing the results with your implementation.

I was just going to reply with a variation of this, if you're implementing a
full protocol that uses AES-CTR (or any algorithm/mode for that matter), find
other implementations that do it too and make sure that you can talk to them.
In theory everyone could end up implementing it wrong, but that's somewhat
unlikely.

(This has already caught AES-CTR implementation bugs in the past, for example
one particular version of OpenSSL 0.9.8 got AES-CTR keying wrong and it was
noticed when SSH users couldn't connect to OpenSSH servers using this mode).

Peter.

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


Re: Client Certificate UI for Chrome?

2009-09-08 Thread Peter Gutmann
Ian G i...@systemics.com writes:

If one is trying to solve the whole thing, then using the much-commented
secure-bookmarks model would do this.  Within the secure bookmark, record the
user's certificate and cache enough info on the server's cert to deal with
replacements (like, cert, name, CA).

There's a variant of this, the site-specific browser (SSB), that takes you to
(for example) your bank in a strongly sandboxed, hardened environment.  This
reduces the cognitive load on the user from a more or less impossible-to-
follow set of instructions to only ever do your banking by clicking on this
desktop icon.  This isn't by any means a general solution, but by solving for
the most common cases (your bank, Paypal, eBay, Amazon) you'd address a fairly
large chunk of the problem.  See Breaking out of the Browser to Defend
Against Phishing Attacks by Smetters and Stewart for more details on this.

Others have suggested some ideas, so I'll just add:  the problem isn't IMO
how to do it.  There are lots of good ideas.

Actually that does point out one problem, which I alluded to in my previous 
post: we have lots and lots of good ideas, but little hard data to indicate 
which ones will work and which won't, or which ones work better than others 
(although the cynical response to this might be that almost anything would 
work better than what we've got now).  Specifically, there are a pile of 
papers along the lines of here's an experiment showing that what we're doing 
now doesn't work, here's a completely new security mechanism we've invented 
that involves redesigning the browser and server authentication back-end, and 
as a side-effect here are some UI ideas to go with it.  What we don't have 
however is here's a real-world evaluation of various ideas that have been 
proposed for fixing what we already have built into browsers and servers. 
Unfortunately without this data we (including myself) are to some extent just 
people wanking around with their opinions [0].

It's also not certain how such data would be published.  Which journal or
conference would accept a paper with no new ideas in it, just a
straightforward evaluation of existing material?

Peter.

[0] A Linus quote, brought about by a discussion on the difference between OS
secheduler design and security design: the *discussion* on security seems to
never get down to real numbers. So the difference between them is simple: one
is 'hard science'. The other one is 'people wanking around with their
opinions'.

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


Re: Client Certificate UI for Chrome?

2009-09-08 Thread Peter Gutmann
Steven Bellovin s...@cs.columbia.edu writes:

Peter, I'm not sure what you mean by good enough to satisfy security geeks
vs. good enough for most purposes.  I'm not looking for theoretically good
enough, for any value of theory; my metric -- as a card-carrying security
geek -- is precisely good enough for most purposes.

Here's a real-world example of the problem I was referring to, from a
discussion with some browser developers.  We were going over the above issue -
how to use the results of usability studies to improve the browser security UI
- and I asked why, if they were aware of this work, no-one had done anything
with it.  The response was that if we implement this then attackers will use
XUL to spoof it, and because of that it's not even worth trying.  In other
words because a hypoethetical weakness existed, it wasn't even worth
attempting to improve anything.  Instead of trying to help at least some of
the people some of the time, it was better to leave everyone unprotected all
of the time.

Given the failure of all previous attempts -- who, amongst the proponents of
EV certificates, realized that attackers could and would use all-green
favicon.ico files to fool users -- I think the burden of proof is on the
proponents.

But the problem with these approaches is that they're pretty much all just
random tweaking of the same thing, aimlessly rearranging the UI elements in
the hope that eventually something will work after (as you point out) the
twenty more or less identical previous attempts have failed.  For example the
Firefox password-entry mechanism (a generic popup dialog with a gibberish
title) hasn't changed in at least ten years (possibly even longer, I can't
remember what the Netscape 2.0 one looked like any more), all that's changed
is that every major release a few new bits of flair get added to the browser
chrome.  The previous attempts aren't lots of different approaches, it's the
same failed approach tried over and over and over again, with slight
variations over time in the hope that one of them might work.

What I was advocating was trying new approaches based on ideas from UI
research, not just fiddling with the chrome in the hope that this time it'll
finally start working.

Peter.

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


Re: SHA-1 and Git (was Re: [tahoe-dev] Tahoe-LAFS key management, part 2: Tahoe-LAFS is like encrypted git)

2009-09-08 Thread Peter Gutmann
Thor Lancelot Simon t...@rek.tjls.com writes:

I think we're largely talking past one another.  As regards new horrible
problems I meant simply that if there _are_ new horrible problems_ such
that we need to switch away from SHA1 in the TLS PRF, the design mistakes
made in TLS 1.1 will make it much harder.

Well, let's move the TLS 1.2 aspect out of the discussion and look at the
underlying issues.  If you're looking at this purely from a theoretical point
of view then it's possible that the ability to use SHA-2 in the PRF is an
improvement (it may also be a step backwards since you're now relying on a
single hash rather than the dual hash used in the original design).  Since no-
one knows of any attacks, we don't know whether it's a step backwards, a step
forwards, or (most likely) a no-op.

However there's more to it than this.  Once you've got the crypto sorted out,
you need to implement it, and then deploy it.  So looking at the two options
you have:

Old: No known crypto weaknesses.
 Interoperable with all deployed implementations.
 Only one option, so not much to get wrong.

New: No known crypto weaknesses.
 Interoperable with no deployed implementations.
 Lots of flexibioity and options to get wrong.

Removing the common factors (the crypto portion) and the no-op terms
(interoperable with existing implementations) we're left with:

Old: -
New: Non-interoperable.
 Complex - Likely to exhibit security flaws (from the maxim that
   complexity is the enemy of security).

That's a rather high cost to pay just for the ability to make a crypto fashion
statement.  Even if the ability to negotiate hash algorithms had been built in
from the start, this only removes the non-interoperability but doesn't remove
the complexity issue.

As I read Ben's comments, they were _advocating_ those kinds of design
mistakes, advocating hard-wiring particular algorithms or their parameter
sizes into protocols,

You keep asserting that this is a mistake, but in the absence of any
cryptographic argument in support, and with practical arguments against it, it
looks like a feature to me.

In fact, it is radically harder to replace an entire protocol, even with a
related one, than to drop a new algorithm into an existing, properly-designed
protocol.

A properly-designed security protocol is one that's both cryptographically
sound and simple enough that it's hard to get wrong (or at least relatively
easy to get right, admittedly not necessarily the same thing).  Adding a pile
of complexity simply so you can make a crypto fashion statement doesn't seem
to be helping here.

If TLS 1.{0,1} had been designed to make the hash functions pluggagle
everywhere

... like that model of security protocol design IKEv1 was [0], then we'd have
all kinds of interop problems and quite probably security issues based on
exploitation of the unnecessary complexity of the protocol, for a net loss in
security and interoperability, and nothing gained.

Peter.

[0] Apologies to the IPsec folks on the list, just trying to illustrate the
point.

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


Re: Client Certificate UI for Chrome?

2009-09-04 Thread Peter Gutmann
Steven Bellovin s...@cs.columbia.edu writes:

This returns us to the previously-unsolved UI problem: how -- with today's
users, and with something more or less like today's browsers since that's
what today's users know -- can a spoof-proof password prompt be presented?

Good enough to satisfy security geeks, no, because no measure you take will
ever be good enough.  However if you want something that's good enough for
most purposes then Camino has been doing something pretty close to this since
it was first released (I'm not aware of any other browser that's even tried).
When you're asked for credentials, the dialog rolls down out of the browser
title bar in a hard-to-describe scrolling motion a bit like a supermarket till
printout.  In other words instead of a random popup appearing in front of you
from who knows what source and asking for a password, you've got a direct
visual link to the thing that the credentials are being requested for.  You
can obviously pepper and salt this as required (and I wouldn't dream of
deploying something like this without getting UI folks to comment and test it
on real users first), but doing this is a tractable UI design issue and not an
intractable business-model/political/social/etc problem.

Peter.

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


Re: Client Certificate UI for Chrome?

2009-08-18 Thread Peter Gutmann
James A. Donald jam...@echeque.com writes:

I cannot see how you could create a bank web page without a web application
framework (counting mod-php as a very primitive web application framework)
and scripting and a database, which scripting and database has to know who it
is is that logged in

We really are talking about completely different things here.  The scripting
and whatnot has nothing to do with TLS or TLS auth mechanisms.  The only thing
you need to care about (if you really want to go this way) is channel binding.

The information about which user, which database primary key is logged in,
has to be passed up through one layer after another and from one process to
another.

Yeah, and that's what channel binding is for.

The plumbing really is that complicated.

Only if you deliberately choose to make it so.  Read the RFCs I mentioned
earlier.

Because keep-alive usually fails for plumbing reasons, standard TLS usually
does the PKI-based non-authentication dance every page, resulting in
additional round trips, resulting in painfully bad performance for SSL web
sites

But TLS doesn't work like that.  If it did, you'd get a cert popup every time
you clicked on a link on a TLS-protected web site.  Unless you somehow manage
to flush the TLS session cache on the server (which seems unlikely unless
you're DoS'ing it) there's no additional round-trip(s), or additional anything
for that matter.

Peter.

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


Re: Client Certificate UI for Chrome?

2009-08-16 Thread Peter Gutmann
James A. Donald jam...@echeque.com writes:

[Incredibly complicated description of web scripting plumbing deleted]

We seem to be talking about competely different things here.  For a typical
application, say online banking, I connect to my bank at www.bank.com or
whatever, the browser requests my credential information, and the TLS-SRP or
TLS-PSK channel is established. That's all.  There's no web application
framework and PHP and scripting and other stuff at all, in fact I can't even
see how you'd inject this into the process.

Further, if we do the SRP dance every single page, it is a huge performance
hit, with many additional round trips. One loses about 20 percent of one's
market share for each additional round trip.

You only do it once when the TLS session is set up, it's exactly as for
standard TLS except that instead of PKI-based non-authentication you use
cryptographic mutual authentication.  How do you get an SRP exchange for every
web page?

Peter.

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


Re: Client Certificate UI for Chrome?

2009-08-11 Thread Peter Gutmann
James A. Donald jam...@echeque.com writes:

For password-authenticated key agreement such as TLS-SRP or TLS-PSK to work, 
login has to be in the chrome.

Sure, but that's a relatively tractable UI problem (and see the comment below 
on Camino).  Certificates on the other hand are an apparently intractable 
business, commercial, user education, programming, social, and technical 
problem.  I'd much rather try and solve the former than the latter.

The problem with password auth is that no browser (with the exception of 
Camino) has made even the most basic attempt to do the UI for this properly.  
In all cases the browser pops up a dialog box, unconnected to the underlying 
operation or web page, that says Gimme your password in one way or another. 
This could be coming from anywhere, the browser, Javascript on the web page, 
another web page, who knows where, but since everyone knows that passwords are 
insecure there's no point in expending any effort to try and make them 
secure, and that's been the status quo for fifteen years.

What Camino does (and it's been awhile since I played with it, so I'll qualify 
that with what I hope it still does) is roll the password-entry box down out 
of the browser menu bar in a circular motion that's both hard to spoof and 
that unmistakably ties the credential-entry request both to the web page that 
it's associated with and to the browser rather than being some floating popup 
coming from who knows where or what.  This can no doubt be nitpicked, but it's 
better than any other browser (that I've seen) does.

More generally, I can't see that implementing client-side certs gives you much 
of anything in return for the massive amount of effort required because the 
problem is a lack of server auth, not of client auth.  If I'm a phisher then I 
set up my bogus web site, get the user's certificate-based client auth 
message, throw it away, and report successful auth to the client.  The browser 
then displays some sort of indicator that the high-security certificate auth 
was successful, and the user can feel more confident than usual in entering 
their credit card details.  All you're doing is building even more substrate 
for phishing attacks.

Without simultaneous mutual auth, which -SRP/-PSK provide but PKI doesn't, 
you're not getting any improvement, and potentially just making things worse 
by giving users a false sense of security.

Peter.

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


  1   2   3   4   5   >