Re: what is GPG's #1 objective: security or anti-patent stance ( Re: on the state of PGP compatibility (2nd try))

[Peter Gutmann]

Adam Back <[EMAIL PROTECTED]> writes:

>Back in the days of pgp2.x I used to receive and send a fair proportion of
>mail encrypted with pgp; these days it is a much lower proportion, and a
>rather high proportion of those fail.  It's not like I'm using old software or
>failing to try what is reasonable to get messages to work.  Even with my
>fairly complete collection of PGP versions you saw the results.  Imagine how
>much worse it will be between people who do not upgrade frequently or take
>such defensive strategies.  So you say upgrade already.  However as I think I
>have demonstrated, I follow this strategy myself and as you can see it doesn't
>work either.

I've been in a similar situation.  Back when I was fighting our government over
crypto export controls, it was sometimes necessary to talk to journalists in a
manner which didn't give the spooks a week's advance notice about something
which they shouldn't have known about until they opened the morning paper.
This was in the days of PGP 5.x.  Some of the people I was talking with were
pretty patient, and often put up with multiple iterations of neither side being
able to decrypt the other's messages, but eventually the choice came down to
given the opposition advance notice or not having the story published at all,
and there's really not much choice there.

Now substitute "human rights group" for "journalist" and "secret police" for
"spooks" and you can see why this is a problem.  Non-commercial PGP has always
been by geeks, for geeks, with features more important than minor
considerations like usability.  Who cares if there are 146 semi-documented,
vaguely-defined command-line options, look at the algorithm choices!  If you
want to use some obscure hash algorithm which was fasionable for 2 months in
1997, you can, and who cares if it takes you half an hour, the FAQ, the
manpage, and an online search to figure out how to encrypt a file?

That's why non-commercial crypto will always struggle to find mainstream
acceptance.  Doing the crypto engine is (relatively) easy, and fun, and there
are lots of people willing to help.  Doing the UI components is dreary and
boring, and no-one is interested because they've just spotted a hash algorithm
published in the Journal of the Bratislavian Philological Society in 1978 which
they urgently need to add support for.

(Although I don't use Windows mailers, I've heard nice things about The Bat,
 http://www.ritlabs.com/the_bat/features.html, which has built-in PGP support.
 Apparently at some point Pegasus Mail, http://www.pmail.com, will have built-
 in PGP and S/MIME support as well).

Peter.

Re: all about transferable off-line ecash (Re: Brands off-linete ch)

[Peter Gutmann]

[EMAIL PROTECTED] writes:

>"Our appointed masters" at the mint are the ones who WANT us to use the "new
>currency" because it saves them money.  It's the stores and the people that
>don't use or want them.

Just as a reference point, NZ switched from paper $1 and $2 to coins vaguely
similar to the US dollar coin a few years ago without any fuss.  If the USG
simply told people the notes were being withdrawn in 12 months (or whatver),
the change should work OK.

Having used both, I *much* prefer the coins.  Being in the US and having to
handle wads of tattered, grubby $1 notes, many of which wouldn't be accepted by
vending machines because of their condition or weren't the sort of thing you'd
want to touch just before you ate the food you'd bought with them, really
showed me what I was missing with $1 coins.

Peter.

Re: Coins vs. bills

[Peter Gutmann]

Ken Brown <[EMAIL PROTECTED]> writes:

>For some reason the mention of a "Susan B Anthony" dollar stuck in my brain as
>an "Alice B Sheldon" dollar. Susan Anthony is a person who I've never heard
>of. I'm almost tempted not to find out who she is or was to preserve a nugget
>of delicious cognitive dissonance. A world in which governments put Alice
>Sheldon on the currency would be an interestingly different world from the one
>we seem to be inhabiting.

Not being from the US I have no idea who either of those two are, but that does
raise an interesting point: Maybe the reason no-one wants the coin is because
of who's on it.  Solution: Mint a coin with La Cicciolina (or whoever the US
equivalent would be) on it.  They'd be able to get rid of at least 140M of
them.

Peter.

RE: Lucky's 1024-bit post [was: RE: objectivity and factoring analysis]

[Peter Gutmann]

"Lucky Green" <[EMAIL PROTECTED]> writes:

>1) Very, very few applications, and no cryptographic libraries that I am aware
>of, that currently employ RSA perform any kind of sanity check on the size of
>the keys.

There are both applications and crypto libraries which perform fairly extensive
checking on keys.  However, it's not as simple as you describe:

- GPG and (I believe) NAI PGP perform a pile of sanity checks which among other
  things are designed to make the Klima-Rosa attack a lot more difficult to
  pull off.  This works because PGP knows it's only going to be fed keys from
  other PGP implementations, so it doesn't have to put up with the quirks and
  oddities of random software.

- CryptoAPI expects keys to be in a certain format based on its own
  public/private key blob format, and crashes if they're not.  It doesn't seem
  to do any validation of parameters, and there's even a MSKB article telling
  you how to use an RSA key with e=1 to export plaintext secret keys (!!).
  This is the opposite end of the scale from the GPG/PGP approach.

- For crypto libraries, which have to be able to accept keys from all sorts of
  weird sources, it's difficult to get it right.  For example I perform a pile
  of checks on RSA keys (n = p * q, ( d * e ) mod p-1 == 1 and ( d * e ) mod
  q-1 == 1, ( q * u ) mod p == 1, etc [0], the standard stuff from the Klima-
  Rosa paper) and the FIPS 186 checks on DLP keys.  As a result, I keep getting
  complaints from people whose weird keys are being rejected by my code.  My
  standard response to this is "You've got the source code, if you want to use
  strange key parameters you can change the source to allow it" (transl."If you
  want to hang yourself, the rope's over there"), but that hardly works for
  commercial products.

As a result, (most) crypto libraries will continue to allow any old garbage as
key values.  User perception is more important than security.

Peter.

[0] Speaking of RSA sanity checks, can anyone provide a sensible explanation
why OpenSSH uses e=35?  I can think of several reasons why you wouldn't
want to use this, but no sensible argument in support of it.

Re: disk encryption modes

[Peter Gutmann]

Nomen Nescio <[EMAIL PROTECTED]> writes:

>Peter Gutmann and Colin Plumb invented a simple trick which provides this
>property in conjunction with CBC or CFB modes.  We're going to encrypt/decrypt
>a disk block, which is divided into "packets" which are the cipher block size
>(64 or 128 bits).  Let P[j] mean the jth packet of plaintext in the block;
>assume there are n packets in the block. C[j] is the jth packet of ciphertext.
>
>Encryption
>
>P[n] ^= Hash(P[1..n-1], blocknum, diskID)
>Encrypt block using P[n] as IV
>
>Decryption
>
>Decrypt C[2..n] using C[1] as IV
>Decrypt C[1] using P[n] as IV
>P[n] ^= Hash(P[0..n-1], blocknum, diskID)
>
>The idea is to use P[n] as IV, first xoring in some function (doesn't have to
>be a crypto hash) of the first n-1 packets, the block number, and some disk-
>specific value.  Doing this ensures that the IV depends on all the bytes in
>the block, so a change to any byte will change the entire block.  The
>decryption doesn't have to be split into n-1 and 1 block parts as shown here,
>any division will do.

Actually it's more general that that, the reason the original implementation
used such a simple first pass was because it had to run on things like 385/25's
which weren't too fast doing two passes of encryption.  For anything more
recent, you'd do two passes of encryption, the first to build the IV and the
second to encrypt with it.  This in effect means that the first pass is a MAC
of the data (alongside encrypting it) and the second pass is pure encryption.
This gives you some nice provable security properties which Phil Rogaway and
Mihir Bellare have done some work with (see
http://www.cs.ucdavis.edu/~rogaway/papers/index.html and
http://www-cse.ucsd.edu/users/mihir/papers.html for some publications).  This
is the approach used in RFC 3211, which I'd regard as the proper (unconstrained
by having to run on a slow CPU) way to use the technique..

(I'm kinda surprised that this issue keeps coming up again and again, Colin's
 design is a general-purpose solution which works with any block cipher.  It's
 a solved problem, and has been so for about a decade).

While I'm on the topic, I'd also like to question the implicit assumption that
speed is the principal design target.  Having a lot of experience with disk
crypto on (by current standards) very slow machines, I must say that speed has
never been a problem for me.  Right now I'm doing software-based 3DES and I
can't even notice that the drive is encrypted.  Now if you're encrypting swap
and your system is thrashing I can see that you'd notice, but for the average
user who barely accesses the disk and who's running a modern OS which does
sensible buffering/cacheing, it really isn't an issue.  Far better to
concentrate on flexibility and security than to drop everything so you can
chase after this single red herring.

Peter.

Re: disk encryption modes

[Peter Gutmann]

Adam Back <[EMAIL PROTECTED]> writes:

>So if you mean the approach in 1311 you referenced below:
>
>|Key wrapping:
>| 
>|   1. Encrypt the padded key using the KEK.
>| 
>|   2. Without resetting the IV (that is, using the last ciphertext
>|  block as the IV), encrypt the encrypted padded key a second
>|  time.
>| 
>|The resulting double-encrypted data is the EncryptedKey.
>| 
>| 2.3.2 Key Unwrap
>| 
>|Key unwrapping:
>| 
>|   1. Using the n-1'th ciphertext block as the IV, decrypt the n'th
>|  ciphertext block.
>| 
>|   2. Using the decrypted n'th ciphertext block as the IV, decrypt
>|  the 1st ... n-1'th ciphertext blocks.  This strips the outer
>|  layer of encryption.
>| 
>|   3. Decrypt the inner layer of encryption using the KEK.
>
>are you sure it's not vulnerable to splicing attacks (swapping ciphertext 
>blocks around to get a partial plaintext change which recovers after a block or 
>two)?  CBC mode has this property, and this mode seems more like CBC in CBC 
>than a CBC-MACed CBC-encrypted message -- there can't be a MAC property as such 
>because there is no where to store one, so the best you could hope for is earch 
>byte of plaintext depends on each byte of ciphertext, and this is the property 
>I'm questioning based on the usual CBC splicing attacks.

It is a CBC MAC.  A CBC MAC encrypts n blocks and then takes the final output as 
the MAC.  Now look at where the IV for the second pass comes from.  It's a nice 
trick, because it works without any data expansion.

>What is Colin's design and where is it described?

Originally in a sci.crypt post of about 10 years ago, more recently (which isn't 
saying much, it was years ago) in the docs for SFS, 
http://www.cs.auckland.ac.nz/~pgut001/sfs/index.html.  Note that this is the 
speed-customised version, the version which uses two passes of encryption is in 
RFC 3211.

Peter.

Re: attack on rfc3211 mode (Re: disk encryption modes)

[Peter Gutmann]

Adam Back <[EMAIL PROTECTED]> writes:

>I can see that, but the security of CBC MAC relies on the secrecy of the
>ciphertexts leading up to the last block.  In the case of the mode you
>describe in RFC3211, the ciphertexts are not revealed directly but they are
>protected under a mode which has the same splicing attack. The splicing attack
>on "CBC MAC with leading ciphertext" works through CBC encryption, here's how
>that works:

Right.  One minor point, the IV is never zero, for disk encryption it's a
cryptographic transform of the sector number, for PWRI it's supplied by the CMS
algorithm parameter (this doesn't affect the attack).

>I would have thought this would be considered a 'break' of a non-malleable
>cipher mode as discussed for disk encryption where each bit of plaintext
>depends on each bit of ciphertext as would be the case with a secure cipher
>matching Mercy's design goals (a block cipher used in ECB mode with a
>different key per block).

Yup.  Actually the no-stored-IV encryption was never designed to be a non-
malleable cipher mode, the design goal was to allow encryption-with-IV without
having to explicitly store an IV.  For PWRI it has the additional nice feature
of avoiding collisions when you use a 64-bit block cipher, which is probably
going to be the case for some time to come even with AES around.  It was only
after all that that I noticed that the first pass was effectively a CBC-MAC,
but it didn't seem important enough to mention it in the RFC since it wasn't an
essential property (good thing I didn't :-).

>With a disk mode, unlike with RFC3211 pasword based encryption for CMS there
>is no place to store the structure inside the plaintext which may to some
>extent defend against this attack.

Even with PWRI you get at most ~32 bits of protection, and can bypass even that
if you encrypt 5 or more 64-bit blocks and mess up the second block, since the
garble will propagate to at most 4 of the 5 blocks.  The 32-bit limit was
deliberate, I was worried about dictionary attacks above all else (in fact the
first version of the wrap was a bit too paranoid in that it had no redundancy
at all, which unfortunately meant that it wasn't possible to catch incorrect
passwords.  User complaints lead to the addition of the 24-bit check value
which is enough to catch virtually all mistyped passwords but not enough to
provide more than a small reduction in the number of guesses necessary for an
attacker.  The length byte is there so an attacker can't perform an iterative
attack where they change the algorithm ID for the wrapped key to 40-bit RC4 and
brute-force it, then 56-bit DES and brute-force the 16-bit difference, then 80-
bit Skipjack, 112-bit two-key 3DES, and finally 128-bit AES.  There was another
key wrap design where this was possible).

Digressing from the original disk-sector-encryption, I'd be interested in some
debate on the requirements for password-based key wrapping.  The design goals
I used were:

  1. Resistance to dictionary/password-guessing attacks above all else.

  2. No need to use additional algorithms like hash algorithms (see the RFC for
 the rationale, to save me typing it all in again).

The reason for 1. is that provided you use a secure cipher the best approach
for an attacker is going to be a dictionary attack or similar attack on the
password used to wrap the key.  Since the wrapping key is going to be used to
protect things like long-term private keys, this is an extremely high-value
item.

Note that the immunity to key-guessing requirement is mutually exclusive with
modification-detection, since (for example) storing a SHA-1 hash would allow
you to immediately verify whether you'd found the password/key.  This is the
exact problem which PKCS #12 has, you don't need to attack the key wrap since
the MAC on the wrapped data is a much easier target.  There's another key wrap
which stores a full SHA-1 hash alongside the wrapped key (to protect against
some problems present in an earlier version of the same key wrap mechanism,
which fell to fairly trivial attacks).  This is great for integrity protection,
but terrible for security, since it allows you to verify with pretty much 100%
accuracy whether you've guessed the password.I also looked at some sort of
OAEP-like wrapping (or, more generally, a Feistel-like construct of the kind
used in OAEP), but it seemed a bit ad-hoc when used with symmetric key wrap
rather than RSA.

Does anyone have any thoughts on symmetric key wrap, and specifically the
differences between high-value and low-value (ephemeral) key wrap requirements?

General rant: It's amazing that there doesn't seem to be any published research
  on such a fundamental crypto mechanism, with the result that everyone has to
  invent their own way of doing it, usually badly.  We don't even have a decent
  threat model for this, my attempt at one for password-based key wrap may or
  may not be appropriate (well, I hope it's more or less right), but it'

Re: Edinburgh Financial Cryptography Engineering 2002 - CFP

[Peter Gutmann]

Ian Grigg <[EMAIL PROTECTED]> writes:

>Very different animal :-)  The original goal for a mixed business and law and
>accounting and a tad of crypto was perverted into YACC - yet another crypto
>conference - and became very academic, very mathematical, very crypto, very
>junior, and very ignorable.

Phew, at least I'm not the only one who's been thinking that (I grumbled to one
of the organisers a while back that they ought to rename it BermudaCrypt, since
it was that in all but name anyway).  Does anyone know what happened to the
Usenix e-commerce conferences?  They were in the vein of what FC used to be...
there's also the EC-Web conference, although that has more of an emphasis on
web technology than EC.

Peter.

RE: NAI pulls out the DMCA stick

[Peter Gutmann]

Curt Smith <[EMAIL PROTECTED]> writes:

>Certificate Authorities issue certificates complete with CA imposed expiration
>dates and usage limitations. (I prefer independent systems with unrestricted
>certificates)

So issue your own.  Honestly, why would anyone want to *pay* some random CA for
this?

>Certificate Authorities match individuals to keys (Thanks, but no thanks)

And PGP doesn't?  Anyway, X.509 certs can be as anonymous as PGP keys.

>Certificate Authorities can revoke certificates at anytime (CA-driven DOS
>attack)

Most implementations ignore revocation, and in any case it's not an issue if
you issue your own.

Peter.

Re: Joe Sixpack doesn't run Linux

[Peter Gutmann]

Meyer Wolfsheim <[EMAIL PROTECTED]> writes:

>S/MIME support is in just about every popular email client out of the box.
>Why is PGP more widely used?
>
>[Good reasons snipped]

Those who care about security [0] use PGP, the rest use S/MIME.  To steal a
line from Hexed:

  "S/MIME: For people who could care less".

Actually it's not even that, it's closer to:

  "Plaintext: For people who could care less".

I have yet to exchange an encrypted S/MIME message of any significance with
anyone, ever.  Even if the other side is using an S/MIME-enabled mailer, we
usually end up using PGP even if it means having to try half a dozen different
versions to find one which will process the other side's messages.  While I'm
in a quoting mood, there's also Marshall Rose's comment about X.400 to steal:

  Two people meet at a conference and exchange email addresses.  They get back
  to their offices and want to communicate securely.  If both sides are using
  PGP x.y.z, they communicate securely.  If one side is using PGP x.y.z and the
  other isn't, they wait for a message and then keep trying different PGP
  versions until they find one which will process the message.  If they aren't
  using PGP, they communicate in plaintext and hope no-one's listening.

  (In case that's forwarded or quoted out of context, this is a comment on a
   social issue, not a software issue).

Peter.

[0] With the corollary: "and aren't government users", S/MIME is used a fair
bit in certain areas, it just doesn't get much public exposure.

RE: NAI pulls out the DMCA stick

[Peter Gutmann]

[EMAIL PROTECTED] writes:

>My impression is that S/MIME sucks big ones, because it commits one to a
>certificate system based on verisign or equivalent.

I'll say this one more time, slowly for those at the back: What you're
criticising is PEM circa 1991, not S/MIME.  Things have moved on a bit since
then.

Peter.

RE: NAI pulls out the DMCA stick

[Peter Gutmann]

Curt Smith <[EMAIL PROTECTED]> writes:

>1.  How do you create a X.509 signing hierarchy?

Grab whatever crypto software you feel most comfortable with that does X.509
and start cranking out certs.

>2.  Can you add additional algorithms (ie. Twofish)?

Certs are for public-key algorithms, so Twofish would never appear in there
(well, I guess you could certify a Twofish key, but I'm not sure what the point
would be).

>3.  Is a relavent developer reference is available for X.509?

You have to distinguish between the X.509 format and tools to use X.509.  I
assume you're after a manual for the tools, rather than RFC 3280, for the same
reason that most PGP users don't start by reading RFC 2440.  In that case,
refer to the docs for your crypto toolkit.

Peter.

Re: S/MIME and web of trust (was Re: NAI pulls out the DMCA stick)

[Peter Gutmann]

Eric Murray <[EMAIL PROTECTED]> writes:

>Additionally, there is nothing that prevents one from issuing certs that can
>be used to sign other certs.  Sure, there are key usage bits etc but its
>possible to ignore them.  It should be possible to create a PGP style web of
>trust using X.509 certs, given an appropriate set of cert extensions.

I proposed some very simple additions to X.509 which would allow you to use the
certs in the same way as PGP keys a year or two back.  Unfortunately the PKIX
WG chair is about as open to PGP-style additions to X.509 as some PGP people
are towards S/MIME.

(You can also do PGP using X.509 certs, I've been doing that for awhile just
 out of sheer bloody-mindedness :-).

Peter.

Re: Government subsidies: our last, best hope for Cryptanarchy?

[Peter Gutmann]

"Lucky Green" <[EMAIL PROTECTED]> writes, and I add my $0.02:

>The fact of the matter is that the usage of PGP by businesses, the sole
>significant source of NAI PGP revenue, had long passed its peek. How many
>business do you know that rolled out PGP in the last year?

It's also become increasingly difficult for crypto-enthusiasts within a company
to convince mgt. that a new project should use PGP.  A year or two back you
could still, with a bit of persuasion, convince a company to go with PGP rather
than S/MIME or SSL or whatever (and "whatever" is, with frightening frequency,
IPsec, of which more below).  This is now almost impossible to do, because PGP
is seen as having very little industry support, which terrifies management.

>However, a closer inspection of the PGP interoperability problems, which have
>been at one of the issues coming up in just about every single discussion I've
>had with anybody about PGP over the last year, shows that the interop problems
>are not between current versions by multiple vendors, but between versions, in
>some cases by the same vendor, that were released over time.

The major reason for this is the incessant need of the PGP standards
contributors to keep tweaking the spec for every little issue which comes down
the track, constantly breaking compatibility with the current code base.
Unfortunately given that someone is going to come up with some novel problem
which PGP doesn't quite address at the moment but which can be fixed with a
minor update, every six months or so, it's quite possible that the standard
will never settle down until someone gets around to shooting the engineers and
backing out the last dozen or so compatibility-breaking tweaks and updates.

>Even the most casual user of software tends to be familiar with and acceptant
>of the need for occasional software upgrades.

Only if it's broken, and that's the "problem" with PGP: It ain't broken.  I can
take my 10-year-old copy of PGP 2.6.x and be no less secure with it than with
the very latest NAI release.  The only reason most people ever dumped ssh 1.x
was because of very widely-publicised exploits, and even then for many users it
took the widespread use of ssh rootkits to get them to go to 2.x.  PGP hasn't
had that problem.  Like the Energizer bunny, it just keeps on going.  Look at
the Disastry PGP releases with source code going back 10 years, it's like
taking a trip back in time.  Except for the gratuitous changes in packet
formats and whatnot and a few new algorithms, you could use it to process
current messages (it's one of the first of my standard suite of PGP versions to
try).  In fact since good ol' 2.x will interoperate with any other 2.x-vintage
version out there but post-2.x stuff is nothing but interop trouble, there's a
strong incentive *not* to upgrade.

>The reluctance to upgrade to a newer version of PGP does not appear to be
>driven by a refusal or inability to upgrade software in general. This
>reluctance to upgrade appears PGP specific.

It's not PGP specific.  It's because it ain't broken, and going to a newer
version is frequently more painful (due to interop problems) than staying with
what works.

>Now perhaps there may be the rare case of a PGP user that is still running PGP
>2.x on the same DOS box, using the same mailer and the same text editor as
>they did 5 years ago.

As a matter of fact I keep an old DOS box stashed away for emergencies.  No
matter how bad things get, you can always bring up DOS on whatever random
hardware you can scrape together from various corners, fire up a terminal
emulator, and get online.

>The same Cypherpunk expressed a hope that absent NAI's PGP, the German
>government group currently funding GPG might be more inclined to fund UI work
>for Windows. Perhaps they would. Assuming for a moment they will, would this
>lead to a better PGP Windows UI than NAI's PGP offered? NAI's PGP UI is pretty
>darn good. Looking at the sorry state of UI's currently offered for GPG, even
>with government funding, I suspect that it will be a long time indeed before
>we will see a GPG UI that will compare positively to the current NAI PGP UI.

That's always been the problem with crypto software.  Crypto is cool and fun to
do.  It is (compared to the UI) relatively easy to implement given a decent
toolkit with a good selection of algorithms and whatnot (just to show I'm not
blowing smoke, it took me around two weeks to add OpenPGP as a target format
for cryptlib enveloping).  OTOH UI work is painful and boring and not even
remotely sexy.  It'd take me forever to put a UI at the level of Outlook (which
is what the masses would expect) onto cryptlib, and even if I knew anything
about Windows GUIs you couldn't pay me enough to do it.  There are however a
few products which have managed this, eg The Bat,
http://www.ritlabs.com/securebat/index.html, so it's not impossible.  Sure,
it's not Outlook, but it's an impressive piece of work for one person.

>I bet a good percent

Re: Edinburgh Financial Cryptography Engineering 2002 - CFP

[Peter Gutmann]

Dan Geer <[EMAIL PROTECTED]> writes:

>I founded this series in 1995 and was proud to have done so; we ran them in
>1996 and 1998 as well, but the cutting edge quickly moved away from USENIX's
>core and forte to where every conference organizer on the planet had an e-
>commerce workshop of some sort up and running.

Unfortunately they've become either just another Crypto clone (FC in the last
year or two) or a collection of XML/J2EE/buzzword-du-jour be-ins (all the
rest).  The world still needs a good, technical e-commerce security conference
which isn't one of the above.

>I'm open to suggestions, of course,

I'd love to see it resurrected.  While I can't really organise it because of
where I am, I'd be happy to referee papes or whatever.  Having served on PCs
for several other security conferences, I've seen enough papers of the
appropriate kind submitted elsewhere to indicate that there'd be enough for an
e-commerce security conference (in other words there's no shortage of material
there).  The Usenix one, during its short lifetime, attracted some really good
papers.

Peter.

RE: NAI pulls out the DMCA stick

[Peter Gutmann]

[EMAIL PROTECTED] writes:
>On 27 May 2002 at 19:56, Peter Gutmann wrote:
>>[EMAIL PROTECTED] writes:
>>>My impression is that S/MIME sucks big ones, because it commits one
>>>to a certificate system based on verisign or equivalent.
>>
>>I'll say this one more time, slowly for those at the back: What you're
>>criticising is PEM circa 1991, not S/MIME.  Things have moved on a bit
>>since then.
>
>You need a certification authority.  Every one you deal with has to
>acknowledge whatever certification authority gave you your certificate.
>
>[etc etc - standard description of original 10-year-old PEM certification
> model]

No, as I said before, what you're describing is PEM circa 1991, not S/MIME.  In
the S/MIME model, anyone can issue certs (just like PGP), including yourself.
In addition, many large CAs will issue certs in any name to anyone, so even if
you don't want to do your own keys a la PGP you can still get a Verisign cert
which behaves like a PGP key.

Rather than wasting all this bandwidth in a lets-bash-S/MIME-by-pretending-
it's-still-PEM debate (what is it with this irrational fear of S/MIME?), I'd be
more interested in a serious discussion on which key-handling model is less
ineffective, WoT or X.509-free-for-all.  At the moment both of them seem to
work by using personal/direct contact to exchange keys, with one side
pretending to be WoT-based (although no-one ever relies on this) and the other
pretending to be CA-based (although no-one ever relies on this [0]).  The end
result is that they're more or less the same thing, the only major
differentiating factor being that most X.509-using products don't allow you to
distribute your own certs the way PGP does.

Peter.

[0] With my earlier caveat about exceptions for government orgs who have been
instructed to rely on it, or else.

Re: PKI: Only Mostly Dead

[Peter Gutmann]

Derek Atkins <[EMAIL PROTECTED]>
>[EMAIL PROTECTED] (Peter Gutmann) writes:
>> For example the value
>>1234567890 taken in isolation could be anything from my ICQ number
>>to my shoe size in kilo-angstroms, but if you view it as the pair {
>>,  } then it makes sense
>>(disclaimer: I have no idea whether that's either a valid ICQ number
>>or my shoe size in kilo-angstroms).
>
>It's clearly not your shoe size in kilo-angstroms, unless you have MIGHTY
>large feet.  According to 'units', that works out to 4860 inches.

Obviously it's my hat size then.

Peter.

Re: Sci Journals, authors, internet

[Peter Gutmann]

Greg Newby <[EMAIL PROTECTED]> writes:

>Some electronic journals, some conferences and some print journals now let
>authors retain copyright or, if they keep copyright, allow authors to do what
>they please with their work.

Usenix is really good with this.  You agree not to re-publish anything for a
period of one year (to cover their print distribution), although you're allowed
to put a copy on your home page.  After that, you're free to do what you like.
They also make all their stuff available online at no charge after a year. This
is why I preferentially submit papers to Usenix rather than ACM or IEEE, I want
to get the information out there where it does some good, not have it locked up
in a copyright prison for all eternity.  I can't imagine that the ACM is going
to make much (if anything) from the reprint rights of a ten-year-old article on
distributed search algorithms, but by locking it up, very few people ever have
access to it.

(Hmm, I wonder if it can be argued that making stuff intended for public
 distribution inaccessible violates the creator's moral rights?  I know that
 doesn't apply in the US, but in other countries it might work.  Moral rights
 can't be assigned, so no publisher can take that away from you.  Any lawyers
 out there?).

>It's far more typical, though, for the journal to get all rights, except
>perhaps classroom use (aka "fair use") by the author.

That's more traditional for publishers like IEEE and ACM.  OTOH they seem to
turn a blind eye to people making papers available on their home pages, even if
the publishing agreement says you shouldn't do that.  I suspect the backlash
would be too strong if they tried to clamp down on this, although I wish it'd
be formalised in some way rather than leaving it as a grey area.

Peter.

Good quote on biometric ID

[Peter Gutmann]

I was reading a late-70's paper on computer security recently when I saw that
it contains a nice quote about the futility of trying to use biometrics to
prevent Sept.11-type attacks, I thought I'd share it with people:

  When a highway patrolman is sent to his duty, he has to be given the
  authority to cite traffic violators.  This cannot be done explicitly for each
  violator because at the time that the patrolman is sent to his duty, the
  traffic violator does not exist, and the identity of the future violators is
  not known, so that it is impossible to construct individual access rights for
  the violators at that time.  The point is that the patrolman's authority has
  to do with the behaviour of motorists, not their identity.

  - Naftaly Minsky, "An Operation-Control Scheme for Authorisation in Computer
Systems", International Journal of Computer and Information Sciences,
Vol.2, No.2, June 1978, p.157.

Peter.

RE: IP: SSL Certificate "Monopoly" Bears Financial Fruit

[Peter Gutmann]

"Lucky Green" <[EMAIL PROTECTED]> writes:

>"Trusted roots" have long been bought and sold on the secondary market as any
>other commodity. For surprisingly low amounts, you too can own a trusted root
>that comes pre-installed in >95% of all web browsers deployed.

I'd heard stories of collapsed dot-coms' keys being auctioned off, that being
the only thing of value the company had left.  It makes the title of Matthias'
paper even more appropriate.

(However, I do think that anyone wanting to compromise your security will use
 this morning's MSIE hole to do it rather than buying a CA key.  OTOH it'd be a
 great universal skeleton key for government agencies charged with protecting
 the world from equestrians).

Peter.

Re: Ross's TCPA paper

[Peter Gutmann]

Jay Sulzberger <[EMAIL PROTECTED]> writes:

>Nonsense.  Let us remember what Palladium is:
>
>Palladium is a system designed to enable a few large corporations and
>governments to run source secret, indeed, well-encrypted, code on home user's
>machines in such a way that the home user cannot see, modify, or control the
>running code.

There's an even simpler explanation which I tried recently on some non-techies:

  Palladium is a way for Microsoft to make it harder for users to install a
  pirated copy of Office.  That is all.

They understood.

>From a purely economic perspectice, I can't see how this will fly.  I'll pull a
random figure of $5 out of thin air (well, I saw it mentioned somewhere but
can't remember the source) as the additional manufacturing cost for the TCPA
hardware components.  Motherboard manufacturers go through redesigns in order
to save cents in manufacturing costs, and they're expected to add $5 to their
manufacturing cost just to help Microsoft manage its piracy problem?  More to
the point, there's a significant engineering overhead involved here.  Look at
PC power management, after years of APM and then ACPI we've now reached the
situation where power management more or less works, most of the time, as long
as you don't do anything more complex than suspend-to-disk.  Assuming that the
TCPA hardware is of the same level of complexity as ACPI, what a hardware
vendor gets by going down the TCPA/Palladium track is:

 - More expensive products than the competition with no gain in features.
 - Late to market because of the extra design and testing involved.
 - Years of bugfixes and updates a la ACPI.

In return they get:

 - A warm glow of satisfaction knowing that they're lending Microsoft a hand in
   improving their bottom line.

Sounds a bit like the SET business model in which the issuing bank got to carry
all the cost and liability and the aqcuiring bank got all the benfits.

Peter.

RE: DNA databases to be classified

[Peter Gutmann]

"Lucky Green" <[EMAIL PROTECTED]> quoted:

>The feat proves that even if all the polio virus in the world were
>destroyed, it would be easily possible to resurrect the crippling
>disease. It also raises the worrying possibility that bioterrorists
>could use a similar approach to create devastating diseases such as
>ebola and smallpox without having to gain access to protected viral
>stocks.

I saw this on BBC news.  It took a very sophisticated lab two years work to
produce polio.  They thought they might be able to do smallpox given about 20
years work.  They even managed to slip in an Internet reference in the story. 

I guess "We synthesised polio from RNA" just isn't newsworthy enough on its
own.

Peter.

Re: Ross's TCPA paper

[Peter Gutmann]

Eric Murray <[EMAIL PROTECTED]> writes:
>On Fri, Jul 12, 2002 at 07:14:55PM +1200, Peter Gutmann wrote:
>>From a purely economic perspectice, I can't see how this will fly.  I'll pull a
>>random figure of $5 out of thin air (well, I saw it mentioned somewhere but
>>can't remember the source) as the additional manufacturing cost for the TCPA
>>hardware components.  Motherboard manufacturers go through redesigns in order
>>to save cents in manufacturing costs, and they're expected to add $5 to their
>>manufacturing cost just to help Microsoft manage its piracy problem?
>
>Motherboard makers don't pay for it.  Microsoft pays for it.

Hmm, I can just see it now, Windows 2005 ships as three CDs, a 400-page EULA, a
fine-tip soldering iron, a magnifying glass, an EMBASSY chip, and a copy of
"SMD Soldering for Dummies".

Peter.

Re: Big Brotherish Laws

[Peter Gutmann]

Bill Stewart <[EMAIL PROTECTED]> writes:

>I have heard of one case where somebody was stopped in Nevada, and instead of
>presenting his California driver's license, if any, he presented his
>somewhere-in-the-Caribbean non-photo license and an international driver's
>license, and that was just fine for Nevada.

That's because non-US licenses constitute automatic permission for minor
traffic law violations.  The scenario is something like the following:

[Driver gets pulled over].

Driver: "Gidday mate, hows it going?"

[Cop asks for license, looks at it]

Cop: "A, screw it, too much paperwork.  Don't do it again.  HAND".

Peter.

Sovereignty issues and Palladium/TCPA

[Peter Gutmann]

It looks like Palladium (or whatever it's called this week) is of concern not
just to individuals but to governments as well (the following text forwarded
from elsewhere):

-- Snip --

  Governments would want to explore the implications of the use and
retention of government-held information and use of software for government
business.
  More particularly, governments are likely to want to explore the issues
related to potential foreign control/influence over domestic governmental
use/access to domestic government held data.
  In other words, what are the practical and policy implications for a
government if a party external to the government may have the potential
power to turn off our access to its own information and that of its
citizens.

-- Snip --

Unlike China, not everyone can address this problem by building their own
systems from the silicon on up.

Peter.

The Crypto Gardening Guide and Planting Tips

[Peter Gutmann]

After much procrastination I recently put the Crypto Gardening Guide and
Planting Tips online at
http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt, this may be of
interest to readers.  From the introduction:

  There has been a great deal of difficulty experienced in getting research
  performed by cryptographers in the last decade or so (beyond basic
  algorithms such as SHA and AES) applied in practice.  The reason for this is
  that cryptographers don't work on things that implementors need because it's
  not cool, and implementors don't use what cryptographers design because it's
  not useful or sufficiently aligned with real-world considerations to be
  practical. As a result, security standards are being created with mechanisms
  that have had little or no security analysis, often homebrew mechanisms or
  the standards editor's pet scheme.  The problem is a lack of communication:
  Cryptographers often don't seem aware of the real-world constraints that
  their design will need to work within in order to be successfully deployed.
  The intent of this document is to cover some of those real-world constraints
  for cryptographers, to point out problems that their designs will run into
  when attempts are made to deploy them.  Also included is a motivational list
  of extremely uncool problems that implementors have been building ad-hoc
  solutions for since no formal ones exist.

Peter.

Re: Putting the "NSA Data Overwrite Standard" Legend to Death... (fwd)

[Peter Gutmann]

Thomas Shaddack <[EMAIL PROTECTED]> writes:

>Second, where did the number 7 really come from? 

>From the OSI 7-layer model, which took it from the fact that the number 7 is
sacred to a certain tribe in Borneo (see "The Elements of Networking Style",
by Mike Padlipsky).

Peter.

Re: Congressmen in need of composting: Manzanar fine with him

[Peter Gutmann]

"Major Variola (ret)" <[EMAIL PROTECTED]> writes:

>Why don't they stop pretending and call it Fatherland Security Agency?

Because then the Russian translation of the name wouldn't be "KGB" any
more (well, it'd be less close to KGB than it is now).

Peter.

Good survey article on crypto hardware

[Peter Gutmann]

There's a good article on software and hardware for reconfigurable computer
systems (e.g. FPGA's) in the June 2002 ACM Computing Surveys for people who are
interested in that sort of thing.  This is the sort of hardware which is often
used for crypto when a full ASIC isn't economically viable (one of those
combined PPC+FPGA cores would be quite interesting for crypto use).

Peter.

Re: right MTA for crypto support

[Peter Gutmann]

Eugen Leitl <[EMAIL PROTECTED]> writes:

>It's relatively easy to turn on TLS in sendmail.  It's not secure against
>active attackers that can modify the data in the TCP stream but it's better
>than nothing.

Actually it's better than any other mail security out there.  See the slides
for my talk at Usenix Security 
(http://www.cs.auckland.ac.nz/~pgut001/pubs/usenix02_slides.pdf) for more
details (the StartTLS stuff is about halfway through).

Peter.

Re: right MTA for crypto support

[Peter Gutmann]

Eric Murray <[EMAIL PROTECTED]> writes:
>On Wed, Aug 28, 2002 at 03:26:47PM +1200, Peter Gutmann wrote:
>> Eugen Leitl <[EMAIL PROTECTED]> writes:
>
>(actually, I wrote:)

Oops, sorry, trimmed the wrong text.

>>>It's relatively easy to turn on TLS in sendmail.  It's not secure against
>>>active attackers that can modify the data in the TCP stream but it's better
>>>than nothing.
>>
>>Actually it's better than any other mail security out there.  See the slides
>>for my talk at Usenix Security
>>(http://www.cs.auckland.ac.nz/~pgut001/pubs/usenix02_slides.pdf) for more
>>details (the StartTLS stuff is about halfway through).
>
>It depends on how you define "better".

Currently the amount of my mail protected by traditional means is essentially
nonexistant.  I get one piece of PGP-encrypted mail every month or two (and I
was one of the peope who helped write the thing!) and I don't recall ever
having received or sent any S/MIME-encrypted mail.  OTOH something like 10-15%
of all my mail is protected by STARTTLS, and the figure is rising continuously
and will continue to do so (particularly if MS make some minor changes in
Exchange which I've asked some people there about).

It doesn't matter how many types of mail encryption software I have sitting
unused on my hard drive, 10% (and growing) coverage with reasonable protection
is better than 0% coverage with good protection.

Peter.

Re: Cryptographic privacy protection in TCPA

[Peter Gutmann]

Nomen Nescio <[EMAIL PROTECTED]> writes:

>If a key is misused, i.e. "scraped" out of the TPM and used to create a
>virtualized, rule-breaking software TPM, it can be revoked.  This means that
>all the TPMs that share that one key lose the use of that key. But it doesn't
>matter much, because they each have many more they can use. Since it is
>expected that only a small percentage of TPMs will ever need their keys
>revoked, most TPMs should always have plenty of keys to use.

I designed something along these lines some years ago as a way of building a
fault-tolerant key management system.  The idea is that you create a pile of
keys, and these vote on key updates.  If a key is compromised, you sign its
replacement with a quorum of non-compromised keys, and replace the bad key.
You also periodically roll over keys as a preventive measure, limiting
exposure due to compromises.  No need for a PKI or anything else complex like
that, it's all automatic and transparent.

There can be slight problems if a device stays offline long enough that enough
keys have been rolled over to make reaching a quorum impossible, which was an
issue when I designed the thing but rather unlikely now.  I can dig up the
exact details in case anyone's interested.

Peter.

Re: S/MIME in Outlook -- fucked.

[Peter Gutmann]

"James A. Donald" <[EMAIL PROTECTED]> writes:

>While the immediate bug is in Microsoft IE and Outlook, this exploit is also
>a reflection of the contorted mess that is the certificate structure and the
>public key infrastructure

One of the eternal problems of X.509 software:

Implementation Problem Redux

Certified for use with Windows

- Microsoft owns the trademark
- Submit software to Microsoft, who perform extensive testing
- Passing software can use the certification mark
- Reasonable (given the size of the deployed base) interoperability among 
  tested products

S/MIME

- RSADSI owns (owned) the trademark
- Simple interoperability test for signing and encryption
-- Anyone could participate, at no cost
- Passing software can use the certification mark
- Good interoperability among tested products

X.509
- No quality control
- You cannot build software so broken than it can't claim to be X.509v3

(Lifted from "Everything you never wanted to know about PKI but have been
 forced to find out",
 http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf).

Peter.

Re: no ICs in nukes...

[Peter Gutmann]

"Major Variola (ret)" <[EMAIL PROTECTED]> writes:

>there are no chips in nukes (p 8)

There are no ICs in *safety-critical* areas (they use discrete components and
mechanical interlocks).  An earlier slide is quite clear that there are ICs
in there.

Peter.

Re: Cypherpunks and Irish Travellers

[Peter Gutmann]

>>another woman, Rose Ann Carroll, were arrested March 27 at a Kohls
>>department store in Fort Worth on charges of theft $50 to $500.
>
>I wasn't follownig the news ... they didn't get Osama, did they ?

No, although there was a brief scare when it was reported that bed Linen had
been spotted in another part of the store.

Peter.

Re: What good are smartcard readers for PCs

[Peter Gutmann]

"James A. Donald" <[EMAIL PROTECTED]> writes:

>Increasingly however, we see smartcard interfaces sold for PCs. What for, I
>wonder?

Companies buy a few readers for their developers who write software to work
with the cards.  They may even roll out a few in pilots, and put out a stack of
press releases and print brochures advertising how hip they are for using smart
cards.  Eventually the clients discover how much of a bitch they are to work
with (installation problems/buggy drivers/incompatibilities/not having your
card when you need it/etc, not helped by the fact that smart card vendor after-
sales support is the most client-hostile of any PC hardware type I know of)
that users decide to live with software-only crypto until the smart card scene
is a bit more mature.

Given that n_users >> n_card_vendors, this situation can keep going for quite
some time.

Peter.

Sex scandal undermines spy morale

[Peter Gutmann]

Most of the major Australian papers have reports of this, here's one from
http://www.theage.com.au/articles/2002/09/26/1032734259148.html.  The DSD is
Australia's NSA.

Sex scandal undermines spy morale
September 26 2002

Sexual misconduct has so comprehensively undermined morale within one of
Australia's top-secret intelligence agencies it has become a national security
risk, according to a report today.

The rift within the Defence Signals Directorate was detailed in a file given
to the News Ltd papers.

It alleges improper sexual behaviour, nepotism and mismanagement by high-
ranking agency officers.

[...]

Re: What good are smartcard readers for PCs

[Peter Gutmann]

I wrote:

>The FAQ handwaves the details, so it could be either 1 or 3.  Can someone who
>has one of these things try reading the ATR off it?

He Who has No Shame [0] reports that it's a GemClub memory card, which is
reasonably similar to the old SLE4428-style cards: 256 bytes of memory, some
of it PIN-protected.  Available commands are read, write, and verify PIN.
Given the info in the FAQ, it would appear that the PIN is fixed/hardcoded
into the driver, since there's no indication that users are asked for it, and
it mentions that if someone else finds your card, they get access (or they may
just use the non-protected storage in the card).  I'm guessing this was a
marketing decision, expecting x-teen-year-old kids (whatever the target market
for these things is) to remember and enter PINs, not to mention the UI issues
involved in obtaining the things, would make it unworkable, while reading off
a URL and password and poking it into a browser is something which is a lot
safer to deploy.

Access control is by an XML version of basic-auth.

In other words, it's (effectively) a dumb memory card with (effectively) HTTP
basic-auth.  It does however use the T=0 serial protocol and not I2C, which is
a bit trickier to read with wires poked in the parallel port :-).

Peter.

[0] He actually bought it under his own name, without pretending it was for
his nieces or something.

Real-world steganography

[Peter Gutmann]

I recently came across a real-world use of steganography which hides extra
data in the LSB of CD audio tracks to allow (according to the vendor) the
equivalent of 20-bit samples instead of 16-bit and assorted other features.
According to the vendors, "HDCD has been used in the recording of more than
5,000 CD titles, which include more than 250 Billboard Top 200 recordings and
more than 175 GRAMMY nominations", so it's already fairly widely deployed.
>From http://www.hdcd.com/partners/proaudio/overview.html:

[...]

Hidden Code Addition/Output Dither/Quantization

The final step in the reduction to 16 bits is to add high-frequency weighted
dither and round the signal to 16-bit precision. The dither increases in
amplitude in the frequency range of 16 to 22.05 kHz, leaving the noise floor
flat below 16 kHz where the critical bands of hearing associated with tonality
occur. As part of the final quantization, a pseudo-random noise hidden code is
inserted as needed into the least significant bit (LSB) of the audio data. The
hidden code carries the decimation filter selection and Peak Extend and Low
Level Range Extend parameters. Inserted only 2?5 percent of the time, the
hidden code is completely inaudible-effectively producing full 16-bit
undecoded playback resolution. The result is an industry-standard 44.1-kHz,
16-bit recording compatible with all CD replication equipment and consumer CD
players.

[...]

The paper describing the process is available under the somewhat misleading
name http://www.hdcd.com/partners/proaudio/AES_Paper.pdf.  The description of
the stego en/decoding process is on p.15 (it's a rather long excerpt, but it's
interesting stuff):

As part of the final quantization, a hidden code side channel is inserted into
the LSB when it is necessary for the encoder to inform the decoder of any
change in the encoding algorithm. It takes the form of a pseudo-random noise
encoded bit stream which occupies the least significant bit temporarily,
leaving the full 16 bits for the program material most of the time. Normally,
the LSB is used for the command function less than five percent of the time,
typically only one to two percent for most music. Because the hidden code is
present for a small fraction of the time and because it is used as dither for
the remaining 15 bits when it is inserted, it is inaudible. This was confirmed
experimentally with insertion at several times the normal fraction of time.

[...]

The mechanism which allows insertion of commands only when needed consists of
encapsulating the command word and parameter data in a "packet". A
synchronizing pattern is prepended to the data and a checksum is appended. The
resulting packet is then scrambled using a feedback shift register with a
maximal length sequence and inserted serially, one bit per sample, into the
LSB of the audio data. The decoder sends the LSB's of the audio data to a
complementary shift register to unscramble the command data. A pattern
matching circuit looks for the synchronizing pattern in the output of the
descrambler, and when it finds it, it attempts to recover a command. If the
command has a legal format and the checksum matches, it is registered as a
valid packet for that channel. The arrival of a valid packet for a channel
resets a code detect timer for that channel. If both channels have active
timers, then code is deemed to be present and the filter select data is
considered valid immediately. However, any command data which would effect the
level of the signal must match between the two channels in order to take
effect. The primary reason for this is to handle the case where an error on
one channel destroys the code. In such a case, the decoder will mistrack for a
short time until the next command comes along, which is much less audible than
a change in gain on only one channel, causing a shift in balance and lateral
image movement. If either of the code detect timers times out, then code is
deemed not to be present, and all commands are canceled, returning the decode
system to its default state. If the conditions on the encoder side are not
changing, then command packets are inserted on a regular basis to keep the
code detect timers in the decoder active and to update the decoder if one
starts playing a selection in the middle of a continuous recording.

Since the decoder is constantly scanning the output of the de-scrambler shift
register for valid command packets even when none are present, the possibility
exists that there may be a false trigger. For audio generated by the encoder,
this possibility is eliminated in the absence of storage and transmission
errors by having the encoder scan the LSB of the audio data looking for a
match. If a match to the synchronizing pattern is found, the encoder inverts
one LSB to destroy it.

Modern digital storage and transmission media incorporate fairly sophisticated
error detection and correction systems. Therefore, we felt that only moderate
precautions were necessary 

Re: What email encryption is actually in use?

[Peter Gutmann]

"James A. Donald" <[EMAIL PROTECTED]> writes:

>To the extent that real people are using digitally signed and or encrypted
>messages for real purposes, what is the dominant technology, or is use so
>sporadic that no network effect is functioning, so nothing can be said to be
>dominant?

For encryption, STARTTLS, which protects more mail than all other email
encryption technology combined.  See
http://www.cs.auckland.ac.nz/~pgut001/pubs/usenix02_slides.pdf (towards the
back).

For signing, nothing.  The S/MIME list debated having posts to the list
signed, and decided against it: If I know you, I can recognise a message from
you whether it's signed or not.  If I don't know you, whether it's signed or
not is irrelevant.  That leaves a few highly specialised applications which
don't really qualify as use by "real people" (e.g. pgpmoose, EDI, etc etc,
where any random proprietary format is fine, since it's decided by mutual
agreement of both parties).

Peter.

Re: What email encryption is actually in use?

[Peter Gutmann]

"David Howe" <[EMAIL PROTECTED]> writes:
>at Wednesday, October 02, 2002 3:13 AM, Peter Gutmann
><[EMAIL PROTECTED]> was seen to say:
>>As opposed to more conventional encryption, where you're protecting
>>nothing at any point along the chain, because 99.99% of the user base
>>can't/won't use it.
>That is a different problem. if you assume that relying on every hop between
>you and your correspondent to be protected by TLS 

Doing a quick check of all of today's mail, there's only a single hop on the
WAN.  This is a non-issue.

>*and* the owner of that server to be trustworthy (not only in the normal
>sense, but resistant to legal pressure, warrants from LEAs and financial
>"incentives" from your competitors) 

If the Uni sysadmins want to read mail sent from Uni machines, they'll get it
with or without me using encryption, and it'd be the same for most (all?)
corporates.  This is a non-issue.

>then you are in for a rude awakening at some point.

I know exactly what I'm getting from STARTTLS, which is adequate security most
of the time, automatically, with no extra effort.  If I want real security,
I'll send it from a home machine in a lead-lined room while wearing a tinfoil
hat, while worrying whether the use of an encrypted message in this manner
will attract undue suspicion.

Luckily I don't need real security most of the time, just protection from
fishing expeditions and general snooping, which STARTTLS gives me.

Peter.

Interesting KPMG report on DRM

[Peter Gutmann]

KPMG have a report "The Digital Challenge: Are You Prepared?" available at
http://www.kpmg.com/news/index.asp?cid=660 in which they surveyed execs at
media companies and conclude that they're focusing too much on (trying to)
lock up content using encryption rather than how to do something useful with
it:

  Digital content is getting a lot of attention - but not at the board level,
  where it is urgently needed. As a recent KPMG survey of top executives
  shows, media companies are focusing too much on encryption and other
  defensive technologies while failing to develop proactive strategies that
  recognize and leverage their online intellectual property assets.

[...]

  But the industry.s efforts to grapple with losses on this scale by locking
  away content behind multiple layers of protection - whether encryption,
  copyright protection, or authentication - have tended to detract from the
  user experience while failing to deliver the hoped-for revenue streams.

  Indeed, for all the publicity, expert attention, and corporate ingenuity
  devoted to digital piracy, it is striking that global content companies have
  not yet been able to find a working solution.

  This white paper, organized around a survey conducted for KPMG by The
  Economist Intelligence Unit, takes the industry.s pulse on The bottom line
  is that media companies need to shift their focus from a circle-the-wagons
  defense of digital intellectual property to innovative strategies for
  managing online content as a core revenue source. To achieve this shift,
  digital intellectual property needs to be valued properly, just like other
  assets on the balance sheet. Also, its protection needs to be treated as a
  key issue of corporate governance and given sustained and dedicated board-
  level attention.

  It is clear from the survey that media executives are trying to remain
  optimistic about the potential of digital content - but securing
  intellectual property rights is an uphill battle. In the quest for the right
  mix of measures to fight piracy, executives are relying heavily on
  encryption as well as reactive steps to police and punish violators. At the
  same time, however, many companies fail to conduct systematic accounting for
  their digital assets, or to pursue more proactive strategies to build new
  revenue streams from their online content.

[...]

  Media companies have so far failed to pioneer new business models that would
  rob piracy of its appeal. Preoccupied with defending the barricades against
  pirates, the industry has shown a deficit of creativity and innovation in
  rolling out products and services that can compete with the pirates. This
  was clear in KPMG.s survey, where only a handful of respondents saw offering
  potential abusers the chance to distribute content legally as a way of
  protecting digital intellectual property.

  In addition, the content industry remains hostage to its own strict
  interpretations of copyright laws and definitions of intellectual property.
  Most leading media organizations have their roots in traditional media
  formats - they still consider every bit of content they produce to be
  subject to copyright and they defend it - tooth and nail. However, today.s
  Internet world conflicts with this business model, as consumers expect more
  fluid boundaries and demand a free flow of information.

Good stuff, read the whole thing at http://www.kpmg.com/news/index.asp?cid=660.

Peter.

Re: Warning.. Warning.. *bleep*

[Peter Gutmann]

anonymous <[EMAIL PROTECTED]> writes:

>"Officials said the warning, based on information obtained from al Qaeda
>prisoners in mid-October, suggested that terrorists may try to destroy
>bridges or key sections of tracks.

Having experienced the US rail system in the past, would anyone even notice if
they did?  Actually having experienced NZRail in the past as well, I'm sure
no-one would notice here, particularly if the attack resulted in a derailment.
With a European rail system it'd be different.

>Next in the series:
>"FBI warns bouncy castles may be targeted"

Nahh, "FBI warns buses may be targeted, leading to late or missed buses".

Peter.

Re: Did you *really* zeroize that key?

[Peter Gutmann]

David Honig <[EMAIL PROTECTED]> writes:

>Wouldn't a crypto coder be using paranoid-programming skills, like 
>*checking* that the memory is actually zeroed? (Ie, read it back..)
>I suppose that caching could still deceive you though?

You can't, in general, assume the compiler won't optimise this away
(it's just been zeroised, there's no need to check for zero).  You 
could make it volatile *and* do the check, which should be safe from 
being optimised.

It's worth reading the full thread on vuln-dev, which starts at
http://online.securityfocus.com/archive/82/297827/2002-10-29/2002-11-04/0.
This discusses lots of fool-the-compiler tricks, along with rebuttals
on why they could fail.

Peter.

RE: Did you *really* zeroize that key?

[Peter Gutmann]

"James A. Donald" <[EMAIL PROTECTED]> writes:

>If the optimizer ever optimizes away a write to volatile
>memory, device drivers will fail.  Most device drivers are
>written in C.  If anyone ever produces a C compiler in which
>"volatile" does not do what we want, not only are they out of
>spec, but smoke will start coming out of hardware when the
>device drivers are recompiled.

The people who assume that any compiler which compiles their code gets
an obscure feature like volatile exactly as per the spec are probably the
same ones who assume that fixed-size buffers will never be exceeded.

It's my job to be paranoid.  I will assume that an arbitrary compiler 
gets a while() loop right (it'd be obvious if it didn't), but I won't 
gamble my crypto keys over assumptions about the correct handling of 
volatile in all compilers.  Specifically, I want to keep crypto keys
secure in the real world, and the real world may have compilers which
optimise away references to volatile storage, whether the spec says
so or not.

Peter.

Digital signature legislation tutorial posted

[Peter Gutmann]

I've recently revamped part 2 of my Godzilla security tutorial, splitting off
the coverage of digital signature legislation and related issues into its own
section.  Part2a, consisting of a total of 79 slides, covers the question of
why we need digital signature legislation, what is a signature, paper
vs.electronic signatures, non-repudiation, trust, and liability, existing
approaches, examples of existing legislation of various types including
advantages and drawbacks, and the Digital Signature Law litmus test (and it
also explains why having a techie comment on legal issues isn't as silly as it
sounds :-).  It's available as part 2a of the Godzilla tutorial at
http://www.cs.auckland.ac.nz/~pgut001/tutorial/index.html.  Comments welcome

Peter.

Re: sleep deprivation was Re: Torture done correctly is a terminal process

[Peter Gutmann]

Steve Schear <[EMAIL PROTECTED]> writes:

>I read some books in my youth on SH and found I could put myself in a self-
>induced altered reality state from which I could not be easily awakened.

I've had that too, listening to pre-election party political broadcasts.

>physical abuse might be thwarted as well for the well conditioned.

Time to start listening to election speeches...

Peter.

Re: ACLU funds Total Awareness of State Abuse

[Peter Gutmann]

[Apologies if you've seen this before, one of our machines has been quietly
 dropping outgoing mail...]

"Major Variola (ret)" <[EMAIL PROTECTED]> writes:

>It's a mirror image to the government's plan to empower some Americans to
>check on their neighbors, under a program known as the Terrorism Information
>and Prevention System.

Is that the American Neighbourhood Watch?  That lead to the following post on
the ukcrypto list a while back:

-- Snip --

Graham <[EMAIL PROTECTED]> writes:

>Beware! traitors are everywhere!  You must immediately report any
 terrorists
>treasonous behaviour or any suspicion of treasonous behaviour to the
 terrorist
>Computer. Failure to do so is treason.
 American Neighbourhood Watch

>Some of your brother Troubleshooters may serve the Computer as Guardians
  neigbours A.N.W.  neigbourhood
>Of Internal Security.  They are present for your protection.  They will
 wardens
>report any treasonous behaviour or hint of treasonous behaviour or
terrorist   terrorist
>suspicion that treasonous behavour might take place at some time in the
terrorist
>future, to the Computer.  Rejoice in the assurance that any treason
A.N.W.   terrorism
>among your companions will be discovered and punished.

>Devote your service to the Computer.  Your loyalty will be generously
A.N.W.
>rewarded.

So there we have the real explanation - Dubya wants a live roleplaying version
of the game.

Peter.

-- Snip --

Peter.

Re: U.S. Drops 'E-Bomb' On Iraqi TV

[Peter Gutmann]

Sarad AV <[EMAIL PROTECTED]> writes:
>> The highly classified bomb creates a brief pulse of
>> microwaves powerful enough to fry computers, blind
>> radar, silence radios, trigger crippling power
>> outages and disable the electronic ignitions in
>> vehicles and aircraft.
>
>the existance of such a bomb was on indian news papers
>a week ago.

It's also nothing like highly classified - google for "flux compression
generator".

Peter.

Re: Things are looking better all the time

[Peter Gutmann]

Steve Schear <[EMAIL PROTECTED]> writes:

>I seem to recall that with sufficient knowledge and commonly available
>detonators shaped explosive charges can be configured to hurl heavy
>explosive payloads, much like a mortar, with fair accuracy, great distance
>or very high velocity.  I can't seem to find the reference on-line but I
>vaguely recall that a 50kg payload could be accelerated to multi-mach
>speeds with a device that could be placed in a car trunk.  A poor man's
>howitzer.

It sounds like you're talking about explosively formed projectiles (EFPs),
which are a means of creating high-velocity (several km/s) light projectiles,
chiefly useful for armour penetration.  Because of the way it works, it can't
"hurl heavy explosive payloads" (neither heavy, not explosive).  It's been
around for awhile, but the first technology demonstrators didn't surface until
the 1980s (Germany and France), and it's only starting to be adopted now (very
tricky technology to get right).  The RAF used an EFP in 1989 to assassinate
the chairman of Deutsche Bank (it's typically reported as being "a car bomb",
but was actually done by parking a pushbike with a small bag on the back next
to the road where the car was to pass.  The projectile punched through the
side of his armoured limo and killed him, but left everyone else alive.  This
is one of those feats which, if you had asked experts in 1989, would have told
you was impossible to do).

Peter.

Re: Things are looking better all the time

[Peter Gutmann]

Bill Stewart <[EMAIL PROTECTED]> writes:
>At 04:14 PM 03/26/2003 +1200, Peter Gutmann wrote:
>>The RAF used an EFP in 1989 to assassinate the chairman of Deutsche Bank
>
>I assume that's some Italian or German group's acronym and not Britain's
>Royal Air Force?  :-)

Red Army Faction, a German terrorist group active mostly in the 1970s, now
disbanded.

Peter.

RE: U.S. Drops 'E-Bomb' On Iraqi TV

[Peter Gutmann]

John Young <[EMAIL PROTECTED]> writes:

>Whether either of these work as bragged or are psyop mirages is worth betting
>an WMD Indian nickle on.

It's a cool toy, but I can't see someone using a $1M e-bomb when a $1000 Mk.82
will do the same thing, especially if there's any chance it'll be captured
intact by an enemy who can... hmm, there's a thought:

Bush announces discovery of WMD in Baghdad.

US forces have discovered an Iraqi WMD embedded in a crater in floor of the
the Ministry of Truth in Baghdad.  "We were flabbergasted" said a
flabbergasted spokesthing. "They'd even dummied it up to look like it was
manufactured in the US".

Peter.

RE: U.S. Drops 'E-Bomb' On Iraqi TV

[Peter Gutmann]

Steve Schear <[EMAIL PROTECTED]> writes:
>At 01:46 AM 3/28/2003 +1200, Peter Gutmann wrote:
>>John Young <[EMAIL PROTECTED]> writes:
>>
>>>Whether either of these work as bragged or are psyop mirages is worth betting
>>>an WMD Indian nickle on.
>>
>>It's a cool toy, but I can't see someone using a $1M e-bomb when a $1000 Mk.82
>>will do the same thing, especially if there's any chance it'll be captured
>>intact by an enemy who can... hmm, there's a thought:
>
>According to Carlo a E-WMD can be constructed, by a knowledgeable person,
>in a home garage machine shop from parts costing << $5000.

This is the Pentagon we're talking about here.  The spanner used to tighten
the bolts costs $5000.

(I've also been told that a Mk.82 wholesales for around US$250, so I guess
 we're being overcharged at NZ$1K.  Maybe it's because we don't buy 'em in
 bulk).

Peter.

Re: Fatherland Security agents above the law?

[Peter Gutmann]

"Tyler Durden" <[EMAIL PROTECTED]> writes:

>"The Fatherland Security troops are publicly embaressed and showing their
>brown shirts."
>
>Well, I'm not convinced you guys have detected the right intended message
>here.
>
>Basically, the real message may be: "it's impossible to protect Americans
>through local policies alone".

I thought it was "The news media will do anything for a story, even if they
have to manufacture it themselves".  Given that the US is currently obsessed
with terrorism, creating a sensationalist story related to it is a sure-fire
winner, even if the more accurate wording of "ABC ships expensive yacht
ballast to US" would get less attention.

(Come to think of it, I'm sure I could raise at least a moderate stink over
 here by letting it slip that some of the America's Cup yachts that were here
 earlier in the year may have had (shock, horror!) dangerous radioactive
 uranium in their keels, in violation of the government's anti-nuclear
 stance).

Peter.

Re: An attack on paypal --> secure UI for browsers

[Peter Gutmann]

Amir Herzberg <[EMAIL PROTECTED]> writes:

>Ka Ping Yee, User Interface Design for Secure System, ICICS, LNCS 2513, 2002.

Ka-Ping Yee has a web page at http://zesty.ca/sid/ and a lot of interesting
things to say about secure HCI (and HCI in general), e.g. a characterisation
of safe systems vs. general-purpose systems:

  In order for Alice to use her computer usefully, she has to be able to
  instruct programs to do things for her.  In order for those programs to
  carry out tasks, she has to trust those programs with some authority.  So
  every useful operation involves making the system a little bit less safe.
  In order to keep the system from becoming unboundedly unsafe, Alice must
  also be able to make her system more safe.

  A system in an ultimately safe state is one that can't do anything other
  than what was planned ahead of time.  General-purpose computing is useful to
  Alice only because she can make unpredictable inputs into the system, asking
  it to do new things.

Peter.

Re: An attack on paypal --> secure UI for browsers

[Peter Gutmann]

Nomen Nescio <[EMAIL PROTECTED]> writes:

>I don't see how this is going to work.  The concept seems to assume that
>there is a distinction between "trusted" and "untrusted" programs. But in the
>NGSCB architecture, Nexus Computing Agents (NCAs) can be written by anyone.
>If you've loaded a Trojan application onto your machine, it can create an NCA,
>which would presumably be eligible to put up a "trusted" window.
>
>So either you have to configure a different list of doggie names for every
>NCA (one for your banking program, one for Media Player, one for each online
>game you play, etc.), or else each NCA gets access to your Secret Master List
>of Doggie Names.  The first possibility is unmanageable and the second means
>that the trustedness of the window is meaningless.

Maybe MS will implement something like the secure attention key in the old VAX
A1 VMM (Ctrl-Alt-Del already serves this purpose for logins) which gives you a
guaranteed non-spoofed interface to the kernel (see for example "A
Retrospective on the VAX VMM Security Kernel" by Karger et al for more
information on this).  They certainly have the VMS knowhow :-).

Peter.

Re: An attack on paypal

[Peter Gutmann]

"Matt Crawford" <[EMAIL PROTECTED]> writes:

>True as written, but Netscrape ind Internet Exploder each have a hack for
>honoring the same cert for multiple server names.  Opera seems to honor at
>least one of the two hacks, and a cert can incorporate both at once.
>
>   /C=US/ST=Illinois/L=Batavia/O=Fermilab/OU=Services
>   /CN=(alpha|bravo|charlie).fnal.gov/CN=alpha.fnal.gov
>   /CN=bravo.fnal.gov/CN=charlie.fnal.gov

Just to clarify this, so you need a multivalued CN, with one containing the
expression "(a|b|c)" and the remaining containing each of "a", "b", and "c"?
Is it multiple AVAs in an RDN, or multiple RDNs?   (Either of these could be
hard to generate with a lot of software, which can't handle multiple AVAs in
an RDN or multiple same-type RDNs).  Which hack is for MSIE and which is for
Netscape?

Peter.

Re: Maybe It's Snake Oil All the Way Down

[Peter Gutmann]

Derek Atkins <[EMAIL PROTECTED]> writes:

>Actually, the ASN.1 part is a major factor in the X.509 interoperability
>problems.  Different cert vendors include different extensions, or different
>encodings.  They put different information into different parts of the
>certificate (or indeed the same information into different parts).  Does the
>FQDN for a server cert belong in the DN or some extension?  What about the
>email address for a user cert?

That doesn't really have anything to do with ASN.1 though.  You can make just
as big a mess with XML (actually even bigger, in my experience), or EDIFACT,
or whatever.  The problem isn't the bit-bagging format, it's that it's
accumulated such a mass of cruft that no two people can agree on what to put
in there.  Whether the resulting mess is wrapped in ASN.1 or XML or EDIFACT or
plastic pooper scooper bags doesn't really make any difference.

Peter.

Re: Low cost cruise missile

[Peter Gutmann]

Steve Schear <[EMAIL PROTECTED]> writes:

>A New Zealand home handyman's bid to construct a cruise missile in his shed
>has made global headlines, and the British media have dubbed him a threat to
>world security.
>
>http://www.theage.com.au/articles/2003/06/05/1054700311550.html

Good grief, what a load of drivel!  I'm sure Bruce will be amused to hear that
the toys he plays with in his spare time are now a threat to world security...
I wonder what his pulsejet-powered go-kart would be classed as?  The
journalist obviously went to a lot of trouble phoning various agencies and
people for comment, but didn't spend 10 seconds with google to see that these
things are commonly available all over the world.

(I think Bruce may have, to some extent, shot himself in the foot a bit by
 presenting it the way he has, although given his talent for self-promotion
 I'm sure it wasn't accidental :-).  Maybe he'll get his funding now.  In any
 case anyone can buy a standard commercially-built jet engine or build their
 own from one of the zillion web pages devoted to this topic and have as much
 of a "cruise missile" as he has.  The guidance system is left as an exercise
 for the reader).

Must have been a really slow news day...

Peter.

Re: Attacking networks using DHCP, DNS - probably kills DNSSEC

[Peter Gutmann]

William Allen Simpson <[EMAIL PROTECTED]> writes:

>Would this be the DHCP working group that on at least 2 occasions when I was
>there, insisted that secure DHCP wouldn't require a secret, since DHCP isn't
>supposed to require "configuration"?

Given that their goal is zero-configuration networking, I can see that being
required to provide a shared secret would mess things up a bit for them.  It'd
be a bit like PKIX being asked to make ease-of-use a consideration in their
work, or OpenPGP to take X.509 compatibility into account.

Peter.

Re: AP by any other name ...

[Peter Gutmann]

Anonymous <[EMAIL PROTECTED]> writes:

>I first ran into this market concept about ten years ago. The Iowa Political
>Stock Market successfully predicted the outcome of the 1992 U.S. presidential
>election within a few tenths of a percentage point for all three candidates
>(including Perot).  It was more accurate than 8 major polls. Since then there
>have been many other experiments with other markets: Hollywood Stock Exchange
>where people bet on future box office receipts and Foresight Exchange where
>traders bet on the outcomes of unresolved scientific and societal questions.

It's been used in other areas as well, and for rather longer than ten years.
For example, one of the most accurate estimates of the entropy of natural
language involved people placing bets on the value of the next letter seen (as
opposed to the more traditional "I guess it'll be an 'e'" estimation
technique).

Peter.

RE: Secure IDE?

[Peter Gutmann]

"Trei, Peter" <[EMAIL PROTECTED]> writes:

>No info on chaining modes, if any, nor of IV handling.

DES/ECB, originally with a 40-bit key, more recently with 56-bit and 3DES.
Keys generated by the manufacturer onto a USB dongle.  No easy way to make
backups of the dongle.  It's a messy tradeoff: If you want something like
laptop/data-theft-protection (which will suit the majority of the market),
then DES-40/ECB is fine, but you want to be able to back up the dongle because
if that goes (and after multiple insertions and removals it will) you've lost
all your data.  OTOH if you want protection from the MIB the fragile nature of
the key storage is probably a benefit, but then you want 3DES/CBC to go with
it.  At the moment you have laptop-theft-protection crypto and MIB-protection
key storage.

You can buy truckloads of these things on ebay for about $20 a pop if you want
to play with one.

Peter.

RE: Secure IDE?

[Peter Gutmann]

"Trei, Peter" <[EMAIL PROTECTED]> writes:
>[EMAIL PROTECTED]:[EMAIL PROTECTED]
>>"Trei, Peter" <[EMAIL PROTECTED]> writes:
>>>with a good distribution of IVs
>>
>>Where would you store them?  The feature of this is that it's fully
>>transparent, so you can't store IVs anywhere.
>
>I'm not really up on crypto file systems, but I beleive at least some use the
>sector address as the IV. IVs don't need to be random, secret, or
>unpredictable - they just need to be unrepeated. (I'm assuming sector-at-a-
>time encryption).

But the IV is repeated, every time you encrypt new data for that sector.  You
need to either store a random IV for each sector (usually infeasible) or make
two passes over the data (details vary), using the output from pass 1 to
affect pass 2 (slow).

>>>* Some kind of PIN or password protection on the dongle.
>>
>>How would you do this without a custom BIOS (remember that their general
>>product is for dropping into any PC)?
>
>We're talking about two different products. The ABIT is a MB, presumably with
>it's own custom BIOS, so that's not an issue there.

Customised, not custom.  Think of it as a Chinese-menu type setup, it's a one-
size-fits-all BIOS with appropriate modules compiled in for handling the CPU
and chipset features.  Now motherboard vendors can plug in their own feature
modules, but it's a somewhat nontrivial option usually used only for highly
marketable features (overclocking options, ability to re-flash from Windows,
etc etc).

Peter.

Re: Ethnomathematics

[Peter Gutmann]

John Bethencourt <[EMAIL PROTECTED]> writes:
>On Wed, Feb 26, 2003 at 10:02:05PM +1300, Peter Gutmann wrote:
>>Well, I made a start a few years ago with "Network Security: A Feminist
>>Perspective" (done when "people ask me to do security talks for them without
>>bothering to specify which aspect of security they want me to talk about")
>>about halfway down my home page.  The direct link to the slides is
>>http://www.cs.auckland.ac.nz/~pgut001/pubs/fhealth.pdf.
>
>Hilarious! I loved it, but it was so short. You should do an extended, in
>depth treatment of this subject in the spirit of Sokal.

I could never maintain that for more than a page or two (although I do have an
upcoming X.509 RFC with a paragraph of two of Marxist philosophy taking the
place of the usual rambling philosophising over why the RFC is needed).  If
someone else wants to take over from/extend the above work, they're welcome
to.

Peter.

Re: Ethnomathematics

[Peter Gutmann]

Bill Stewart <[EMAIL PROTECTED]> writes:

>Actually doing a female-oriented physics or teaching curriculum is fine, if
>somebody can do a good job of it.

Well, I made a start a few years ago with "Network Security: A Feminist
Perspective" (done when "people ask me to do security talks for them without
bothering to specify which aspect of security they want me to talk about")
about halfway down my home page.  The direct link to the slides is
http://www.cs.auckland.ac.nz/~pgut001/pubs/fhealth.pdf.

Peter.

Re: Cavium Security Processor

[Peter Gutmann]

Mike Rosing <[EMAIL PROTECTED]> writes:

>From http://www.cavium.com/newsevents_Nitrox2PR.htm: "Product pricing at 1KU
>lot quantities ranges from $295 for the CN2130 to $795 for the CN2560. The
>NITROX II Software Development Kit is priced at $9995."
>
>Not priced for a huge number of implementors.  They probably hope to sell a
>few hundred develoment kits and maybe 10,000 to 100,000 chips.  They don't
>even put their data sheets online. Maybe they're just a scam?

They're for real all right, and have a pretty nice product, but they've fallen
into the same trap that many smart card vendors fall into where they want to
sell their cards for $20 each but price the SDK at $995 and then wonder why
no-one's supporting their hardware.

(Hint to vendors: The cutoff in most organisations at which implementors have
 to get 15 levels of management approval to get something is $70-100.  If your
 SDK costs more than that, you're practically guaranteeing that it's not going
 to be used.  If you want your hardware supported, give away the SDK, or at
 most charge some token amount to deter freeloaders if you're worried about
 that).

Peter.

Re: Brumley & Boneh timing attack on OpenSSL

[Peter Gutmann]

Bill Stewart <[EMAIL PROTECTED]> writes:

>Schmoo Group response on cryptonomicon.net
>http://www.cryptonomicon.net/modules.php?name=News&file=article&sid=263&mode=&order=0&thold=0
>Apparently OpenSSL has code to prevent the timing attack,
>but it's often not compiled in (I'm not sure how much that's for
>performance reasons as opposed to general ignorance?)

I had blinding code included in my crypto code for about 3 years,
when not a single person used it in all that time I removed it
again (actually I think it's probably still there, but disconnected).
I'm leaning strongly towards "general ignorance" here...

Peter.

Re: "Forest Fire" responsible for a 2.5mi *mushroom cloud*?

[Peter Gutmann]

"J.A. Terranson" <[EMAIL PROTECTED]> writes:

>Wow!  I had no idea ammonium nitrate (ANFO for all intents and purposes,
>yes?) could produce that kind of result!  How much was there?

4,500 tons, of which only 10% detonated.

(The nitrate was desensitised with ammonium sulfate and stored outside,
whenever anyone needed any they'd drill holes and blast off chunks with
dynamite.  Ammonium nitrate has a complex chemical reaction that wasn't really
understood until after the Texas City disaster in 1947, there had previously
been fires in several bulk ammonium nitrate stores without any explosions.  At
Oppau it was assumed that amatol (a standard military explosive, ammonium
nitrate + TNT) had somehow got into the piles and that was what caused the
explosion).

Peter.

Re: Cash, Credit -- or Prints?

[Peter Gutmann]

Alan Barrett <[EMAIL PROTECTED]> writes:

>On Tue, 12 Oct 2004, John Kelsey wrote:
>>but there doesn't seem to be a clean process for determining how
>>skilled an attacker needs to be to, say, scan my finger once, and
>>produce either a fake finger or a machine for projecting a fake
>>fingerprint into the reader.
>
>... or a replacement reader that fakes the signals to the rest of the
>security system.

I've seen a number of smart card/PCMCIA combo devices that to this, they have
a discrete fingerprint sensor device connected to a discrete crypto device.
You can fake out the fingerprint check portion by tying one of the connecting
lines to Vcc or GND.

Peter.

At least there's some (attempt at) common sense in airline security

[Peter Gutmann]

http://www.nzherald.co.nz/storydisplay.cfm?storyID=3600794&thesection=news&thesubsection=general

Ease off says air security boss
15.10.2004

Security on domestic flights is too strict and should be downgraded, says the
head of the Aviation Security Service.

General manager Mark Everitt, a former police detective with 21 years'
experience, said if he had his way passengers would be able to take Swiss Army
knives and other small, sharp objects on board domestic flights.

"I'm actually an advocate for letting these things back on the aircraft. It's
time to back up a little," he told delegates at the Police Association's
annual conference yesterday.

But New Zealand had to meet international security standards and his personal
view was not enough to instigate a review of security standards.

Knowing levels of risk was the key to ensuring flights were safe, said Mr
Everitt. The banning of small knives did not stop attacks in the air.

[...]

Vote-counting glitch in NZ local elections

[Peter Gutmann]

Looks like you can mess up voting even if there is a paper trail.  These are
paper votes that are electronically counted, so the problem was in the
electronic processing, not the actual voting procedure.

http://www.nzherald.co.nz/storydisplay.cfm?storyID=3600391&thesection=news&thesubsection=general&thesecondsubsection=&reportid=1162640

Let me count the ways ...
14.10.2004

[...]

An electronic processing and counting botch-up has left the results for seven
city and district councils and 18 district health boards up in the air. Final
results, due yesterday, have been delayed indefinitely.

Mr Carter blamed the company Datamail, which was contracted by Electionz.com -
the company hired by many councils to manage their elections - to count the
votes from electronically scanned voting papers.

[...]

Peter.

Re: Foreign Travelers Face Fingerprints and Jet Lag

[Peter Gutmann]

"R. A. Hettinga" <[EMAIL PROTECTED]> writes:

>NEWARK, Sept. 30 - Laetitia Bohn walked into Newark Liberty International
>Airport on Thursday, dazed and sleepy after an eight-hour flight from Paris,
>and was jolted from her reverie when an immigration officer asked for her
>photograph and fingerprints along with her passport.

The US now has the dubious distinction of being more obnoxious to get through
the borders than the former East Germany (actually even without this measure,
the checks had become at least as obnoxious as the East German ones).  I
wonder whether the next step will be building a wall...

Peter (who'll be thinking really hard about any future conference trips to the
   US).

Re: Foreign Travelers Face Fingerprints and Jet Lag

[Peter Gutmann]

Steve Furlong <[EMAIL PROTECTED]> writes:
>On Sun, 2004-10-03 at 05:18, Peter Gutmann wrote:
>>The US now has the dubious distinction of being more obnoxious to get through
>>the borders than the former East Germany (actually even without this measure,
>>the checks had become at least as obnoxious as the East German ones).  I
>>wonder whether the next step will be building a wall...
>
>Reign in the overheated rhetoric. The East German state built their wall to
>keep the East Germans from leaving, while the US policies are meant to keep
>out a demonstrated threat.

I never made any comment about who's keeping what in or out (the wall was
officially an anti-fascist protection barrier, also meant to keep out a
demonstrated threat).  What I was pointing out was that having been through
both East German and US border controls, the US ones were more obnoxious.

Peter.

Re: Cyclotrimethylene trinitramine

[Peter Gutmann]

John Young <[EMAIL PROTECTED]> writes:

>Generously, the US government offers a complete set of photos, 
>drawings, process diagrams and descriptions for an RDX manufacturing 
>plant. Library of Congress has the info in its Historic American 
>Engineering Record.

It's not all too hard to make from hexamine (although quite inefficient,
the bulk manufacture isn't done that way) for someone with access to a 
bit of chemical equipment.  I couldn't believe the fuss they're making 
over this, it's just another HE, although more brisant than most.  The 
story is about as interesting as "Stick of dynamite discovered in 
Baghdad parking lot", the media is making it sound like someone's 
absconded with a live nuke.  I guess they couldn't spend the necessary
30 seconds or so it'd take to look it up somewhere and see what was
involved.

Peter.

Re: This Memorable Day

[Peter Gutmann]

Eugen Leitl <[EMAIL PROTECTED]> writes:
>On Tue, Nov 02, 2004 at 08:16:41AM -0500, R. A. Hettinga wrote:
>>
>No cypherpunks content. Just local politics.

And it's not even original, they've mostly just translated it into English,
updated it a bit (e.g. League of Nations -> UN), and changed the Russian names
and references to Middle Eastern ones.

Peter.

Re: This Memorable Day

[Peter Gutmann]

"R.A. Hettinga" <[EMAIL PROTECTED]> writes:
>At 3:32 AM +1300 11/3/04, Peter Gutmann wrote:
>>Eugen Leitl <[EMAIL PROTECTED]> writes:
>>>On Tue, Nov 02, 2004 at 08:16:41AM -0500, R. A. Hettinga wrote:
>>>><http://online.wsj.com/article_print/0,,SB109936293065461940,00.html>
>>>No cypherpunks content. Just local politics.
>>
>>And it's not even original, they've mostly just translated it into English,
>>updated it a bit (e.g. League of Nations -> UN), and changed the Russian names
>>and references to Middle Eastern ones.
>
>Yup. That's Davis' point, actually. Fuck with the West, we kick your ass.

Well it wasn't the point I was trying to make, which was comparing it to
predictions made by (the propaganda division of) another super-power in the
mid 1940s about winning an unwinnable war because God/righteousness/whatever
was on their side, and all they had to do was hold out a bit longer.  Compare
the general tone of the WSJ article to the one in e.g. the first half of
http://www.humanitas-international.org/showcase/chronography/documents/htestmnt.htm.

Peter.

Re: This Memorable Day

[Peter Gutmann]

"R.A. Hettinga" <[EMAIL PROTECTED]> writes:

>Germany 1944 does not equal USA 2004, no matter how hard you twist the
>kaleidoscope.

Fighting an unwinnable war always seems to produce the same type of rhetoric,
whether it's the war on some drugs, the war on anyone Bush doesn't like, or
the war on anything non-German.  The only thing that changes over time are the
identities of the bogeymen that are used to justify it.

(Do you seriously think the war on bogey^H^H^Hterrorism can ever be won?
 Leaving aside the obvious debate that you can't even tell who you're at war
 with, how do you know when you've won?.
 
 We have always been at war with Terroristia)

Peter.

Re: This Memorable Day

[Peter Gutmann]

"James A. Donald" <[EMAIL PROTECTED]> writes:

>But it is hardly a matter of "holding out".  So far the Pentagon has
>shattered the enemy while suffering casualties of about a thousand,

We're talking about different things, the War on Bogeymen vs. the War for Oil.
In its war on bogeymen, the most notable thing the USG has achieved to date is
to create vastly more of them.  Its strategy is about as effective as the
paras were on Bloody Sunday, i.e. its actions serve mostly as a recruitment
drive for the opposition:

  I swear by Almighty God [...] to fight until we die in the field of red gore
  of the infidel tyrants and murderers.  Of our glorious faith, if spared to
  fight until not a single trace is left to tell that the Holy soil of our
  country was trodden by these infidels.  Also these robbers and brutes, these
  unbelievers of our faith, will be driven into the sea, by fire, the knife or
  by poison cup until we of the true faith clear these infidels from our
  lands.

(Whoever wrote the original was definitely no English lit major).

Peter.

Re: In a Sky Dark With Arrows, Death Rained Down

[Peter Gutmann]

"R.A. Hettinga" <[EMAIL PROTECTED]> writes:

>These were not the sort of sporting arrows skillfully shot toward gayly
>colored targets by Victorian archery societies (charmingly described by Mr.
>Soar in later chapters) but heavy "bodkin pointed battle shafts" that went
>through the armor of man and horse.

That's the traditional Agincourt interpretation.  More modern ones (backed up
by actual tests with arrows of the time against armour, in which the
relatively soft metal of the arrows was rather ineffective against the armour)
tend to favour the muddy ground trapping men and horses, lack of room to
manoeuver/compression effects, and arrows killing horses out from under the
knights, at which point see the muddy ground section.  Obviously the machine-
gun effect of the arrows was going to cause a number of minor injuries, and
would be lethal to unarmoured troops, but they weren't quite the wonder-weapon
they're made out to be.

(There were other problems as well, e.g. the unusually high death toll and
 removal of "ancient aristocratic lineages" was caused by English commoners
 who weren't aware of the tradition of capturing opposing nobles and having
 them ransomed back, rather than hacking them to pieces on the spot.  Again,
 arrows didn't have much to do with the loss of so many nobles).

Peter.

Re: This Memorable Day

[Peter Gutmann]

[EMAIL PROTECTED] (=?iso-8859-1?Q?Tiarn=E1n_=D3_Corr=E1in?=) writes:

>The Russians (for example) conquered Hitler's capital, Berlin. And I believe
>the Russian zone in Germany was larger than any of the others, reflecting the
>fact that Stalin bore most of entire burden of defeating Germany,
>uncomfortable as it may be.

The figure that's usually quoted is that 80% of German's military force was
directed against Russia.  Of the remaining 20%, a lot had already been engaged
by France, the UK (via the BEF, the RAF, North Africa), Greece, etc etc before
the US got involved in Europe.  So the Russians should get most of the credit.

Peter.

Re: In a Sky Dark With Arrows, Death Rained Down

[Peter Gutmann]

"James A. Donald" <[EMAIL PROTECTED]> writes:

>I find this very hard to believe.  Post links, or give citations.

Normally I'd dig up various refs, but since this topic has been beaten to
death repeatedly in places like soc.history.medieval, and the debate could
well go on endlessly in the manner of the standard "What would have happened
if the North/South had done X?", I'll just handwave and invite you to dig up
whatever sources you feel like yourself.

>>(There were other problems as well, e.g. the unusually high death toll and
>> removal of "ancient aristocratic lineages" was caused by English
>> commoners who weren't aware of the tradition of capturing opposing
>> nobles and having them ransomed back, rather than hacking them to
>> pieces on the spot.
>
>Wrong
>
>French nobles were taken prisoner in the usual fashion, but executed because
>the English King commanded them executed.

Nobles expected to surrender to other nobles and be ransomed.  Commoners
didn't respect this, and almost never took prisoners.  Henry's orders didn't
make that much difference, at best they were a "we'll turn a blind eye"
notification to his troops.  When you have English commoner men-at-arms (front
row) meeting French nobles (front row, hoping to nab Henry and other for-
ransom nobles, and to some extent because it was unseemly to let the commoners
do the fighting, although they should have learned their lesson for that at
Courtrai) there's going to be a bloodbath no matter what your leader orders.
For the peasants it's "get him before he gets me", not a chivalric jousting
match for the landed gentry.  In addition the enemy nobles had weapons and
armour that was worth something, while a ransom was useless to a non-noble (if
Bob the Archer did manage to captured Sir Fromage, his lord would grab him,
collect the ransom, and perhaps throw Bob a penny for his troubles).

(There's a lot more to it than that, but I really don't want to get into an
 endless debate over this.  Take it to soc.history if you must, and if
 anyone's still interested in debating this there).

Peter.

Re: In a Sky Dark With Arrows, Death Rained Down

[Peter Gutmann]

"James A. Donald" <[EMAIL PROTECTED]> writes:
>Peter Gutmann wrote:
>>Nobles expected to surrender to other nobles and be ransomed.
>>Commoners didn't respect this, and almost never took prisoners.
>>Henry's orders didn't make that much difference, at best they were a
>>"we'll turn a blind eye" notification to his troops.
>
>The english army was well disciplined, and in battle did what it what it was
>told.  About half way through the battle of Agincourt, King Henry decided he
>could not afford so many troops guarding so many prisoners, and told them
>kill-em-all.   Nobility had nothing to do with it.   It did not matter who
>took you prisoner.

As I said in my previous message, this is the topic of endless debate, and in
particular the high death toll among the nobles could arisen from any number
of causes.  For example at Crecy the French king (Philip the something'th) had
the oriflamme (French war banner indicating that no prisoners could be taken)
displayed because he was worried that the gold-rush for enemy nobles to ransom
would screw up the French battle order, resulting in huge losses when the
French ended up at the losing end.  There's speculation that they did the same
thing at Agincourt, because no French chronicler of the time raised even a
murmur about the killings.  So something like that could have been just as
much the cause as any order given by Henry V to dispatch leftovers after the
battle (for example the mass slaughter of the first and second lines
("battles") of French, bogged down in mud (the battle was fought in a rain-
soaked freshly-ploughed field), by English commoners occurred very early in
the battle, while the killing of stragglers under Henry's orders didn't happen
until the following day, or the very end of the battle for prisoners).  If you
really want to continue this, please do it in soc.history medieval, there are
already thousand-odd-message threads going over every nuance of this.

Peter.

Re: This Memorable Day

[Peter Gutmann]

ken <[EMAIL PROTECTED]> writes:
>James A. Donald wrote:
>>  So far the Pentagon has
>> shattered the enemy while suffering casualties of about a thousand,
>> which is roughly the same number of casualties as the British empire
>> suffered doing regime change on the Zulu empire - an empire of a
>> quarter of a million semi naked savages mostly armed with spears.
>
>Be fair. They had a trained and disciplined army. Most of whom
>would obey orders to the death. That's worth a hell of a lot in
>battle.

You also had to look at what they were up against.  Witness the complete
massacre at Isandlwana (the classic Zulu bull-and-horns overran the
British camp because the troops were too far away from their ammunition
to resupply, no doubt copying Elphinstone's tactic in Afghanistan) vs.
post-Isandlwana use of Gatling batteries and massed field artillery 
(some of which was converted Naval artillery), e.g. Ulundi, where 
post-battle reports were of piles of Zulu dead mown down by Gatlings.

The British only thought that the Zulus were just semi-naked savages 
until Isandlwana.

Peter.

Re: Cell Phone Jammer?

[Peter Gutmann]

"Tyler Durden" <[EMAIL PROTECTED]> writes:

>Anyone know from first-hand experience about cellphone jammers?
>
>I need...
>
>1) A nice little portable, and

Try the SH066PL, a nice portable that looks exactly like a cellphone, it's one
of the few portables I know of.

>2) A higher-powered one that can black out cell phone calls within, say, 50
>to 100 feet of a moving vehicle.

Google is your friend, there are tons of these around, with varying degrees of
sophistication.  These are definitely not portable, taking several amps at
6-12V to power them.

None of them are exactly cheap.

Peter.

Re: Anti-RFID outfit deflates Mexican VeriChip hype

[Peter Gutmann]

"R.A. Hettinga" <[EMAIL PROTECTED]> forwarded:

>"Promoting implanted RFID devices as a security measure is downright 'loco,'"
>says Katherine Albrecht. "Advertising you've got a chip in your arm that
>opens important doors is an invitation to kidnapping and mutilation."

Since kidnapping is sort of an unofficial national sport in Mexico (or at
least Mexico City), this is particularly apropos.  An implanted RFID seems to
be just asking for an "express kidnap", something more traditionally used to
get money from ATMs.

Peter.

Re: Unintended Consequences

[Peter Gutmann]

Steve Furlong <[EMAIL PROTECTED]> writes:

>I tried, years before _UC_ came out, to get some friends to name their
>daughter Chlamydia. They didn't know what the word meant, but for some reason
>didn't trust my advice. Nor did they like Pudenda.

One of the characters in Hercules Returns is called Labia, and lives in the
town of Chlamydia.  There are a number of other characters with similar names.

Peter.

uATX motherboard with built-in crypto

[Peter Gutmann]

I just noticed that ABIT have a nice uATX motherboard with a built-in Cavium
crypto engine "capable of processing up to 400Mbps of IPSec traffic or 3,500
RSA operations per second".  Details at
http://www.abit-usa.com/products/servers/products.php?categories=4&model=69.

Peter.

Re: Call to the Usual Suspects

[Peter Gutmann]

"Trei, Peter" <[EMAIL PROTECTED]> writes:

>I'll be in the SF/SJ area the week of the RSA conference. Anyone interested
>in getting together for dinner one night?

Do these things actually get organised?  I thought you just bump into other
Cpunks via the usual Brownian motion and at some point someone suggests a
place to go, half the participants slope off to an alternative establishment
on the way there, and that's how dinner gets arranged.

Peter.

Re: FCC vs decentralization

[Peter Gutmann]

Eugen Leitl <[EMAIL PROTECTED]> writes:
>On Fri, Feb 13, 2004 at 04:36:56PM +0100, Thomas Shaddack wrote:
>> FCC recently mandated fees for Internet radio "broadcasters", based on the
>
>You're hailing from .cz, me from .de. Of what relevance is FCC to us?

The RIAA/MPAA and US govt.are working on that.  Stand by.

Peter.

Re: Earthlink to Test Caller ID for E-Mail

[Peter Gutmann]

"R. A. Hettinga" <[EMAIL PROTECTED]> writes:

>If we really do get cryptographic signatures on email in a way that works,
>expect 80% of all spam to be blown away as a matter of course.

I think you mean:

  If we really do get cryptographic signatures on email in a way that works,
  expect 80% of all spam to contain legit signatures from hacked PCs.

This is just another variation of the "To secure the Internet, build a big
wall around it and only let the good guys in" idea.

Peter.

Re: Earthlink to Test Caller ID for E-Mail

[Peter Gutmann]

Eugen Leitl <[EMAIL PROTECTED]> writes:

>"A way that works" would involve passphrase-locked keyrings, and forgetful
>MUAs (this mutt only caches the passphrase for a preset time).

"A way that works *in theory* would involve ...".  The chances of any vendor
of mass-market software shipping an MUA where the user has to enter a password
just to send mail are approximately... zero.

>Filtering for signed/vs. unsigned mail doesn't make sense, authenticating and
>whitelisting known senders by digital signature makes very good sense.

In that case you can just filter by sender IP address or something (anything)
that's simpler than requiring a PKI.  Again though, that's just another
variant of the "Build a big wall" dream.  In order to have perimeter security
you first need a perimeter.  If the spammer you're trying to defend against is
your own mother (because she clicked on an attachment you sent her, it says so
in the From: address, that's actually a spam-bot), you don't have a perimeter.
All you have is a big pile of Manchurian candidates waiting to bite you.

Peter.

Re: Fortress America mans the ramparts

[Peter Gutmann]

"Major Variola (ret)" <[EMAIL PROTECTED]> writes:

>PS: what happens if your passport's chip doesn't work?   Do you get sent back
>and the airline fined $10K?  Do you wait extra time while the still-readable
>passport number indexes your record online? How much extra time?  (Anyone
>have experience with domestic eg traffic pigs discovering that your magstrip
>is corrupted?)
>
>Are all chip biometrics encrypted with the same key?  How much does that cost
>on BlackNet these days?How much extra should our Seals Flaps and
>Documents dept charge?

Details are available from sources like
http://www.icao.int/mrtd/download/documents/Biometrics%20deployment%20of%20Machine%20Readable%20Travel%20Documents.pdf
and
http://www.icao.int/mrtd/download/documents/PKI%20Digital%20Signatures.PDF
(in general the docs are at http://www.icao.int/mrtd/download/documents/,
where MRTD = machine-readable travel documents) although you have to be
careful what you reference since they're still frantically updating the
designs as they go, so any document will be out of date in a few months.  It's
also being (as far as I can tell) designed by people with little or no
security experience, under intense pressure from the US to Do Something About
Security.  Early technical drafts I saw (not the generic whitepapers on the
site, which are pretty vague) were an appalling pile of kludgery.  From what
I've heard since then it hasn't gotten any better.  I dunno whether this is
because the work is being contracted out to the Usual Suspects, who don't know
much about the area, or whether they did try and get experienced people in and
were told that what they were trying to do wouldn't work and/or couldn't be
done in less than 5-10 years.

Peter.

Re: Partition Encryptor

[Peter Gutmann]

"Stirling Westrup" <[EMAIL PROTECTED]> writes:

>Does anyone know of a good partition encryptor for Windows? I know of an
>accountant who would like to encrypt her client's financial data. She's stuck
>with Windows until such time as a major company starts shipping yearly tax
>software for linux.
>
>Something like PGPdisk, only open source, would be best.

ScramDisk (Win9x) or E4M (Win2K) will do it if she can handle a container-
volume encryptor rather than a partition encryptor, both are open source.  E4M
needs some minor updates for XP by someone who knows about NT device drivers,
otherwise you'll occasionally get problems unmounting volumes.

Peter.

RE: C3 Nehemia C5P with better hardware RNG and AES support

[Peter Gutmann]

coderman <[EMAIL PROTECTED]>

>I have written some poor code and info regarding the C5XL (nehemiah) and
>linux:
>
>http://peertech.org/hardware/viarng/

I've got code to use it under Windows in the latest cryptlib snapshots (soon
to be the 3.1 release), which you can grab via the download link at
http://www.cs.auckland.ac.nz/~pgut001/cryptlib/index.html.  The RNG code is in
misc/rndwin32.c, and is available under a dual license (BSD or GPL, your
choice).  Note though that I don't actually have a C5XL to play with, so at
the moment I've only been able to verify that it won't crash when run on AMD
and Intel CPUs.  If anyone has a C5XL with Windows installed, I'd be
interested in hearing about any problems.

Peter.

RE: [Asrg] Re: [Politech] Congress finally poised to vote on anti -spam bill [sp]

[Peter Gutmann]

"Hallam-Baker, Phillip" <[EMAIL PROTECTED]> writes:

>DNSSEC is not happening, blame Randy Bush and the IESG for refusing the
>working group consensus and imposing their own idea that cannot be deployed.
>An experimental protocol that increases the volume of data in the .com zone
>by an order of magnitude (read Gbs of data) is simply unacceptable.

Do you have any more details on this for those who don't normally follow
DNSSEC?

Peter.

Re: U.S. in violation of Geneva convention?

[Peter Gutmann]

Nomen Nescio <[EMAIL PROTECTED]> writes:

>After WWI the "winners" humiliated the loosers badly. This is one of the main
>reasons Hitler came to power and got support from the Germans for the
>aggressions that started the war. He managed to use these feelings of being
>treated as dogs and paying to heavy for the first war. Also they were very
>humiliated by the fact that France then occupied part of western Germany.
>
>After WWII the "winners" had learned their lesson from WWI pretty well. Now
>they did not humilate the people of Germany like after the first war. We got
>the Mar shal plan and so on.

Unfortunately after GulfWarII the "winners" hadn't learned their lessons from
WWII very well.  At the end of the war, despite the bombing campaigns, Germany
had a vaguely functional administration and (heavily rationed) food, coal,
electricity, etc were available.  The Allies systematically dismantled all of
that, both through apathy (no real planning beyond "Move in and occupy the
place") and their zeal to rebuild the country in their own image.  For
example, they prevented anyone who'd ever been a Nazi party member from doing
their job.  Well the problem was that to do almost anything, you had to be a
party member, so they instantly stopped all civil administration,
engineering/maintenance work, teachers, the judicial system, the police, you
couldn't even deliver the mail without being a party member (since they were
government employees).

Virtually every male over the age of about 16 had been in the military and had
experience with weapons.  So you now had a mass of unemployed ex-military who
desperately wanted food and clothing, and had access to an almost infinite
supply of weaponry.  In addition Germany after the war attracted what one of
the allied leaders (Eisenhower?) described as "the scum of Europe", eager to
make a quick buck (in Iraq it's folks eager to beat up the infidels).  This
lead to sizeable pitched battles between the armed gangs and the occupying
military, with the military frequently being outgunned by the gangs.

Substitute Germany -> Iraq and profit / food -> religion /nationalism and the
same situation exists today.

Peter.

RE: RSA performance on Athlon64 vs. Itanium

[Peter Gutmann]

"Lucky Green" <[EMAIL PROTECTED]> writes:

>I since ran additional tests. All tests are for 1024-bit RSA signatures.

Taking some guesses here at the code being used:

>1) OpenSSL as shipping with the RedHat Taroon beta for Athlon 64:
>
>921 RSA signatures/second

x86-32 hand-tuned asm optimised for Pentium Pro.

>2) OpenSSL compiled manually:
>
>1313 RSA signatures/second

x86-64 code, gcc optimised for Athlon64.

>3) Performance benchmark application made available to reviewers:
>
>Exceeding 3800 RSA signatures/second.

x86-64 hand-tuned asm optimised for Athlon64.  I'm guessing this one has the
same catch as the Itanium speed test.

>I am getting ready to buy a second one to upgrade my other box at home.

My PoS hardware test PC and a $25 Broadcom chip beats your Athlon 64 :-).

Peter.

Re: RSA performance on Athlon64 vs. Itanium

[Peter Gutmann]

"J.A. Terranson" <[EMAIL PROTECTED]> writes:
>On Sun, 12 Oct 2003, Lucky Green wrote:
>> I just picked up an Athlon64 3200+, which runs at a 2 GHz clock speed.
>> Using the Red Hat for AMD64 beta and the version of OpenSSL that ships
>> with that beta, I get 922 1024-bit RSA signs per second. This is a tad
>> less RSA signatures per second than I have seen on an 800MHz Itanium
>> using highly optimized assembler. That's rather poor performance on the
>> Athlon64.
>>
>> Are the figures that I am seeing typical for OpenSSL on the Athlon64?
>> Has anybody here seen different figures using optimized code?
>
>Was there ever a reply to this?  If so, could someone forward it to me off-
>list, as I missed it :-(

The reply, sent off-list, was something like "You're running x86-32 code on an
x86-64 CPU in emulation mode, what do you expect?" :-).  In addition the
Itanium RSA demo code works by turning the CPU into a $1000 ASIC, so you'd
need to test it for SSL handshakes per second or something similar where the
CPU has to do some other work besides RSA crypto ops.

Peter.

RE: C3 Nehemia C5P with better hardware RNG and AES support

[Peter Gutmann]

"Lucky Green" <[EMAIL PROTECTED]> writes:
>Peter wrote:
>> In case anyone's interested, there's a cpu die photo at
>> http://www.sandpile.org/impl/pics/centaur/c5xl/die_013_c5p.jpg
>> showing the amount of real estate consumed by the crypto functions
>> (it's the bottom centre, a bit hard to read the label).
>
>I fail to understand why VIA bothered adding AES support into the CPU. When
>was AES last the bottleneck on a general-purpose CPU? 

Apart from the obvious "what cool thing can we fit in -> <- this much spare
die space?", the obvious target is SOHO routers/firewall boxes.  My spies tell
me that it's already being used in a number of products like this, and the
addition of AES will help the process.  Hardware SHA-1 in the next rev makes
it even better, since you can now do IPsec and SSL tunneling purely in
hardware (and then you lose it all again in the crappy Rhine II NIC, but
that's another story).

>The bottleneck tends to be modular exponentiations, yet VIA failed to include
>a modular exponentiation engine. Strange.

Not for SOHO use it isn't, the initial handshake overhead is negligible
compared to the constant link encryption overhead.  The alternative is to do
the crypto externally, for which you're paying for an expensive and power-
hungry crypto core capable of doing a zillion DH/RSA ops/sec that gets used
once every few hours.  The alternative is to load or load your standard
firewall firmware into a Nehemiah and offload all the crypto and RNG stuff.

Peter.

Re: C3 Nehemia C5P with better hardware RNG and AES support

[Peter Gutmann]

"Ralf-P. Weinmann" <[EMAIL PROTECTED]> writes:

>Look at the PadLock ACE programming guide

The security app note is also entertaining reading.  For example it lists one
of the motivations for getting security right as "your husband may find out
...".  On why they didn't save a copy of the test data for the NIST suite:
"(Hey, do you have 10TB of disk drives lying around? We can fill a 30 GB drive
with raw bits in a little more than 30 minutes - if the drive controller can
keep up with us.)".  And a little further on it refers readers to "Marketing
quote from CRI" (which was a slip-up this time).  The app note was actually
written by humans.  Cool.

Peter.