Re: [Cryptography] AES-256- More NIST-y? paranoia

2013-10-08 Thread Bill Stewart

On Oct 4, 2013, at 12:20 PM, Ray Dillinger wrote:
 So, it seems that instead of AES256(key) the cipher in practice should be
 Is it not the case that (assuming SHA256 is not broken) this 
defines a cipher

 effectively immune to the related-key attack?

So you're essentially saying that AES would be stronger if it had a 
different key schedule?

At 08:59 AM 10/5/2013, Jerry Leichter wrote:

- If this is the primitive black box that does a single block
  encryption, you've about doubled the cost and you've got this
  messy combined thing you probably won't want to call a primitive.

You've doubled the cost of key scheduling, but usually that's more like
one-time than per-packet.  If the hash is complex, you might have
also doubled the cost of silicon for embedded apps, which is more of a problem.

- If you say well, I'll take the overall key and replace it by
  its hash, you're defining a (probably good) protocol.  But
  once you're defining a protocol, you might as well just specify
  random keys and forget about the hash.

I'd expect that the point of related-key attacks is to find weaknesses
in key scheduling that are exposed by deliberately NOT using random keys
when the protocol's authors wanted you to use them.

The cryptography mailing list

Re: [Cryptography] TLS2

2013-10-01 Thread Bill Stewart

At 02:27 PM 9/30/2013, James A. Donald wrote:

On 2013-09-30 18:02, Adam Back wrote:

If we're going to do that I vote no ASN.1, and no X.509.  Just BNF format
like the base SSL protocol;

Granted that ASN.1 is incomprehensible and horrid, but, since there 
is an ASN.1 compiler that generates C code we should not need to comprehend it.

Unfortunately, you have to be able to comprehend all of the failure 
modes and attacks on ASN.1.

The object descriptions themselves are a bit bloaty, with their main 
weakness being that either

you have to get permission to attach your data into the official tree,
or else do a vendor-specific branch, but they're not all that broken.
It's the data representations that map them into binary strings that are a
wretched hive of scum and villainy, particularly because you can't depend on a
bit string being able to map back into any well-defined ASN.1 object
or even any limited size of ASN.1 object that won't smash your stack or heap.
The industry's been bitten before by a widely available open source library
that turned out to be vulnerable to maliciously crafted binary strings
that could be passed around as SNMP traps or other ASN.1-using messages.

Similarly, PGP's most serious security bugs were related to
variable-length binary representations that were trying to steal bits
to maximize data compression at the risk of ambiguity.
Scrounging a few bits here and there just isn't worth it.

The cryptography mailing list

Re: [Cryptography] Thoughts on hardware randomness sources

2013-09-14 Thread Bill Stewart

At 08:32 PM 9/13/2013, Jerry Leichter wrote:
If by server you mean one of those things in a rack at Amazon or 
Google or Rackspace - power consumption, and its consequence, 
cooling - is *the* major issue these days.  Also, the servers used 
in such data centers don't have multiple free USB inputs - they may 
not have any.

More to the point, the servers in the data centers aren't going to 
let you plug things in to them, especially if you're just renting a 
virtual machine or cloud minutes and don't get to connect to the real 
hardware at all (which also means you're not going to be able to use 
disk drive timing.)
A tablet computer has lots of sensors in it; even turning the cameras 
on at boot time and hashing the raw pixels should give you a 
reasonable chunk of entropy; you're not going to turn your virtual 
machine upside down and shake it like an Etch-A-Sketch.

I realize it's possible for somebody to try to manipulate this, but 
I've always assumed that ethernet packet timing ought to give you 
some entropy even so, and even though with virtual machines you may 
only get quantized versions of interrupt times.  Startup processes 
are probably going to include pinging a router and a name server, or 
at least they could if you wanted.

The cryptography mailing list

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

2013-09-11 Thread Bill Stewart

At 10:39 AM 9/11/2013, Phillip Hallam-Baker wrote:
Perfect Forward Secrecy is not perfect. In fact it is no better than 
regular public key. The only difference is that if the public key 
system is cracked then with PFS the attacker has to break every 
single key exchange and not just the keys in the certificates and if 
you use an RSA outer with an ECC inner then you double the 
cryptanalytic cost of the attack (theory as well as computation).

I wouldn't mind if it had been called Pretty Good Forward Secrecy 
instead, but it really is a lot better than regular public key.
The main difference is that cracking PFS requires breaking every 
single key exchange before the attack using cryptanalysis, while 
cracking the RSA or ECC outer layer can be done by compromising the 
stored private key, which is far easier to do using subpoenas or 
malware or rubber hoses than cryptanalysis.

(Of course, any messages that were saved by the sender or recipient 
can still be cracked by non-cryptanalytic techniques as well, but 
that's a separate problem.)

The cryptography mailing list

Re: [Cryptography] Bruce Schneier has gotten seriously spooked

2013-09-08 Thread Bill Stewart

At 12:09 PM 9/7/2013, Chris Palmer wrote:

On Sat, Sep 7, 2013 at 1:33 AM, Brian Gladman wrote:

 Why would they perform the attack only for encryption software? They
 could compromise people's laptops by spiking any popular app.

 Because NSA and GCHQ are much more interested in attacking communictions
 in transit rather than attacking endpoints.

So they spike a popular download (security-related apps are less
likely to be popular) with a tiny malware add-on that scans every file
that it can read to see if it's an encryption key, cookie, password

More to the point, spike a popular download with remote-execution malware,
and download spiked patches for important binaries,
so the not-a-collection-target's browser uses known keys
(the opposite of the fortify patch that made 40-bit Mozilla do 128-bit),
and the disk encryption software broadcasts its keys or stashes them 
in plaintext

The cryptography mailing list

Re: [Cryptography] In the face of cooperative end-points, PFS doesn't help

2013-09-07 Thread Bill Stewart

At 06:49 PM 9/6/2013, Marcus D. Leech wrote:
It seems to me that while PFS is an excellent back-stop against NSA 
having/deriving a website RSA key, it does *nothing* to prevent the kind of
  cooperative endpoint scenario that I've seen discussed in other 
forums, prompted by the latest revelations about what NSA has been up to.
But if your fave website (gmail, your bank, etc) is disclosing the 
session-key(s) to the NSA,

Depends a lot on how cooperative they are.  It's much easier to get a 
subpoena/secret-order/etc. for business records that a company 
keeps, which may include the long-term key, than to get one for 
transient session keys that their software doesn't keep.  Doesn't 
mean they can't do it, but it's probably much easier to get an order 
to produce plaintext, especially for a company like a bank or email 
service where the plaintext is something they would be keeping, at 
least briefly, as a business record anyway.

Do we now strongly suspect that NSA have a flotilla of TWIRL (or 
similar) machines, so that active cooperation of websites isn't 
strictly necessary

  to derive their (weaker) RSA secret keys?

Unlikely - the economics are still strongly against that.  Keeping a 
fleet of key cracking machines to grab long-term private keys from 
high-value targets might make sense, but each long-term key gets used 
to protect thousands or millions of transient session keys.  If they 
have 1024-bit RSA crackers at all, unless there's been a radical 
breakthrough in factoring, they're still not fast.

I've always preferred RSA-signed Diffie-Hellmann to encrypted 
session-key transfer when it's practical.  The long-term keys only 
get used for signatures, so if they're compromised they can only be 
used to impersonate the endpoints, not to read previous sessions, and 
under less-than-NSA versions of due process, it's a lot easier to 
argue in court against a police agency that wants to impersonate you 
than one that wants a copy of a transaction.

The cryptography mailing list

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

2013-09-07 Thread Bill Stewart

On 7/09/13 09:05 AM, Jaap-Henk Hoepman wrote:
Public-key cryptography is less well-understood than symmetric-key 
cryptography. It is also tetchier than symmetric-key crypto, and 
if you pay attention to us talking about issues with nonces, 
counters, IVs, chaining modes, and all that, you see that saying 
that it's tetchier than that is a warning indeed.

You have the same issues with nonces, counters, etc. with symmetric 
crypto so I don't see how that makes it preferable over public key crypto.

At 12:57 AM 9/7/2013, ianG wrote:
It's a big picture thing.  At the end of the day, symmetric crypto 
is something that good software engineers can master, and relatively 
well, in a black box sense.  Public key crypto not so easily, that 
requires real learning.  I for one am terrified of it.

Public-key crypto requires learning math, and math is hard (or at 
least ECC math is hard, and even prime-number-group math has some 
interesting tricks in it.)
Symmetric-key crypto is easy in a black-box sense, because most 
algorithms come with rules that say You need to do this and not do 
that, yet the original PPTP did half a dozen things wrong with RC4 
even though the only rule is never use the same state twice.
But if you want to look inside the black box, most of what's there is 
a lot of bit-twiddling, maybe in a Feistel network, and while you can 
follow the bits around and see what changes, there can still be 
surprises like the discovery of differential cryptanalysis.
Public-key crypto lets you use math to do the analysis, but [vast 
over-simplification] symmetric-key mostly lets you play around and 
decide if it's messy enough that you can't follow the bits.

But there are other traps that affect people with either kind of 
system.  Once PGP got past the Bass-o-matic stage, the biggest 
security problems were mostly things like variable-precision numbers 
that were trying so hard to save bits that you could trick the 
program into interpreting them differently and accepting bogus 
information.  Fortunately we'd never have problems like that today 
(yes, ASN.1 BER/DER, I'm looking at you), and nobody ever forgets 
to check array bounds (harder in modern languages than in C or 
Fortran, but still quite possible), or fails to validate input before 
using it (SQL injections), etc.

The cryptography mailing list

Re: [Cryptography] FIPS, NIST and ITAR questions

2013-09-04 Thread Bill Stewart

At 03:06 PM 9/3/2013, Jerry Leichter wrote:

On Sep 3, 2013, at 3:16 PM, Faré wrote:
 Can't you trivially transform a hash into a PRNG, a PRNG into a
 cypher, and vice versa?
I don't actually know if there exists a 
construction of a PRNG from a cryptographically 
secure hash function.  (You can build a MAC, but 
even that's not trivial; people tried all kinds 
of things that failed until the HMAC construction was proven correct.)

PRNG is not necessarily a cryptographically 
strong term.  But isn't counter-mode hash likely to be ok?

Counter = seed;
while (counter++) Output(Hash(counter));
// or as somebody said Output(Hash(seed||counter||seed));
// and you probably need to pad 
it to be long enough for the hash to be happy.

Obviously if somebody discovers the seed the whole thing is toast.

And you can turn the PRNG into a stream cypher by 
doing plaintext[x] xor PRNG[x], with the usual limitations.

None of that has any bearing on ITAR, of course.

The cryptography mailing list

Re: [Cryptography] IPv6 and IPSEC

2013-09-03 Thread Bill Stewart

At 01:53 PM 8/29/2013, Taral wrote:

Oh, wait. I misread the requirement. This is a pretty normal
requirement -- your reverse DNS has to be valid. So if you are
3ffe::2, and that reverses to, then
better resolve to 3ffe::2.

For IPv4, that's a relatively normal way to do things,
though if is commercial, might actually be a load-balanced bunch of servers 
in xx.yy.zz.0/24

instead of just one machine, or they might be hidden behind NAT.

But with IPv6 privacy extensions, a single machine might be using
pseudorandomly-generated addresses in a /64 subnet,
so you'd have to do some kind of wildcarding to represent it as a single name.
Also, residential vs. commercial is a much fuzzier boundary for IPv6;
an IPv6 machine might be a VM tunnelling to Hurricane Electric over IPv4,
or tunnelled from a residence to a DSL ISP that can only do telco DSL at IPv4.

The cryptography mailing list

Re: [Cryptography] Using Raspberry Pis

2013-08-27 Thread Bill Stewart

Custom built hardware will probably be the smartest way to go for an
entrepreneur trying to sell these in bulk to people as home gateways anyway

Meanwhile, while Phill may have spent $25 for a USB Ethernet, I 
frequently see them on sale for $10 and sometimes $5.

The cryptography mailing list

Re: Haystack (helping dissidents?)

2010-09-29 Thread Bill Stewart

On Thu, Sep 16, 2010 at 04:49:19PM +, M.R. wrote:
| I said (something like) this when Haystack first appeared on this
| list...
| Words dissidents and oppressive regimes have no place in
| serious discussions among cryptographers. Once we start assigning
| ethical categorizations to those that protect and those that attack
| (data files, communications channels, etc.) we are watering the
| garden in which the weeds like Haystack flourish.

They do tell you what level of attack you're trying to block.
There's spammers trying to crack your system for money,
but then there's a national government that doesn't like you,
though I suppose it's possible that if you're not annoying
one of the top ten governments, you might get a larger attack by annoying 

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

Stanford 10/7/2010 -- Lessons from the Haystack Affair

2010-09-29 Thread Bill Stewart

Potentially interesting lecture if you're in the Bay Area

Subject: Liberation Technology 10/7/2010 -- Lessons from the Haystack Affair
Date: Mon, 27 Sep 2010 13:40:55 -0700 (PDT)


The Stanford Program on Liberation Technology Seminar Series is starting
up again. The first of the series will be held on Sept 23, 4:30pm
at Wallenberg Hall. As an EE380 attendee you may find this series of
lectures at the cust of Computer Science, Electrical Engineering, and
Social Science his stimulating and informative series.

  Lessons from the Haystack Affair

October 7, 2010
4:30 PM - 6:00 PM
Wallenberg Theater
Wallenberg Hall
450 Serra Mall, Building 160


Haystack, a circumvention tool, emerged in the wake of
the repression after the Iranian election of June 2009.
After achieving considerable public prominence, its use and
distribution was recently halted. Important questions have
been raised about Haystack's effectiveness and security,
as well as the roots of its reputation.

Evgeny Morozov, who emerged as a leading critic of Haystack,
and Daniel Colascione, who wrote the Haystack code, will
discuss the Haystack experience and the lessons it carries for
circumvention technologies and, more broadly, for the evaluation
and political deployment of new information technologies.

Daniel Colascione co-founded the Censorship Research Center
in June 2009 in the aftermath of the Iranian election and has
had a lifelong interest in internet freedom and technological
measures to mitigate censorship.  He created the Haystack
anti-censorship system and holds a BSc in Computer Science
from the SUNY University at Buffalo.


Evgeny Morozov is a leading thinker and commentator on the
political impact of the Internet and a well known opponent
of internet utopianism.  He is a contributing editor to
Foreign Policy and runs the magazine's Net Effect blog
about the Internet's impact on global politics. Evgeny is
currently a Yahoo! fellow at the Institute for the Study of
Diplomacy at Georgetown University. Prior to his appointment
to Georgetown, he was a fellow at the Open Society Institute,
where he remains on the board of the Information Program. Before
moving to the US, Evgeny was based in Berlin and Prague, where
he was Director of New Media at Transitions Online, a media
development NGO active in 29 countries of the former Soviet
bloc. He is writing a book about the Internet and democracy,
to be published this fall by Public Affairs.

Open to the public
No RSVP required

For more information on the Program on Liberation Technology go to-

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

Re: 2048-bit RSA keys

2010-08-16 Thread Bill Stewart

At 01:54 PM 8/16/2010, Perry E. Metzger wrote:

On Mon, 16 Aug 2010 12:42:41 -0700 Paul Hoffman wrote:
 At 11:35 AM +1000 8/16/10, Arash Partow wrote:
 Just out of curiosity, assuming the optimal use of today's best of
 breed factoring algorithms - will there be enough energy in our
 solar system to factorize a 2048-bit RSA integer?

 We have no idea. The methods used to factor number continue to
 slowly get better,[...]

He asked about today's best of breed algorithms, not future ones. In
that context, and assuming today's most energy efficient processors
rather than theoretical future processors, the question has a concrete

With today's best-of-breed algorithms and hardware designs,
there isn't enough money in the economy to build a machine
that comes close to making a scratch in the surface of
that kind of energy consumption, whether for factoring or
for simple destruction.

Basically, 2048's safe with current hardware
until we get some radical breakthrough
like P==NP or useful quantum computers,
and if we develop hardware radical enough to
use a significant fraction of the solar output,
we'll probably find it much easier to eavesdrop
on the computers we're trying to attack than to
crack the crypto.

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

Re: A mighty fortress is our PKI, Part II

2010-07-31 Thread Bill Stewart

At 07:16 AM 7/28/2010, Ben Laurie wrote:

SSH does appear to have got away without revocation, though the nature
of the system is s.t. if I really wanted to revoke I could almost
always contact the users and tell them in person. This doesn't scale
very well to SSL-style systems.

Unfortunately, there _are_ ways that it can scale adequately.
Bank of America has ~50 million customers,
so J. Random Spammer sends out 500 million emails saying
Bank of America is updating our security procedures,
please click on the following link to update your browser.
It's more efficient for BofA to send out the message themselves,
only to actual subscribers, with the actual keys,
helping to train them to accept phishing mail in the process,
but apparently even doing it the hard way scales well enough for some 
people to make money.

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

Re: Possibly questionable security decisions in DNS root management

2009-10-25 Thread Bill Stewart

At 12:14 PM 10/22/2009, David Wagner wrote:

Back to DNSSEC: The original criticism was that DNSSEC has covert
channels.  So what?  If you're connected to the Internet, covert
channels are a fact of life, DNSSEC or no.  The added risk due to any
covert channels that DNSSEC may enable is somewhere between negligible
and none, as far as I can tell.  So I don't understand that criticism.

I thought it was also that DSA had covert channels,
but I also don't see why that's as relevant here,
and I share Dave's skepticism about threat models.
It's unlikely that DNSSEC will let you do anything any more heinous
than Dan Kaminsky's streaming-video-over-DNS hacks have already done.

There are two obvious places that data can be leaked -
the initial key signature process, and the DNS client/server process.
If the people who certify the root or TLDs can't be trusted,
the number of those people is small enough that they can simply
send the secret data to their unindicted co-conspirators
without all the trouble of hiding it in a covert channel on a very public 
DNS server.

And if Bad Guys have compromised the software used in a DNS server,
while they could be subtle and hide data in DSA signatures of DNS records,
it would be much easier to just send it as data if the query
has the evil bit set or asks for or whatever.
There's plenty of room in the formats even without DSA.

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

Re: XML signature HMAC truncation authentication bypass

2009-07-29 Thread Bill Stewart

At 05:11 PM 7/27/2009, Jon Callas wrote:

By the way, do you think it's safe to phase out MD5?
That will break all the PGP 2 users.

Depends - if you're only replacing it with SHA-1, it's probably not 

And if you're breaking things anyway, might as well replace most of the
bit-twiddling variable-length number field types with 32-bit-word-aligned 

but nobody listened to me rant about that a decade ago :-)

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

Re: Proof of Work - atmospheric carbon

2009-01-31 Thread Bill Stewart

At 10:40 AM 1/30/2009, Thomas Coppi wrote:

 Just out of curiosity, does anyone happen to know of any documented
examples of a botnet being used for something more interesting than
just sending spam or DDoS?

There are good botnets and bad botnets.
Good ones ask you if you want to join, bad ones don't.
Good ones are typically things like s...@home, fold...@home,
Great Internet Mersenne Prime Search,  DES crackers, etc.,
and if you've got something good to do, people will help.
People usually only set up the bad ones
if they want to do something bad - it may be interesting the
first time they do it, like a new flavor of DDOS,
but it's not usually doing the world any favors.

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

Re: the skein hash function

2008-10-30 Thread Bill Stewart

Eugen Leitl and Stephan Somogyi [EMAIL PROTECTED] wrote
about the Skein hash function announcement.

One thing I noticed on a first read-through was
a discussion of speed for ASICs vs. general CPUs.
Their implementation on CPUs was about 4 Gbps/core,
and their estimate of ASIC speed was about 5 Gbps
using about 80K gates worth of ASIC,
and their hash-tree mode makes parallelization efficient.
Their conclusion was that ASICs don't give you
much of a speedup, but may save power or cost.

A quick google-look at ASICs showed a number
in the range of 300K-20M gates,
so hash-trees could probably get speedups of up to 20-100x
if you can keep from becoming input-speed-bound.
The 300K chips were about $6, 5M at $50 and 350MHz,
which is somewhat faster than the Skein team estimate,
and some of the denser chips didn't mention price
but were starting to use 45nm technology.
So if Skein becomes popular, ASIC accelerator hardware
may be practical for higher-speed applications.

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

Re: combining entropy

2008-10-29 Thread Bill Stewart

This isn't enough.  Somehow, you have to state that the values emitted
on demand in any given round i (where a round consists of exactly one
demand on all N member and produces a single output result) cannot
receive any input from any other members.  Otherwise, if N=2 and member
0 produces true random values that member 1 can see before it responds
to the demand it received, then member 1 can cause the final result to
be anything it likes.

In the case of malicious members who can snoop the inputs,
Mal can get any result he wants if the combining function is XOR
(or, with slightly more work, if it's a non-cryptographic checksum.)
But if your combining function is a cryptographic hash,
it's computationally difficult to do.

However, even a hash isn't always enough - consider the case
where the application of the random numbers only uses k of the N bits,
and the attacker has enough time to try out 2**k (waving hands roughly here)
different cases.  So you may still need to design your protocols carefully.

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

Re: On the randomness of DNS

2008-07-31 Thread Bill Stewart

 Ben wrote:

  But just how GREAT is that, really? Well, we don'
  t know. Why? Because there isn't actually a way test for randomness. Your
 DNS resolver could be using some easily predicted random number generator
 like, say, a linear congruential one, as is common in the rand() library
 function, but DNS-OARC would still say it was GREAT.

At 11:57 AM 7/30/2008, Pierre-Evariste Dagand wrote:

Well, they are some tests to judge the quality of a random number
generator. The best known being the Diehard tests:

Random number quality is contextual.
In this case, for 95-99% of the market, the real test is between
Patched Badly Broken Not patched yet Didn't need patching,
and if you'd prefer the term Best we can do until DNSSEC
instead of GREAT I won't be the one to argue with you.

There are some other possible conditions, like
Rolled their own with open source, badly
or  Maliciously subtle malware DNS resolver.
The latter is way too much work compared to cruder approaches
(like targeting queries directly to your evil DNS server).
The former is not too common, though it probably exists,
but once most systems get patched,
it may not be a big enough target to interest crackers.

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

Re: Toshiba shows 2Mbps hardware RNG

2008-02-10 Thread Bill Stewart

At 07:02 PM 2/9/2008, Peter Gutmann wrote:

I've always wondered why RNG speed is such a big deal for anything but a few
highly specialised applications.  For security use you've got two options:
1. Use it with standard security protocols, in which case you need all of 128
   or so bits every now and then (and very rarely a few thousand bits for
   asymmetric keygen).

One obvious application I can think of is Diffie-Hellman session key generation
for web or email servers that handle lots of sessions.
Sure, you _could_ use PRNGs to generate the keys, with real RNG now and then,
but a fast RNG can help protect you against one popular threat model, which 
is auditors.

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

Re: Changes in Russian licensing of cryptraghical tools

2008-01-21 Thread Bill Stewart

At 12:23 AM 1/20/2008, Alexander Klimov wrote:

Given what is required to get a license (for example, 4.b in the
first document, says that one must have people trained in
information security), I guess the new law is not supposed to
limit use of cryptography by ordinary people, but to limit
distribution of snake-oil by self-proclaimed professionals.

I would have guessed the opposite - it's designed to prevent
customized encryption solutions that actually work,
but not to prevent mass-market products.
Since you don't need a license for totally inadequate crypto,
you can still sell snake-oil customized for your users.

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

Re: Botnets on Unix

2008-01-20 Thread Bill Stewart

At 11:04 AM 1/18/2008, Ray Dillinger wrote:

 More than half the servers on the Internet -
the very most desirable machines for botnet operators,
because they have huge storage and huge bandwidth - run
some form of Unix, and yet, since 1981 and the Morris Worm,
you've never heard of a botnet composed of Unix machines!

Of course there've been Unix botnets, though most of them
were a few years ago and not as tightly integrated as the current ones
(or as the Morris worm, which was in 1988.)
Stacheldraht was a DDOS tool from ~1999 running in Linux and Solaris;
it was related to Trinoo and Tribe Flood Network which had similar features,
but I'm not sure what OS those ran on.
says there were several thousand machines running it.

I found it running on a RedHat 6 machine in my lab a few years back,
chatting away with a university machine in Sweden.
It had broken in through a wu-ftpd hole, so it was appropriate
that the next time somebody broke into that machine the
botnet controller was from Washington University.
Another attack looked like it was from MIT, but Jeff Schiller said
it was actually from somebody in Japan that had byte order problems
in the target IP address, so it was probably a Sparc machine.

In contrast, nobody ever bothered the Win95 machine on the same DSL circuit,
but it wasn't running any servers.
Both of them were running on 60-75 MHz Pentium hardware.

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

Re: 2008: The year of hack the vote?

2007-12-30 Thread Bill Stewart

Dan wrote:
 Let's not do this or we'll have to talk about JF Kennedy
 who, at least, bought his votes with real money.

That's because Democrats had become more professional,
and the tradition of buying votes with whiskey
only works for the retail level, not wholesale.

Dan also wrote:

May I point out that if voting systems have a level
of flaw that says only an idiot would use them, then
how can you explain electronic commerce, FaceBook,
or gambling sites?  More people use just those three
than will *ever* vote.

The primary threats of electronic voting machines aren't
to the individual voter,
who can slightly increase the chances of getting
his/her vote counted accurately by insisting on paper ballots,
but to the aggregate vote count, which can be hacked
if the precinct has _any_ electronic machines.

The big problem in Ohio appears to have been Denial of Service -
not that there weren't lots of other problems,
but electronic voting systems have sufficient complexity that
an elections department can arrange to have enough
missing parts or supplies or passwords or powercords or whatever
in demographically appropriate precincts so that the
results get skewed even without Other Technical Means.
Some of the black inner-city precincts had two-hour lines
(on a rainy day), while white Republican-leaning precincts
had all the equipment they needed.

(Also, if you're saying only an idiot would use it
and ask how gambling sites exist, the answer is that
only idiots gamble...   As Ed Gerck pointed out,
risk in e-commerce can be managed and amortized into the price,
but that doesn't work for voting.)

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

RE: Trillian Secure IM

2007-10-12 Thread Bill Stewart

 | Which is by the way exactly the case with SecureIM. How
 | hard is it to brute-force 128-bit DH ? My guesstimate
 | is it's an order of minutes or even seconds, depending
 | on CPU resources.

Sun's Secure NFS product from the 1980s had 192-bit Diffie-Hellman,
and a comment in one of the O'Reilly NFS books says that
However, by 1990, advances in RISC processors produced
workstation machines that could, by brute force,
derive the private key from any public key in under a day.
but that in 1987 there were still a lot of Motorola 68010 machines
that took several minutes to generate keys so they didn't want it longer.
I'm guessing that a 1990 RISC machine was around 50 MIPS,
so it's maybe 1/100 the speed of a modern single-core CPU.

128-bit DH sounds like as good a decision as using 40-bit RC4 keys would be 

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

Re: How the Greek cellphone network was tapped.

2007-07-19 Thread Bill Stewart

At 07:37 AM 7/12/2007, Eric Cronin wrote:
 With current CPUs and audio codecs you can get
 decent voice quality over 9600bps.

Yes and no.  There are lots of 8kbps codecs, and some 6.5 and 5.3kbps codecs,
all off which give acceptable voice quality if transmission's ok.
(And you can reduce average transmission rates by 40-50% with silence 

However, that's the raw codec rate - if you're taking the VOIP packets,
wrapping them in RTP, UDP, and IP headers, and then transmitting them on
a layer 2 protocol with as little overhead as PPP or Frame,
the 8kbps becomes more like 26 kbps (Ethernet and ATM are worse,
and DSL is ATM underneath - I'm not sure what the cellular carriers do for 

The problem is that the Voice-stream data packets are extremely small -
the same headers don't add much overhead percentage when you're using 
1500-byte data packets.

In some environments you can do header compression to save about half the 
but in general you can't.  The Asterisk IP PBX has a trunking protocol that 
you use one set of RTP/UDP/IP headers to carry multiple streams of voice 

so you can connect two locations together for close to the raw protocol speeds,
but that's not likely to apply to a mobile phone situation.

The other way to avoid the VOIP overhead is to use one of the old
voice-over-data designs that uses point-to-point async or sync connections
without an IP layer (e.g. raw modems.)  That lets you send voice for
much closer to the 9600 bps (depending on sync protocol, async stop-bits, etc.)

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

Re: How the Greek cellphone network was tapped.

2007-07-16 Thread Bill Stewart

At 10:59 PM 7/9/2007, Florian Weimer wrote:

Uh-oh, no.  The protocol characteristics don't change depending on
who is selling you the device.

Of course they do, at least in the US,
where the mobile phones are generally carrier-specific,
often locked, and generally don't have open designs.
In particular, they're not usually designed to let the
data applications get at the voice compression ASICs,
but they usually don't have enough CPU to compress voice in Java
if they can get at the voice stream at all.
Some of the PDA phones are more flexible, and I'd expect
OpenMoko to be much more flexible.

Many telcos have an aversion to end-to-end protocols.

They're getting better about it, but the transmission characteristics
from most of the data protocols aren't designed for voice,
unless you're willing to do push-to-talk or equivalent.
So ironically, if you want to get good latency for 5.3kbps voice,
you'll want the fastest data protocols.
HSDPA's latency is 100-200ms, and upstream is 100+ kbps -
you could probably run uncompressed voice which is about 80kbps,
since latency's less of a problem.
(EDGE has upstream of 40-60kbps, but latency is 350+
so the more compressed protocols aren't going to behave.
I don't have the 1xRTT numbers handy, but I think they're similar.)

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

Re: Quantum Cryptography

2007-06-30 Thread Bill Stewart

At 08:51 AM 6/28/2007, Alexander Klimov wrote:

I suspect there are two reasons for QKD to be still alive.
First of all, the cost difference between quantum and normal
approaches is so enormous that a lot of ignorant decision makers
actually believe that they get something extra for this money.
  If you tell a lie big enough and keep repeating it, people
  will eventually come to believe it.

The second reason is ``rollback'' (is it right term?): you pay

Kickbacks would be the usual American term.

$10 from your company funds to a QKD vendor, and they
covertly give $5 back to you.

Never attribute to malice what can be adequately explained by incompetence.

Quantum Crypto is shiny new technology, complete with dancing pigs.
And once you've invested the research and development costs into building it,
of course you want to sell it to anybody who could use it.

So what kind of threat models does it address, and what does that
say about the kinds of customers who'd want it?
- It doesn't protect against traffic analysis,
because the eavesdropper can follow the fiber routes
and see who you're connected to.
- It potentially provides perfect forward secrecy a long time
into the future against attackers who can eavesdrop on you now
and save all the bits they want.
That's mainly useful for military applications - most commercial
applications don't require secrecy for more than a few years,
and most criminal activities can't use it because of the
traffic analysis threat.   Maybe banks?
- It doesn't protect against Auditors getting your data.
So maybe it's not useful for banks.
That's really too bad, because except for the military,
the main kinds of customers that need to spend lots of money
on extra-shiny security equipment are doing so to distract Auditors,
but it does let you tell the auditors you'd done everything you could.

- The Quantum Key Distribution versions only protect keys, not data,
so it doesn't protect you against cracking symmetric-key algorithms.
It does provide some protection against Zero-Day attacks on
public-key crypto-systems, but wrapping your key exchange
in a layer of symmetric-key crypto can do that also.
And if you're the military, you can revert to the traditional
armed couriers with briefcases handcuffed to their arms method.

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

RE: Russian cyberwar against Estonia?

2007-05-21 Thread Bill Stewart

At 01:04 PM 5/18/2007, Trei, Peter wrote:

If the Russians aren't behind this, who else should be
suspected? It isn't like Estonia has a wide selection of
enemies. :-)

There are three likely suspects
- the actual Russian government (or some faction thereof)
- Russian Mafia for whatever reasons (might not be distinct from a faction 
of the government,

and usually if the Mafia's involved they're polite enough to
send a note demanding money or something.)
- Some teenage hacker who got annoyed at some other teenage hacker
because they got into an argument on WoW or Myspace
and decided to DDOS him (usually attacks like that
don't take down much more than a small ISP or a university,
but like D00d, you're so 0wn3d, I can take down ur whole 
*country* :-)

The latter isn't as far-fetched as it sounds (well, ok a bit...)

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

Re: 128 bit number T-shirt?

2007-05-02 Thread Bill Stewart

I'd like one with Wearing an integer is not circumvention. on the
back or some such. :)

Large Integers are Not A Crime :-)

On the other hand, isn't the key really an MD5 hash of some haiku about
OK, so we know that
Just Not Good Enough

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

Re: Private Key Generation from Passwords/phrases

2007-01-24 Thread Bill Stewart

 With 4K possible salts, you'd need a
 very large password file to have more than a very few collisions,

Definition of very large can vary. (alliteration intended).[...]
UCSD has maybe 60,000 active users.  I think very large is very common
in the University environment.

Different decade, different threat models, different scales.
It was probably pretty rare to have more than a
couple of hundred users on a PDP-11,
but even at 60-70 you're in birthday-collision range with a 12-bit salt.
But a website could easily have a million users in its password files,
and some systems like Yahoo and Hotmail have hundreds of millions,
though obviously they're not all separate Unix userids.
Sometimes it matters if they get stolen, sometimes not -
I don't care if someone discovers that
my New York Times web password is password,
but I'd be really annoyed if my online banking password got cracked.

Salt is designed to address a couple of threats
- Pre-computing password dictionaries for attacking wimpy passwords
These become harder to do online, pushing a dictionary of
e.g. a million words to 4 billion, or ~32GB,
an unreasonably large database for ~1975 crackers,
though obviously you could use a manageable stack of tapes.
Today that fits in my iPod, though it's still impractical
to store an unsalted full-56-bit DES password dictionary.
- Detecting password collisions within systems, and between systems
Testing a known password against 4096 salts
took a long time at 0.5 MIPS, but it's faster at 4000 MHz.
Large systems will have internal collisions,
and the web makes it even more likely that somebody
will have logins on insecure systems
that might have the same password as their secure logins.
- Annoying then-hypothetical hardware DES crackers
That's still useful against some designs today,
though many designs, especially software,
are table-driven in ways that aren't annoyed much.

There are probably times that salt is useful, and that password files
using hashes are useful, but I'd think that if you're going to do that
today you might as well use 64 or preferably 128 bits of salt,
and of course you might want a hash other than MD5 or SHA-1.

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

Re: Private Key Generation from Passwords/phrases

2007-01-19 Thread Bill Stewart

At 01:55 PM 1/18/2007, John Denker wrote:

We would be better off maintaining just the one technical
definition of entropy, namely S = sum_i P_i log(1/P_i).
If you want to talk about something else, call it something
else ... or at least make it clear that you are using the
term in a nontechnical or metaphorical sense.
If you want to talk about work factor, call it work factor.
If you want to talk about entropy, call it entropy.

One of the roots of the problem is that for many applications,
i is a well-defined event and P(i) is a fixed value (for i) ,
but for many other applications,
i might not be a well-defined event, and/or
P(i) is really a conditional probability, P(i|other-stuff-you-know),
and it's hard to tell whether that's
usefully different from the non-conditional P(i).

One case where this comes up is key generation with entropy pools -
you take a bunch of hopefully-kinda-independent,
hopefully-identically-distributed variables generated
by processes that are complicated enough to look random,
make some estimates of their probability distributions
and hence of their entropy, and add the estimates together,
after prewhitening the samples to make any correlation
harder to exploit.  This gives you N bits of entropy,
and you take M bits of it to use as a key,
again possibly with some hash functions to make
calculations more difficult.

So how many bits of entropy are left?
You can be conservative and call it N-M,
assuming that if somebody were clever enough to take
the M bits key sample they could validate the rest
with only N-M calls to an oracle,
or you could be wildly optimistic and call it N,
assuming that the conditional probabilities of the
remaining pool are still the same given that you know the M bits,
because there's no way to use them to validate anything,
and if you've done a good enough job of designing your
pool management functions the reality is probably
closer to the wildly optimistic case,
unless somebody finds an efficient way to invert your hash functions,
at which point the conditional probabilities are actually
different if you know the M key bits than if you don't.

Another entropy example was the Venona decryptions -
people banging randomly on typewriters didn't actually produce
independent or identically distributed letters,
so the conditional probabilities didn't actually match
the assumed ones, so the entropy estimates were wrong,
and human language plaintext being what it is,
they really needed the 1-bit-per-bit of key entropy.
It's much tougher to exploit than OTPs used more than once,
but it's a start.

But hey, nobody's going to guess that your password
is your dog's name spelled backwards, or think of using
a list of a few million obvious passwords as input to
the key-generation function.

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

Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?

2007-01-19 Thread Bill Stewart

As far as Full Disk Encryption's usefulness as a term goes,
I'd distinguish between several different kinds of applications
for encrypting the contents of a disk
1 - The disk drive or maybe disk controller card (RAID, SCSI, etc.)
encrypts all the bits written to the drive
and decrypts all the bits read from the drive,
usually with some keying input from the OS.
2 - The operating system's driver software
encrypts/decrypts all bits written to/from the drive
3 - The operating system's file system driver software
encrypts/decrypts all bits written to/from a file system
(which might or might not occupy a drive partition.)
4 - Utility software encrypts/decrypts bits written to/from directories.
5 - Application software encrypts/decrypts contents of files.

Obviously if you're trying to protect against KGB-skilled attacks
on stolen/confiscated hardware, you'd like to have the swap partition
encrypted as well as any user data partitions, though you may not care
whether your read-only utility software was protected
(e.g. your Knoppix disk or vanilla shared /usr/ or whatever.)
Whether you implement that in the disk controller or OS is really
a matter of convenience and user support economics -
if you're a small conspiracy you may want to roll your own,
but if you're a corporate IT shop, you've probably got economic issues
that affect whether you customize the OS (more) or the disks or both
and it's the operational processes that will trip you up.

On the other hand, if you're trying to protect against
lower-skilled attackers, e.g. laptop thieves who are reselling
disks to the Nigerians and other hardware on eBay,
you want to protect your file systems,
but probably don't need to protect your swap.
It's certainly nice to do that, of course, and might be a Good Thing
for Linux and ***BSD to include in their standard swap drivers,
but hopefully your file system drivers would keep their keys
in non-swappable memory, and most other things get overwritten
often enough that attackers not using electron microscopes
probably won't bother with them much.  In most OS's,
swap isn't persistent across system reboots,
so you can actually generate a new key on the fly every time
and not bother the user about entering it, unlike regular filesystems
or full-disk-encryption systems.

Of course, if the KGB *is* after you, they may black-bag your PC
before they confiscate it - if there's a key-logger chip
added to your keyboard or a camera mounted in your ceiling light,
it may not matter how cool your FDE is.

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

Re: cellphones as room bugs

2006-12-11 Thread Bill Stewart

At 11:26 AM 12/9/2006, Daniel F. Fisher wrote:
Ian Farquhar (ifarquha) wrote The other problem for this technique is 
battery life.

Suppose this worked by recording from mic to memory and then transmitting 
later. This leads to a bunch of questions:

By what factor could transmission time/power be reduced sending such a 
recording later? How many minutes could a typical phone buffer? How much 
does a typical conversation compress? Are such algorithms within the power 
of a typical phone's processor? How much power is used in recording to 
memory and compressing?

Cell phones already compress voice, to reduce spectrum needs,
and that's done in hardware rather than wasting CPU.
If the phone's design is sufficiently general, it can easily grab
the compressed voice bits and store them in memory instead of transmitting
(assuming there's enough memory, which isn't necessarily the case.)
Voice compression rates are typically 5.6 - 6.5kbps, or 13 on some GSM flavors,
and you may gain a bit from silence suppression depending on
whether the microphone can adequately hear the other speaker.

If the phone doesn't have data networking features,
or only has the slow types (CDPD, etc.) used to handle text messages,
there's probably no big advantage to doing this.
But if you've got faster data service, say 50-60kbps or the newer
~~200-300kbps stuff, then you can transmit faster than real-time speech,
and if you can buffer enough data, say 1 MB for 20 minutes of talk time,
you might save some battery.

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

Cypherpunks make the OED :-)

2006-11-06 Thread Bill Stewart

James Gleick's NYT article on the OED mentions cypherpunk
among the words recently added to the dictionary.

The page requires registration to access, though there are enough
popular pseudonyms that have done so; I don't know if any of the
cypherpunks/somepassword combinations still work;
I've been using one of the no-response email systems for my login.

I don't have a subscription to the online dictionary to
see what they said about it.

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

Public Key Cryptography 30th Anniversary Event - 10/26, Mountain View CA

2006-09-21 Thread Bill Stewart

From: Computer History Museum [EMAIL PROTECTED]
Subject: Public Key Cryptography 30th Anniversary Event - October 26

Celebrating 30 years of Public Key Cryptography (PKC)

Join the Computer History Museum for a special public event celebrating 30
years of public key cryptography. This memorable evening celebration will
honor the inventors, the inventions, the milestones, and the future of PKC.
The program is moderated by Steven Levy, author of Crypto and senior editor
Newsweek, and includes Ray Ozzie, Whitfield Diffie, Martin Hellman, Jim
Bidzos, Dan Boneh, Brian Snow, and John Markoff.  All will share their
opinions on the state of the industry today and an audience question and
answer session will complete the evening.

Go to to register for this exclusive
celebration.  Space is limited, so register

Computer History Museum
1401 N. Shoreline Blvd.
Mountain View CA 94043
(Highway 101 at Shoreline)

OCTOBER 26, 2006
6 to 9 pm

6:00 to 7:00 PM
Networking reception

7:00 to 7:30 PM
Welcome and PKC Overview

7:30 to 8:30 PM
Panel presentation

8:30 to 9:00 PM
Audience question and answer session

Please join us on October 26th for this networking reception and panel
presentation. Mark your calendar now, and visit to register for this celebration.

Space is limited, so register today.

s p o n s o r e d  b y  Voltage Security and RSA:

You are currently part of the Lecture announcement list of the Computer
History Museum. To unsubscribe, please reply to this message with the word
remove in the subject line.

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

Re: Hamiltonian path as protection against DOS.

2006-08-16 Thread Bill Stewart

Crypto is usually about economics and scalability.

If you're doing this for DOS/DDOS prevention,
you don't need the NP-completeness perfection you get from
Hamiltonian paths or similar problems - SHA is fine,
or any other hash that's quick to verify and
hard to reverse.  Even MD5 is probably still ok...
Calculating any of the hashes probably takes less time than
handling the packets does.

It's almost certainly better for you if they harass you by
sending you bogus SHA pieces that you can process quickly
than bogus DH pieces that take you a while,
and if it's not too distributed an attack,
you can also blacklist senders IP addresses.

At present I'm skeptical about the need for
that kind of protection - a simple UDP or TCP handshake
and maybe a Photuris cookie are enough to
take care of most forgery attacks
and let you blacklist hostile senders.
But malware writers are tenacious bastards,
and perhaps there are or will be applications where
this sort of protection could be useful -
merely insisting that attackers use _your_ protocol
is probably enough to cut down on 99.99% of attacks
unless you get the protocol widely adopted.

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

Re: VoIP and phishing

2006-04-29 Thread Bill Stewart

There are two sides to the voice phishing here -
- getting the target to call a phone number you've emailed him
- using cheap voice calls to call the target with your offer.

VOIP doesn't affect the former case much,
since the target is paying for the call,
but it does separate callee geography from phone numbers,
so you can use a plausible phone number (e.g. New York)
that's directed to a location with cheap criminal labor,
without the effort that used to be required to set up
FX numbers or expensive international private lines
or locate your call center in the target's country or state.

I've received one Nigerian 419 phone call, a few years back,
which used a Deaf Relay Operator to relay the call from
the scammer, and apparently they used to be heavy abusers of that service.
VOIP also makes that more practical, and somebody's coined
the term spit to refer to Spam over IP Telephony.

But phone calls are cheap enough that labor is the
dominant cost of the calls.  I receive frequent
offers to refinance my mortgage or get credit cards
that use presumably-standard phone banks, usually calling
from India and claiming to be US banks.
For all I know, they really are legitimate rude bankers
instead of scammers, but I don't care either way.
VOIP may have replaced voice over frame as the transmission medium,
but it's often an enabling technology for the telco rather than
voice over internet to the end user.

I've been at a lot of telecom trade shows recently,
and vendors have been showing off session border controllers
and various security devices and presence servers,
and while there are lots of tools to let the recipient
indicate whether he's accepting calls or not,
there doesn't seem to be much out there to detect and
reject unwanted calls wholesale.  Most of what I've seen
that's somewhat in that direction are buddy-list tools that
let your spouse/boss/etc. reach you directly and divert other
callers to voice mail or whatever, but within a year or two
we'll start needing to get more sophisticated filters the
way we do with email.

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

Re: bounded storage model - why is R organized as 2-d array?

2006-03-10 Thread Bill Stewart

At 10:37 AM 3/9/2006, Chris Palmer wrote:

Right, but even though a 1.5GHz machine is a bit old (heh...) for a
workstation, my dinky little Linksys WRT54GC wireless AP still needs to
AES-encrypt a theoretical maximum of 54Mbps when I turn on WPA.

Unless you're using your Linksys for file-sharing between machines at home,
you're not likely to be encrypting more than about 6 Mbps
(or whatever DSL and Cable Modem do these days in better cities.)

Thus, something faster than AES, but still strong, would be nice. Your
point about CPU cache size vs. pad size is well-taken, though.

I'd trust RC4-used-correctly before trusting Tri-Strata,
if there weren't so much bad history of people misusing RC4...

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

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

2006-03-01 Thread Bill Stewart

Somebody, probably Florian, wrote:

 I couldn't find a PGP key server operator that committed itself to
 keeping logs confidential and deleting them in a timely manner (but I
 didn't look very hard, either).

Keyservers are a peripheral issue in PGP -
important for convenience and for quick distribution of revocation lists,
but they're very strongly just a tool for convenience.

Security through Inconvenience is one flipside of Security through 
Obscurity, I suppose...

If you've got a threat model that includes traffic analysis,
then either you and your unindicted co-conspirators
need to find other ways to exchange keys,
like printing them on business cards,
or find a keyserver that lets you suck down all the keys
so it's not obvious which key you're looking for,
or start using Tor to access the keyservers.

Or you could try using the Google Keyserver -
  just because there isn't one
doesn't mean you can't type in 9E94 4513 3983 5F70
or 9383DE06   or   [EMAIL PROTECTED] PGP Key
and see what's in Google's cache.

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

Re: EDP (entropy distribution protocol), userland PRNG design

2006-02-08 Thread Bill Stewart

At 01:01 AM 2/4/2006, Travis H. wrote:

Assume further that it is not cost-effective to furnish each with a
HWRNG, even one as inexpensive as a sound card (for example, they may
not have a spare slot on the motherboard nor built-in sound).
Suppose that /dev/random is too slow (SHA-1 was never meant to
generate a lot of output) because one of these machines wishes to
generate a large file for use as a one-time pad*.

One-time pads are expensive protocols to use properly -
the operational costs of generating easily-disposable media,
putting couriers with briefcases handcuffed to their arms onto airplanes,
shredder costs when trashing the CD/DVD/etc., /dev/thermite for the PCs,
and all the other things that you need to do for a real OTP threat model
add up to real money after a while.
If you can afford that, you can afford to spend $100 for an
external sound card or USB hardware random generator dongle or whatever
or a PC case with more slots in it.

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

Re: another feature RNGs could provide

2005-12-22 Thread Bill Stewart

 Good ciphers aren't permutations, though, are they? Because if they
 were, they'd be groups, and that would be bad.

Actually, by definition, a cipher should be a permutation from the set
of plaintexts to the set of ciphertexts. It has to be 1 to 1 bijective
or it isn't an encryption algorithm.

The groups-are-bad problem applies to the
mapping between keys and plaintext-cyphertext bijections,
not the mapping between plaintext and cyphertext.
You're trying to avoid the situation where
E(x,key1) == E( E(x,key2), key3) for all x

The mapping between plaintext and cyphertext doesn't need to be 1-1 

1-n mappings from 1 plaintext to multiple cyphertexts
can work fine for many applications,
but have the practicality problem that the cyphertext is
longer than the plaintext, and there aren't many
applications where you really want the expansion.

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

Re: crypto for the average programmer

2005-12-18 Thread Bill Stewart

At 03:34 PM 12/14/2005, [EMAIL PROTECTED] wrote:

An application programmer who is using PKCS1 doesn't even need to
know the small amount of ASN.1 in the spec... libraries that
implement RSA PKCS1 take care of the ASN.1 for the programmer.

This is in fact one reason that ASN.1 exploits
have been so wide-ranging when they've happened.
ASN.1 is a horrendously ugly mess, even uglier than PGP,
so almost everybody uses an existing library instead of
rolling their own or writing a new library for other users.
Major bugs aren't discovered often,
but everybody's pretty much using the same C code,
whether for SNMP or X.509 or whatever.
I don't know how many of the Java et al. versions
have rewritten it natively as opposed to importing
C libraries, which is probably more convenient.

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

Re: A small editorial about recent events.

2005-12-18 Thread Bill Stewart

At 10:58 AM 12/18/2005, Perry E. Metzger wrote:

The President claims he has the prerogative to order such
surveillance. The law unambiguously disagrees with him.

There are minor exceptions in the law, but they clearly do not apply
in this case. They cover only the 15 days after a declaration of war
by congress, a period of 72 hours prior to seeking court authorization
(which was never sought), and similar exceptions that clearly are not

One of the NYT articles also said that the
President's lawyers gave him an opinion saying that the
post-9/11 resolutions gave him the authority to do this.
If the resolutions actually did that, then that could
supersede the previous laws that made it criminal.

But this wasn't the only domestic spying story in the news this week.
NBC reports that the Defense Department is back to
CONINTELPRO-style spying on Americans,
specifically anti-war groups and campaigns against military recruiting,
especially suspicious groups associating with Quakers.

And the EU parliament just voted on massive data collection laws,
requiring ISPs, telcos, and mobile phone companies to
collect and retain information in ways that would have
previously violated EU privacy laws.

That's one of the big problems with protections based on laws -
they're only good until the politicians change the laws.
Constitutional protections are somewhat more durable,
but can still be changed either by Amendments or by
significant changes in court interpretations,
such as the Drugs and Terrorism Exceptions to the Bill of Rights
and the expansion of the Commerce Clause to cover almost everything.

One of the Bush Administration's innovations has been
White House legal opinions telling the President that
the courts ought to approve various powers or practices,
so there's therefore no need to actually take them to court,
whether it's wiretapping or extraordinary rendition or
defining torture to exclude anything done by US forces.
We'll see if he gets away with it this time -
he needs to be stopped.

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

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-10 Thread Bill Stewart

At 09:40 AM 12/8/2005, Aram Perez wrote:

On Dec 7, 2005, at 10:24 PM, James A. Donald wrote:

Software is cheaper than boats - the poorest man can
afford the strongest encryption, but he cannot afford
the strongest boat.

If it is that cheap, then why are we having this discussion? Why
isn't there a cheap security solution that even my mother can use?

Usability is a hard problem, and security is a really broad field.
PGP, for instance, did a pretty good job of security a decade ago,
given Phil's threat models, (ignoring a few algorithm problems
that were mostly related to trying to skimp on bits
and the subsequent weaknesses in MD5),
but the usability was pretty rough back then,
and version compatibility has gotten enough worse that
Hugh Daniel and I can no longer reliably communicate with PGP.

But even if we both drop back to GPG on text files,
and use remailers run by friends on Tor nodes run by random strangers,
KGB-proof security would require protection against
black-bag jobs on Hugh's keyboards and duping employees
at my company's IT department into weakening my Windows XP configuration.
(For cost-effectiveness and avoidance of detection,
I'd recommend the latter strategy, probably by selling them
some new nifty administration tool or Instant Messaging client :-)

The real security issue for your mother is threat models.
If your mom isn't using a Mac or administering her own Linux box,
then her biggest security threat is that she's computing
on a box made of Swiss cheese (though XP does seem to be
noticeably better than Win95/98/ME) and probably using a browser
that's happy to accept random software installed by spammers
and phishers, and if she's not using webmail,
she's probably running a mail client that happily displays
clickable links to phishing sites purporting to be eBay or her bank.
And that's mostly independent of whether she can trustably
send email to other members of the Ladies' Sewing Circle and
Terrorist Society without the Feds reading it,
which is the kind of problem PGP was trying to solve,
because her bank and eBay don't cryptographically sign their mail.

Popularity of a product is critical to its security;
you don't gain anonymity if the Feds can recognize that
you're one of the dozen users of a given application.
Your mom can use Skype, but nobody she knows uses Crypto Kong,
and I only know a few people who use PGP to email their mom.
But some of the Instant Messaging systems use crypto;
too bad that they're continually trying to be incompatible
with each other to gain market share.

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

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

2005-12-08 Thread Bill Stewart

At 08:05 PM 12/2/2005, [EMAIL PROTECTED] wrote:

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

I've used it for about a decade at my credit union,
and I've had my paychecks deposited directly for decades.
There are things I absolutely won't do,
like have a debit card attached to the account,
or have companies authorized to take money out directly,
or have electronic checks of various sorts taken out of the account.
Normally I don't do email with them (though nobody appears to have
noticed them as a phishing target), but I did have one time
I had to ask about a transaction, and they do that by email,
so I was able to trust the responses.

But for basic services where I tell them what to send to whom,
it's reliable, appears to be at least as secure as
the other risks to the account, and it means that the
basic payments I need to make every month happen automatically,
so I only have to pay attention to the occasional variable transaction.

I've also used account-based electronic gold services,
but only transactionally, so at most they end up with a couple dollars
worth of exchange-rate breakage in them, and there are some
non-account-based services that I've also used.
I won't use e-gold - not that their website is obviously insecure,
but for a while there was so much e-gold phishing that
I set my filters to automatically discard anything purporting
to be from them, which might interfere with doing real business.
On the other hand, they don't appear to state a policy of
always digitally signing all transactions, so I'm a bit concerned
beyond the more blatant phishing risks.

Thanks; Bill Stewart

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

Re: ISAKMP flaws?

2005-11-30 Thread Bill Stewart

At 06:56 PM 11/18/2005, William Allen Simpson wrote:

| tromped around the office singing, Every bit is sacred / Every bit
| is great / When a bit is wasted / Phil gets quite irate.

| Consider this to be one of the prime things to correct. Personally,
| I think that numbers should never (well, hardly ever) be smaller
| than 32 bits.
(Jon Callas, 1997-08-08)

Ah yes, a couple of years after Photuris.  And wasn't Jon the _author_
of the PGP variable length integer specification?  Hoisted on his petard?

No, it was still Phil's old heavily-used petard,
worked over by various other people from PGP 3.0 and PGP Inc.
Jon was going for backwards compatibility in the OpenPGP specs.
He may have cleaned up the specs a bit,
and fixed some of the security holes from VL-integer exploits,
but unfortunately OpenPGP retained almost all the old ugliness.

I was always grumpy about the impossibility of doing stealth easily
in the native PGP formats and the fact that the OpenPGP code
fossilized it.  For political reasons I'd have also liked
PGP to have had an optional very simple format so you could
fit it into one page of Perl or equivalent to go with the
RSA in 4 lines of Perl or lisp.

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

Re: the limits of crypto and authentication

2005-07-12 Thread Bill Stewart

At 09:29 PM 7/9/2005, Perry E. Metzger wrote:

The Blue Card, so far as I can tell, was poorly thought out beyond its
marketing potential. I knew some folks at Amex involved in the
development of the system, and I did not get the impression they had
much of a coherent idea of what the technologies would be used for
other than creating marketing buzz.

On the other hand, only a short time before that,
Apple's iMac created a whole marketing revolution
and set of spinoff products and revitalized the company
by coming out with a semi-transparent blue-green case
that effectively packaged the Reality Distortion Field,
and they were able to maintain the effect over several years
by the radical introduction of several other semi-transparent colors.

It'd be nice if good crypto and authentication methods
could create a market for improved products,
but hey, if blue-green translucent dancing pigs gets customers,
the marketing people have done _their_ job.

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

Re: AES cache timing attack

2005-06-25 Thread Bill Stewart

At 02:44 AM 6/20/2005, Peter Gutmann wrote:

Stephan Neuhaus [EMAIL PROTECTED] writes:
Concerning the practical use of AES, you may be right (even though it would
be nice to have some advice on what one *should* do instead).

Would switching to triple-AES (or double-AES) or something help?
Yeah, it's ugly, and AES was supposed to let us get away from triple-DES,
but maybe running one AES with the original key and
the other session with the inverse of the key would
interfere with timing attacks?

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

Re: Papers about Algorithm hiding ?

2005-06-06 Thread Bill Stewart

At 01:14 PM 6/3/2005, [EMAIL PROTECTED] wrote:

I think we are already in a state where practically everybody that has a
computer has crypto available, and it's not difficult to use it!

Of course they have it -
the problem is having crypto in a way that's not suspicious,
and suspicious is highly dependent on your threat model.
For instance, Microsoft Word has crypto -
it's lousy crypto, which isn't directly relevant here,
but it's a utility that people view as normal,
while PGP is inherently suspicious-looking.
No reason that OpenOffice couldn't have crypto that's actually reasonable 
The rename the binaries strategy is probably more reliable than 
cyphersaber etc.

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

Re: how email encryption should work

2005-05-20 Thread Bill Stewart
At 07:00 PM 3/28/2005, James A. Donald wrote:
In my blog I post how email encryption should work
I see a couple of problems with your proposal.
I'm not sure I like your external trusted mail-server assumptions,
but they're probably good enough for many people,
and other people will have better comments about them.
Your plan is really designed for a small number of addresses per sender,
as opposed to a quasi-infinite set of tagged addresses.
It's becoming pretty common for anti-spam reasons
to give different recipients different mail addresses like
so you can track and whitelist/blacklist people you communicate with,
and some ISPs automagically translate between the two formats.
Building a user interface that does that unobtrusively
is probably a hard problem, or at least not a well-solved one,
and building a cryptosystem that assumes a small number of
addresses per user could make that style of mailer harder.
A good user interface probably has some version of petname support,
though, so there's some commonality with key handling.
On the other hand, if you assume that most people will get domains,
whether 2LD or 3LD or other subdomain,
you could do a model that says that a user gets one key per domain,
so you could think about hanging the keys off DNS.
That may not be the right choice (do you want your email addresses
to be easily correlated, and cracking/stealing one address's key
to reveal the keys you use for everybody else?  Or does the domain
pretty much imply that to the skilled recipient anyway so who cares?)
And of course it gets into the whole squabble about DNSSEC,
and why its deployment failed, and whether it was trying to do
a perfect job and therefore less scalable than a mostly-good-enough job,
or at least into the politics of those questions if not the technology.
The related problem is what to do if you *do* want different keys
for different recipients; you could do that with different subdomains,
or you could do a non-DNS approach.
- Is (sender+recipient+timestamp+message) the right thing to sign?
The Subject: line is in the mail headers, but it's probably
something that should be part of the message.
I'm not sure about some various X-headers.
And of course the From: line includes both the email address
and the sender's name, and the sender's name may be different
for different recipients (in some sense, it may be the
recipient's petname for the sender.)
- Also, if you're attaching a key strictly to the email address,
what happens to old signatures if you move email addresses?
I suppose that's part of the point of getting your own domain name,
so you can avoid having to change contact addresses when you change ISPs,
but if you're using a new email address, how do you forward the signature?
One option is to do what you can do in Crypto Kong,
where you send a message from old-address signed by old-address,
saying that you'll be using new address and new key,
but that seems a bit awkward, since you need a convenient way to
include the new keys for people who whitelist you or who you
only want to send encrypted mail to.
Thanks; Bill Stewart
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: Encryption plugins for gaim

2005-03-20 Thread Bill Stewart
At 10:19 PM 3/13/2005, Adam Fields wrote:
Given what may or may not be recent ToS changes to the AIM service,
I've recently been looking into encryption plugins for gaim.
AOL says that the ToS bits are only for things like chatrooms;
user-to-user AIM traffic doesn't even go through their servers.
That doesn't mean they can't eavesdrop on it if they want to,
or that they don't have mechanisms for automating MITM,
so you may very well want to use encryption,
but at least in the normal case your traffic is relatively private.
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

RE: Banks Test ID Device for Online Security

2005-01-05 Thread Bill Stewart

R.A. Hettinga wrote:
 Okay. So AOL and Banks are *selling* RSA keys???
 Could someone explain this to me?
At 12:24 PM 1/4/2005, Trei, Peter wrote:
The slashdot article title is really, really misleading.
In both cases, this is SecurID.
Yup.  It's the little keychain frob that gives you a string of numbers,
updated every 30 seconds or so, which stays roughly in sync with a server,
so you can use them as one-time passwords
instead of storing a password that's good for a long term.
So if the phisher cons you into handing over your information,
they've got to rip you off in nearly-real-time with a MITM game
instead of getting a password they can reuse, sell, etc.
That's still a serious risk for a bank,
since the scammer can use it to log in to the web site
and then do a bunch of transactions quickly;
it's less vulnerable if the bank insists on a new SecurID hit for
every dangerous transaction, but that's too annoying for most customers.

Bill Stewart  [EMAIL PROTECTED] 

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

Re: Are new passports [an] identity-theft risk?

2004-10-28 Thread Bill Stewart
At 06:11 AM 10/24/2004, Ian Grigg wrote:
The questions would then be, what frequency do these
things operate on, what power is required to power
them up, and what power is required to ... power them
down.  Any radio guys around?
There's an excellent RFID reference article at
RFIDs run at a variety of frequencies,
including 128 kHz, 13.56MHz, 915 MHz, 2.45GHz,
which are the common ISM bands that lots of other things run in,
such as cordless phones, WiFi, Microwave ovens, etc.,
which means that detecting readers may be tough.
It doesn't take a lot of power to power them;
not sure what it takes to fry them.

Bill Stewart  [EMAIL PROTECTED] 

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

Re: Printers betray document secrets

2004-10-21 Thread Bill Stewart
At 05:23 PM 10/18/2004, R.A. Hettinga wrote:
It turns out that their techniques aren't all that useful.
Changing laser printer cartridges changes the results.
You might find that two documents were printed
by the same printer, but it doesn't give you the
options for tracking it down that manual typewriters did.
And the differences don't identify a specific printer
in a way that can be tracked, e.g. identifying a serial number
that could be looked up from warranty records.
It's not clear that they work at all with inkjet printers,
and changing ink cartridges is even more common than
changing laser printer cartridges.  If you're sloppy,
you've probably got a bunch of partly-used cartridges around,
so even if you want to print out a bunch of ransom notes
or whatever, you don't even have to go to Kinko's
to get them to be different.
If printer makers want to build in watermarking to
make everything they print traceable, the way many of them
check for documents that look like money and don't print them,
they could hide patterns that survive cartridge changes
(would you notice a few inverted pixels on a 600x600dpi printout?)
But even then, inkjet printers are dirt cheap;
when they're on sale, they're essentially a free enclosure
in a box of overpriced printer cartridges,
so even of the printer wants to rat out the user and
it's not easy to change the serial number PROM,
you can just replace the printer.

Bill Stewart  [EMAIL PROTECTED] 

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

Re: Linux-based wireless mesh suite adds crypto engine support

2004-10-04 Thread Bill Stewart
Peter Gutmann wrote:
 Tinfoil-hat mode.
Agreed, but some people want to be thorough, or pedantic, or paranoid.
At 04:20 AM 9/30/2004, Jonathan Thornburg wrote:
UNDOCUMENTED_EVIL_WIRETAP_MODE can be just about impossible to spot
without full design oversight.  Even for a 3DES chip, where supposedly
you can use deterministic test vectors to verify things, the following
scheme due to Henry Spencer embeds an 
almost-impossible-to-spot-in-practice backdoor:
A somewhat simpler backdoor could be used in block chaining modes.
Occasionally output the data you're leaking instead of one or a few blocks
of cyphertext, and the CBC will glitch on it and then resync a few blocks 
in many environments the application layer will correct for it,
e.g. IPSEC will lose a few packets, TCP will timeout and retransmit,
and 3 seconds later it's as if nothing happened except that
the private keypart has been leaked for the passive eavesdropper.

Bill Stewart  [EMAIL PROTECTED] 

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

Re: Linux-based wireless mesh suite adds crypto engine support

2004-09-29 Thread Bill Stewart
In the past, there have been two main problems with the Via crypto sets
- availability of convenient software
- sufficient documentation and really transparent provable details
so that users could trust and verify that the hardware and software
were doing what they claimed to be doing and
weren't doing anything evil that they didn't admit to,
such as including backdoors or bad random number generators.
For typical applications, this is probably fine,
though I haven't looked at Via's licenses to see if they can
easily be used with a GPL license or if they need LGPL+Weaselwords or worse.
The hard part is trust - Cryptography Research did a study last year
about the quality of the random number generator, and found that you
get about 0.75 bits of entropy per output bit, or 0.99 if you do
Von Neumann whitening, so it's fine for feeding your crypto-based whitener.
But their report indicates that they were mainly working from
design documentation and testing actual equipment,
so their tests doesn't show what the RNG does if you execute
first, much less what happens to the AES keying info or IVs.
Disclaimer:  I'd be really surprised if UNDOCUMENTED_EVIL_WIRETAP_MODE exists -
the folks who built the crypto features in say good pro-privacy things,
and I'm inclined to trust them.  I'm much less sure about the
It's very hard to test for these things when you've got complete documentation,
even if Ken Thompson wasn't helping write your compilers.
Bill Stewart

At 05:21 AM 9/25/2004, R. A. Hettinga wrote: ...
Sep. 24, 2004
The first commercial software product to exploit the cryptographic
acceleration engine in newer Via processors has hit the market, according
to Via. LocustWorld's MeshAP-Pro is a commercial version of MeshAP, Linux
software for self-organizing networks of wireless access points. MeshAP-Pro
targets larger mesh network operators such as urban service providers.
In addition to selling and supporting MeshAP-Pro software, LocustWorld also
offers blackbox hardware platforms for wireless routers, such as the
MeshBox, a Linux-based mini-ITX system based on Via mini-ITX boards.
LocustWorld sells Linux-based blackboxes for wireless routers based on Via
mini-ITX boards
The processors in newer Via mini-ITX boards based on C5P Nehemiah cores
include the PadLock Hardware Security Suite, which includes the PadLock RNG
(random number generator) and the PadLock ACE (advanced cryptography
engine). PadLock ACE performs low-level processing of the algorithms used
in AES (advanced encryption standard), a kind of cryptography defined by US
government standards.

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

Re: public-key: the wrong model for email?

2004-09-17 Thread Bill Stewart
At 10:19 PM 9/15/2004, Ed Gerck wrote:
Yes, PKC provides a workable solution for key distribution... when you
look at servers. For email, the PKC solution is not workable (hasn't been)
and gives a false impression of security. For example, the sender has no
way of knowing if the recipient's key is weak (in spite of its length)
or has some key-access feature. Nonetheless, the sender has to use that key.
I don't understand the threat model here.  The usual models are
- Key too short - Obvious to the sender
- Recipient's machine is compromised
- Not obvious to sender, but not fixable by email program
- Recipient is stupid and careless
- Often obvious to sender, but not fixable by email program
- Recipient's Public Key generator system generates weak keys
- Hard for sender to detect and work around
- Usually requires extra work by recipient to obtain
compromised software, unless mandated by Corporate IT Droids
- Recipient can reduce risk by using open source software
- Recipient's Public Key generator mails copy of private key to
- Indistinguishable from previous case
- Recipient's Client Software mails copy of session key to
- Indistinguishable from previous case
- Recipient's Email Client forwards incoming mail message plaintext
disguised as bouncegrams or viruses.
- Indistinguishable from previous case.
- Recipient's Secret Key is recipient's dog's name spelled backwards,
written on yellow sticky note pasted next to open window,
under the big mirror with a good view of recipient's keyboard and 
- Not a software problem
- Recipient's Computer Disk automatically backed up to optical storage at night
- No sense subpoenaing cyphertext when you can subpoena plaintext.

You're focusing on a relatively niche threat model,
unless there's some operational aspect here I'm missing.
If you wanted to do something fancy, you could insist that the
recipient send the sender a Diffie-Hellmann Half-Key,
which you use to generate a session key that you use for message encryption,
and transmit your DH half-key along with the encrypted message
for the sender to decrypt.  It's still subject to most of the same threats
as the RSA-like public-key model, though maybe it's a bit easier
to detect weak Diffie-Hellmann keys.  However, unless you want to
force the recipient to change their client interface,
the easier place to implement something is in their SMTP client,
and the obvious way to do that is some variant on SSL-SMTP.
If you _still_ want more control, set up a web server,
and instead of sending your actual secret message, send
Encrypt ( Key=Alice, Message=
Alice - I've sent you an encrypted message at
This URL will self-destruct in 5 business days.
- Bob
However, if Alice was using a compromised email client,
she could just as easily be using a compromised browser. 

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

Re: potential new IETF WG on anonymous IPSec

2004-09-13 Thread Bill Stewart
At 11:45 AM 9/12/2004, Sam Hartman wrote:
No.  opportunistic encryption means I have retrieved a key or cert for
the other party, but do not know whether it is actually the right
cert.  This is slightly different although at the level of current
discussion it has the same security properties.
Actually, FreeSWAN's Opportunistic Encryption meant
if you've got IP traffic for somebody,
see if they can do encryption with you and use it if you can.
Because Gilmore wanted to make sure encryption was always done securely,
their implementation used a common PKI - DNSSEC and inverse DNS -
which has the advantage that a security gateway can use it when
all it knows is the IP address of the destination (which is typically the 
but the severe disadvantage that very few people have control
over that DNS space and also that an IP address may belong to more than one 

There's a significant policy question there - if you don't have
a common PKI of some sort, is it worthwhile encrypting anyway,
protecting against passive eavesdroppers but not MITM,
or is that a false sense of security because the people who
most need security are the people most likely to have a government
annoyed enough at them to do the work of running a MITM attack?
Encryption against passive eavesdroppers makes password-stealing
and traffic analysis harder, so it's probably worth the risk,
but that wasn't the choice that FreeSWAM made.

Bill Stewart  [EMAIL PROTECTED] 

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

Re: potential new IETF WG on anonymous IPSec

2004-09-11 Thread Bill Stewart
At 12:57 PM 9/9/2004, Hal Finney wrote:
To clarify, this is not really anonymous in the usual sense.  Rather it
is a proposal to an extension to IPsec to allow for unauthenticated
connections.  Presently IPsec relies on either pre-shared secrets or a
trusted third party CA to authenticate the connection.  The new proposal
would let connections go forward using a straight Diffie-Hellman type
exchange without authentication.  It also proposes less authentication
of IP message packets, covering smaller subsets, as an option.
I read the draft, and I don't see how it offers any improvement
over draft-ietf-ipsec-internet-key-00.txt or Gilmore's proposal touse open 
secret as a not-very-secret pre-shared secret
that anybody who wants to can accept.
It does introduce some lower-horsepower alternatives for
authenticating less than the entire packet, and suggests
using AH which I thought was getting rather deprecated these days,
but another way to reduce horsepower needs is to use AES instead of 3DES.

Also, the author's document discusses protecting BGP to prevent
some of the recent denial-of-service attacks,
and asks for confirmation about the assertion in a message
on the IPSEC mailing list suggesting
   E.g., it is not feasible for BGP routers to be configured with the
   appropriate certificate authorities of hundreds of thousands of peers.
Routers typically use BGP to peer with a small number of partners,
though some big ISP gateway routers might peer with a few hundred.
(A typical enterprise router would have 2-3 peers if it does BGP.)
If a router wants to learn full internet routes from its peers,
it might learn 1-200,000, but that's not the number of direct connections
that it has - it's information it learns using those connections.
And the peers don't have to be configured rapidly without external 
assistance -
you typically set up the peering link when you're setting up the
connection between an ISP and a customer or a pair of ISPs,
and if you want to use a CA mechanism to certify X.509 certs,
you can set up that information at the same time.

Bill Stewart  [EMAIL PROTECTED] 

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

Re: ?splints for broken hash functions

2004-09-06 Thread Bill Stewart

how about this simpler construction?
  (IV1) - B1 - B2 - B3 - ... Bk - H1
  (IV2) - B1 - B2 - B3 - ... Bk - H2
This approach and the cache Block 1 until the end approach
are both special-case versions of maintain more state attacks.
This special case maintains 2*(size of hash output) bits of state.
The cache block 1 case maintains
(size of hash output) + (size of block 1) bits of state,
but doesn't change the (size of block 1) bits between cycles.
(Also, if you're going to do that, could you maintain
(hash(Block1)) bits between cycles instead of the raw bits?)
They both have some obvious simplicity to them,
but I'm not convinced that simplicity actually helps,
compared to other ways of getting more state.
Perhaps the effective state of the 2-IV version is
twice the size of the basic hash, perhaps it's less.
My intuition is that more mixing might be better,
and probably isn't worse, but I could easily be wrong.

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

Re: Compression theory reference?

2004-09-06 Thread Bill Stewart
It's a sad situation when you have to get a non-technical
judge to resolve academic conflicts like this,
but it's your head that you're banging against the wall, not mine.
If you want to appeal to authority, there's the FAQ,
which of course requires explaining the Usenet FAQ traditions;
perhaps you can find Lempel, Ziv, or Welch?
In reality, you could show an algorithm for which any input
gets at most _one_ bit longer, rather than arbitrarily longer.
And of course most of the compression algorithms work because
real data almost always has structure which reduces the entropy.
My information theory books from grad school have
long vanished into some closet, and were written
just about the time LZ came out so they mainly discuss
Huffman coding in the discrete-message sections,
but you should be able to find a modern book on the topic.
Matt Crawford's inductive argument is very strong -
it gives you a constructive way to say that
for any integer N, I can give a proof for that N,
starting at 1 and working your way up,
showing that if there's a lossless coding that doesn't make
any messages of length N any longer, then it doesn't make any any shorter,
so it's not a compression method, just a permutation.
The You could compress any message down to 1 bit
argument is a great throwaway line, but it isn't rigorously valid.
(And if it were, you might as well compress down to zero bits while you're 
at it.)
The problem is that for most lossless compression algorithms,
some strings will get shorter (maybe even much shorter),
but some will stay the same length,
so even if you had a hypothetical never gets longer
compression algorithm, you can't guarantee that your
starting message would be one that got shorter as opposed to staying the same,
so you can't say that all messages would compress to zero.

If your judge doesn't like inductions that count up,
or your academic opponents insist on examining methods that count down,
Bear's argument gets you most of the way there,
by emphasizing the 1-1 mapping aspect, but you could easily get tangled.
(To do this properly, you need to do n and 2**n, but I'll use 10 for 

There are 1024 10-bit messages, and only 512 9-bit messages,
so something obviously happened to the =512 that didn't compress to 9 bits.
Maybe 512 of them didn't compress further and stayed as 10-bit;
almost certainly some of them became 8 bits or shorter.
At least one message didn't get shorter, because
(2**10 - 1) = 2**9 + 2**8 + 2**7 ... + 2**1
So if you want to recurse downwards through repeated compression,
you need to be sure your mapping keeps track of the ones that
didn't compress the first time (maybe they'll compress the second time?),
the ones that compressed by one bit,
and the ones that compressed by more than one bit,
and avoid wandering around in a maze of twisty little passages.
So working your way up is probably cleaner.
At 11:30 AM 9/1/2004, bear wrote:
Actually you don't need to take it all the way to the
reductio ad absurdum here.  There are 1024 10-bit
messages.  There are 512 9-bit messages.  You need
to point out that since a one-to-one mapping between
sets of different ordinality cannot exist, it is not
possible to create something that will compress every
ten-bit message by one bit.
Or, slightly more formally, assume that a function C
can reversibly compress any ten-bit message by one bit.
Since there are 1024 distinct ten-bit messages, there
must be at least 1024 distinct nine-bit messages which,
when the reversal is applied, result in these 1024
messages.  There are exactly 512 distinct nine-bit
messages.  Therefore 512 = 1024.
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Bill Stewart  [EMAIL PROTECTED] 

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

Re: First quantum crypto bank transfer

2004-08-24 Thread Bill Stewart
At 02:02 AM 8/23/2004, Florian Weimer wrote:
* Bill Stewart:
 I agree that it doesn't look useful, but lawful intercept is harder,
 if you're defining that as undetected eavesdropping with
 possible cooperation of the telco in the middle,
 because quantum crypto needs end-to-end fiber so there's
 nothing the telco can help with except installing dark fiber,
 and the quantum crypto lets you detect eavesdroppers.
But this doesn't scale.
You'd need dark fiber to all communication partners.
Yes.  That's part of one definition of doesn't look useful.
So if quantum key distribution was mandated for
applications involving more than just a handful communication
partners, you'd need relays (or rather unlikely advances in optical
circuit switching).
It would be possible to use it as link encryption,
giving up the benefits of end-to-end in return for better scaling,
but you could still make all the relaying happen in the
user organization's facilities, rather than in a telco building
that's outside the user organization's control.
(Just because something isn't very useful doesn't mean you can't
at least try to do the job semi-correctly...)
By the way, the complete bashing of the recent QKD experiment is
probably not totally deserved.  Apparently, the experimenters used a
QKD variant that relies on quantum teleportation of photons.
This QKD variant is currently *not* available commercially,
and the experiment itself could well be an important refinement of
Zeilinger's earlier work in this area.
That's at least interesting, though I don't see why you'd take
the experiment out of the lab without a really well-defined
benefit to the end user (unless you've got a research grant.)
I'm surprised to hear that _any_ quantum key distribution variant
is available commercially, given the costs of dedicating fiber
and the effectiveness of current mathematical crypto
or the alternative approach of couriers with briefcases and handcuffs.

Bill Stewart  [EMAIL PROTECTED] 

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

Re: First quantum crypto bank transfer

2004-08-22 Thread Bill Stewart
At 01:00 PM 8/21/2004, Florian Weimer wrote:
However, I still don't believe that quantum cryptography can buy you
anything but research funding (and probably easier lawful intercept
because end-to-end encryption is so much harder).

I agree that it doesn't look useful, but lawful intercept is harder,
if you're defining that as undetected eavesdropping with
possible cooperation of the telco in the middle,
because quantum crypto needs end-to-end fiber so there's
nothing the telco can help with except installing dark fiber,
and the quantum crypto lets you detect eavesdroppers.
On the other hand, at least in the US and probably in Germany,
if the government wants the records of a bank's transactions,
all they need is the locally-proper paperwork demanding the data,
which is a threat model that quantum crypto doesn't help with,
especially since the costs of that attack are much lower than
tapping quantum fiber transactions.
An intermediate level of weakness is detection of who
the bank is communicating with.  In the case of quantum crypto,
it's simple - just follow the fiber to the other end.
But banks are a semi-special case for this threat also,
because you know that a bank's headquarters will talk to
other buildings belonging to that bank, so it's no information leak...
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: Cryptome on ABC Evening News?

2004-08-17 Thread Bill Stewart
At 03:32 PM 8/12/2004, R. A. Hettinga wrote:
There's a teaser for tonight's 6:30 news about a website that publishes
pipeline maps and the names and addresses of government employees. The 

Speaking unofficially for the telecom industry,
we're really happy to have the site there
showing pictures of cable landings, antennas, etc.
I've seen them used in internal training about submarine cables
and I think we've probably used them in talks to customers as well.
Separately, of course, we have bureaucrats who don't want to
publish the addresses of telecom POPs, ignoring the fact
that you can't buy physically diverse access to a location
if you don't know where it is, and also ignoring the fact
that 90% of a certain large 3-1/2-letter-acronym long distance carrier's
POPs are in the same buildings as the local telcos
so everybody knows where they are anyway,
even though everybody's forgotten the derivation of VH coordinates...

Bill Stewart  [EMAIL PROTECTED] 

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

Re: Using crypto against Phishing, Spoofing and Spamming...

2004-07-28 Thread Bill Stewart
At 03:20 AM 7/18/2004, Enzo Michelangeli wrote:
Can someone explain me how the phishermen escape identification and
prosecution? Gaining online access to someone's account allows, at most,
to execute wire transfers to other bank accounts: but in these days
anonymous accounts are not exactly easy to get in any country, and anyway
any bank large enough to be part of the SWIFT network would cooperate in
the resolution of obviously criminal cases.
At least until a few years ago, and probably still today,
it was easy to get a non-anonymous account in the US using fake ID.
The Know Your Customer laws and other anti-terrorism fallout
may have encouraged banks to check SSNs a bit more carefully,
but as long as the person whose identity you're stealing
doesn't have horrendously bad or good credit,
it's probably still not hard.
If it costs you $100 in fake ID to get the account set up,
and you can burn the phish for $1000, then you win.
But credit cards are probably more common and certainly easier to use.
Buy laptops or other fungible goods, and sell them on eBay.
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: The future of security

2004-06-02 Thread Bill Stewart
At 05:15 AM 6/2/2004, Ben Laurie wrote:
SPF will buy me one thing forever: I won't get email telling me I sent 
people spam and viruses.
Unfortunately, that won't work for me.
My email address is at, the mail forwarding service
where the main proponent of SPF works,
but my SMTP service is whichever ISP I'm currently connected through
(DSL, dial, work, whatever) - which isn't under pobox's control.
So my incoming mail can recognize SPFs and block forgeries,
but my outgoing mail can't use them,
unless pobox changes their business model to provide outgoing SMTP relay
for their customers, doubling their bandwidth needs.
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: [camram-spam] Re: Microsoft publicly announces Penny Black PoW postage project

2003-12-31 Thread Bill Stewart
At 07:46 PM 12/30/2003 +, Richard Clayton [EMAIL PROTECTED] wrote:
 [what about mailing lists]
Obviously you'd have to whitelist anybody's list you're joining
if you don't want your spam filters to robo-discard it.
I never understand why people think spam is a technical problem :( let
alone a cryptographic one :-(
The reason it's partly a cryptographic problem is forgeries.
Once everybody starts whitelisting, spammers are going to
start forging headers to pretend to come from big mailing lists
and popular machines and authors, so now you'll not only
need to whitelist Dave Farber or Declan McCullough if you read their lists,
or Bob Hettinga if you're Tim (:-), you'll need to verify the
signature so that you can discard the forgeries that
pretend to be from them.
You'll also see spammers increasingly _joining_ large mailing lists,
so that they can get around members-only features.
At least one large mailing list farm on which I've joined a list
used a Turing-test GIF to make automated list joining difficult,
and Yahoo limits the number of Yahoogroups you can join in a day,
but that's the kind of job which you hire groups of Indians
or other English-speaking third-world-wagers to do for you.

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

Re: Microsoft publicly announces Penny Black PoW postage project

2003-12-29 Thread Bill Stewart
At 09:37 PM 12/26/2003 -0500, Adam Back wrote:
The 2nd memory [3] bound paper (by Dwork, Goldber and Naor) finds a
flaw in in the first memory-bound function paper (by Adabi, Burrows,
Manasse, and Wobber) which admits a time-space trade-off, proposes an
improved memory-bound function and also in the conclusion suggests
that memory bound functions may be more vulnerable to hardware attack
than computationally bound functions.  Their argument on that latter
point is that the hardware attack is an economic attack and it may be
that memory-bound functions are more vulnerable to hardware attack
because you could in their view build cheaper hardware more []
Once nice thing about memory-bound functions is that,
while spammers could build custom hardware farms in Florida or China,
a large amount of spam is delivered by hijacked PCs or abused relays/proxies,
which run on standard PC hardware, not custom, so it'll still be slow.
Penny Black or any other system that involves tweaking the email protocols
gets a one-time win in blocking spam, because older badly-administered
mail relays won't be running the new system - if their administrators
upgrade them to support the new features, hopefully that will turn off
any relay capabilities.  That doesn't apply to cracked zombie machines,
since the crackers can install whatever features they need,
but at least all of those Korean cable-modem boxes won't run it.

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

Re: Difference between TCPA-Hardware and a smart card (was: example:secure computing kernel needed)

2003-12-22 Thread Bill Stewart

At 09:38 AM 12/16/2003 -0500, Ian Grigg wrote:

In the late nineties, the smart card world
worked out that each smart card was so expensive,
it would only work if the issuer could do multiple
apps on each card.  That is, if they could share
the cost with different uses (or users).
Of course, at this point the assertion that a smart card
(that doesn't also have independent user I/O)
costs enough to care about is pretty bogus.
Dumb smartcards are cost-effective enough to use them
to carry $5 in telephone minutes.
The real constraint is that you're unlikely to have
more than one card reader in a machine,
so multifunction cards provide the opportunity to
run multiple applications without switching cards in and out,
but that only works if the application vendors cooperate.
For instance, you may have some encrypted session application
that needs to have your card stay in the machine during the session
(e.g. VOIP, or secure login, SSH-like things, remote file system access),
and you may want to pay for something using your bank smartcard
during the session.  That's not likely to work out,
because the secure session software vendors are
unlikely to have a relationship with your bank that lets
both of them trust each other with their information,
compared to the simpliciy of having multiple cards.
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: example: secure computing kernel needed

2003-12-14 Thread Bill Stewart
At 02:41 PM 12/14/2003 +, Dave Howe wrote:
Paul A.S. Ward wrote:
 I'm not sure why no one has considered the PC banking problem to be a
 justification for secure computing.  Specifically, how does a user
 know their computer has not been tampered with when they wish to use
 it for banking access.
I think PC banking is an argument *against* Secure Computing as currently
proposed - there is no way to discover if there is a nasty running in
protected memory or removing it if there is.
Agreed.  It's a better argument for booting from a known CDROM distribution.

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

RE: Open Source Embedded SSL - (License and Memory)

2003-11-29 Thread Bill Stewart
[Moderator's note: I'd really like to shut down the What license?
debate --Perry]
At 12:52 AM 11/27/2003 -0800, J Harper wrote:
 1) Not GPL or LPGL, please.  I'm a fan of the GPL for most things, but

 for embedded software, especially in the security domain, it's a
 killer.  I'm supposed to allow users to modify the software that runs
 on their secure token?  And on a small platform where there won't be
 such things as loadable modules, or even process separation, the
 (L)GPL really does become viral.  This is, I think, why Red Hat
 releases eCos under a non-GPL (but still open source) license.
We're aware of these issues.  How do other people on the group feel?
That's an obvious call for a BSD / C-News style license
- You're free to copy it but leave our copyright notice in.
- You acknowledge that you got it for free and that any consequences,
no matter how horrible, of what you do with it are not our 
- You're free to change it, but only if you include a notice that you 
changed it.
- Maybe something about you must either distribute the licensed source code
for no more than a copying/handling charge or else a pointer to 
the original.

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

Re: Open Source Embedded SSL - Export Questions

2003-11-29 Thread Bill Stewart
At 02:45 PM 11/27/2003 +1100, Greg Rose wrote:
At 12:27 PM 11/27/2003, Thor Lancelot Simon wrote:
RC4 is extremely weak for some applications.
A block cipher is greatly preferable.
I'm afraid that I can't agree with this howling logical error.
RC4 is showing its age, but there are other stream ciphers
that are acceptable, and there are block ciphers
(such as FEAL, same vintage as RC4) that aren't even vaguely secure.
Well, to be more precise,
RC4 has restrictions on the ways you can use it that
make its crypto strength fail very badly if you violate them,
and because it's an XOR stream cypher there are sometimes
things you can't do with it that you could do with a block cypher.
RC4 does also have the historical problem that people sometimes
decide to use it with 40-bit keys because they can...
OTOH, of course being a block cypher isn't enough to guarantee
either strength or usefulness, e.g. bass-o-matic.

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

Re: New authentication protocol, was Re: Tinc's response to 'Linux's answer to MS-PPTP'

2003-09-30 Thread Bill Stewart
 =Step 1:
 Exchange ID messages. An ID message contains the name of the tinc
 daemon which sends it, the protocol version it uses, and various
 options (like which cipher and digest algorithm it wants to use).

By name of the tinc daemon, do you mean identification information?
That data should be encrypted, and therefore in step 2.
(Alternatively, if you just mean tincd version, that's fine.

 Step 2:
 Exchange METAKEY messages. The METAKEY message contains the public part
 of a key used in a Diffie-Hellman key exchange.  This message is
 encrypted using RSA with OAEP padding, using the public key of the
 intended recipient.

You can't encrypt the DH keyparts using RSA unless you first exchange
RSA public key information, which the server can't do without knowing
who the client is (the client presumably knows who the server is,
so you _could_ have the client send the key encrypted to annoy MITMs.)
To make the protocol generally useful for privacy protection,
you shouldn't exchange this information unencrypted.
So do a Diffie-Hellman exchange first, then exchange any other information,
including RSA signatures on the DH keyparts.

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

Re: New authentication protocol, was Re: Tinc's response to 'Linux's answer to MS-PPTP'

2003-09-30 Thread Bill Stewart

 If we use RSA encryption, then both sides know their message can only
 be received by the intended recipient. If we use RSA signing, then we
 both sides know the message they receive can only come from the assumed
 sender. For the purpose of tinc's authentication protocol, I don't see
 the difference, but...

  Now, the attacker chooses 0 as his DH public. This makes ZZ always
  equal to zero, no matter what the peer's DH key is.

You need to validate the DH keyparts even if you're
corresponding with the person you thought you were.
This is true whether you're using signatures, encryption, or neither.

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

Re: Code breakers crack GSM cellphone encryption

2003-09-08 Thread Bill Stewart
Trei, Peter wrote:
Why the heck would a government agency have to break the GSM encryption
at all? The encryption is only on the airlink, 
 and all GSM calls travel through the POTS land line system in the clear,
 where they are subject to warranted wiretaps.
Breaking GSM is only of useful if you have no access to the landline
portion of the system.
Some governments are more concerned about using warrants
than others are.  Sometimes the ones that are concerned about them
also have police agencies that like to avoid using them.
Some phone companies are pickier about paperwork than others.
Some phone companies are faster about responding than others.
Having governments that are officially less concerned about warrants
is often correlated with having monopoly phone companies,
which is often correlated with slow bureaucratic response -
they may be extremely happy to help out the police,
but that doesn't mean it doesn't take 18 steps to accomplish it.
Landline-based wiretaps work best if you know the phone number;
over-the-air systems can be more flexible about picking up
any phone nearby, so if you see your target pick up a phone,
but don't know its phone number, they're more convenient.
And in landline-tapping environments, clever law-evaders
can usually acquire the equipment to keep switching phones.

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

Re: Is cryptography where security took the wrong branch?

2003-09-07 Thread Bill Stewart
Ian Grigg wrote:
Pretty much.  Trust in the certificate world means that
a CA has authorised a web server to conduct crypto stuff.
and James Donald and Lynn Wheeler also brought up the issues
of who's certifying what, True Names, etc.
SSL certs are really addressing (I won't say solving, exactly)
two different problems -
- Whether the communication session you're setting up with is really set up with them and not a MITM
- Whether is slightly more likely to be run by Example Inc.,
and not some impostor like Example-Nigeria Ltd
or Bad Example Spa Resort, GMBH, both of whom
happily accept all major credit cards.
DNSSEC (or something like it) takes care of the first problem,
without the intervening step of requiring True Names.
It doesn't help the second problem, and DNS doesn't either,
which is one reason that ICANN is so insistent on getting True Names
for whois records and forcing registrars to get them as well.
It's possible to get some uncertified human-readable information
about a domain name from its whois records.
It's possible to get more human-readable information from SSL certs,
and in some cases that information might be certified in a meaningful way,
but in other cases it's not, and browsers aren't typically very good at
telling you that information unless you try hard to get it,
and when they do nag users about it, users usually ignore it.
But it's not always even useful information - Bad Example might have
a cert from because they take Visa cards at their spa,
but you may be on their _other_ web site that's selling cheap knockoffs of 
whatever the Example Inc. you were trying to deal with sells.
Your browser isn't smart enough to know that.

While DNSSEC mostly follows a hierarchical model, that doesn't mean
that you couldn't get some user-friendly or browser-friendly
certification model that does provide multi-homed values for
rating information about web sites - Consumer Reports or the
Better Business Bureau or whatever could do signed statements
about domain names without building it into DNS or SSL.

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

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

2003-06-30 Thread Bill Stewart
At 11:49 PM 06/29/2003 +0200, Simon Josefsson wrote:
No, I believe only one of the following situations can occur:

* Your laptop see and uses the name, and the DNS server
  translate them into  If your laptop
  knows the DNSSEC root key, the attacker cannot spoof since
  it doesn't know the key.  This attack is essentially a
  man-in-the-middle attack between you and your recursive DNS server.
That doesn't happen.  (Well, it could, but as you point out,
it's not a successful attack methodology, because DNSSEC was designed
to correctly take care of this.)
* Your laptop see and uses the name
  You may be able to verify this using your DNSSEC root key, if the people have set up DNSSEC for their spoofed
  entries, but unless you are using bad software or judgment, you will
  not confuse this for the real
The DNS suffix business is designed so that your laptop tries
to use, either before
or after unsuccessfully trying, depending on implementation.
It may be bad judgement, but it's designed to support intranet sites
for domains that want their web browsers and email to let you
refer to marketing as opposed to,
and Netscape-derived browsers support it as well as IE.
Of course, everything fails if you ALSO get your DNSSEC root key from
the DHCP server, but in this case you shouldn't expect to be secure.
I wouldn't be surprised if some people suggest pushing the DNSSEC root
key via DHCP though, because alas, getting the right key into the
laptop in the first place is a difficult problem.
I agree with you and Steve that this would be a Really Bad Idea.
The only way to make it secure is to use an authenticated DHCP,
which means you have to put authentication keys in somehow,
plus you need a reasonable response for handling authentication failures,
which means you need a user interface as well.
It's also the wrong scope, since the DNSSEC is global information,
not connection-oriented information, so it's not really DHCP's job.

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

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

2003-06-29 Thread Bill Stewart
At 11:15 PM 06/28/2003 -0400, Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], Bill Stewart writes:
This looks like it has the ability to work around DNSSEC.
Somebody trying to verify that they'd correctly reached
would instead verify that they'd correctly reached, which can provide all the signatures
it needs to make this convincing.

So if you're depending on DNSSEC to secure your IPSEC connection,
do make sure your DNS server doesn't have a suffix of
No, that's just not true of DNSsec.  DNSsec doesn't depend on the
integrity of the connection to your DNS server;
rather, the RRsets are digitally signed.
In other words, it works a lot like certificates,
with a trust chain going back to a magic root key.
I thought about that, and I think this is an exception,
because this attack tricks your machine into using the
trust chain, which it controls,
instead of the trust chain, which DNSSEC protects adequately.
So you're getting a trustable answer to the wrong query.
I'm less sure of the implementation issues of the
Connection-specific DNS suffix, and I've seen conflicting documentation.
If the resolver looks up domain.suffix before domain,
then the attacker's DNS doesn't need to control the DNS access,
and only needs to provide the attacker's certificates,
but if the resolver looks up domain before domain.suffix,
then the attacker also needs to make sure that the lookup of domain fails,
which is most easily done by telling the DHCP client to use
the attacker's DNS server along with telling it the suffix.
(That doesn't add any extra work to the attack, but does make it
a bit easier to trace the attacker after the fact;
if you're not replacing the attacker's DNS server entry,
then all you need is a legitimate-looking server for
*  In either case, somebody who can
pull off this kind of an attack probably uses a compromised machine
to run the DNS server on anyway.)
I'm not saying that
there can't be problems with that model, but compromised DNS servers
(and poisoned DNS caches) are among the major threat models it was
designed to deal with.  If nothing else, the existence of caching DNS
servers, which are not authoritative for the information they hand out,
makes a transmission-based solution pretty useless.
DNSSEC seems to do a pretty thorough job of making sure that
if you look up the correct domain name, you'll get the correct answer,
in spite of attackers trying to prevent it.
But this attack tricks you into looking up the wrong domain name,
and DNSSEC makes sure that you get the correct answer for the wrong name,
which isn't the result you want.

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

Attacking networks using DHCP, DNS - probably kills DNSSEC

2003-06-28 Thread Bill Stewart
Somebody did an interesting attack on a cable network's customers.
They cracked the cable company's DHCP server, got it to provide a
Connection-specific DNS suffic pointing to a machine they owned,
and also told it to use their DNS server.
This meant that when your machine wanted to look up,
it would look up instead.
This looks like it has the ability to work around DNSSEC.
Somebody trying to verify that they'd correctly reached
would instead verify that they'd correctly reached, which can provide all the signatures
it needs to make this convincing.
So if you're depending on DNSSEC to secure your IPSEC connection,
do make sure your DNS server doesn't have a suffix of
RISKS-LIST: Risks-Forum Digest  Saturday 17 June 2003  Volume 22 : Issue 78
Date: Fri, 20 Jun 2003 15:33:15 -0400
From: Tom Van Vleck [EMAIL PROTECTED]
Subject: ISP's DHCP servers infiltrated

... It turns out, Charter Communications' DHCP servers were
infiltrated and were providing as the
'Connection-specific DNS suffix', causing all non-hardened Windows
(whatever that means in a Windows context) machines to get lookups
from a hijacked subdomain DNS server which simply responded to every
query with a set of 3 addresses (,,
On these IPs were some phantom services. There were proxying Web
servers (presumably collecting cookies and username/password combos),
as well as an ssh server where the perpetrators were most likely
hoping people would simply say 'yes' to the key differences and enter
in their username/password...
Hmm, my cable ISP was down this morning.  Maybe coincidence.

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

Re: PGP Encryption Proves Powerful

2003-06-04 Thread Bill Stewart
At 11:38 AM 05/30/2003 -0700, John Young wrote:
If the FBI cannot crack PGP that does not mean other
agencies with greater prowess cannot. It is unlikely that
the capability to crack PGP would be publicly revealed
for that would close an invaluable source of information.
Still, it is impressive that PRZ valiantly argues that PGP is
algorithmically impregnable. That should satisfy its users as
well as its crackers.
And Phil was quoted as saying
 Does PGP have a back door? The answer is no, it does not,
 he said. If the device is running PGP it will not be possible
 to break it with cryptanalysis alone.
But in fact that's incorrect.  PGP doesn't have back doors,
but it has two major weaknesses, which are weak user-chosen passphrases,
combined with a secret key file format that makes it easy to
verify whether a key has been guessed correctly,
and human-rememberable passphrases, combined with
rubber-hose cryptanalysis and a captured agent.
If you're doing good operational security, and the
Red Brigades probably are, your passphrases have good enough entropy
that they're hard to crack, but if they got sloppy,
and someone wants to feed all the information that's known about them
to pgpcrack, it's possible that they'll find something.
It's less likely than VENONA succeeding, because the importance
of good passphrases was known, and unlike one-time pads there's
no operational need to occasionally get sloppy under time pressure.
I'm not aware of a PGP port to the Psion, but at least the
Psion 3/3a/3c generation were 8086-like processors,
and there was a C compiler ported to them,
so perhaps somebody ported one of the earlier PGPs.
(There was an old HP palmtop that ran genuine MS-DOS,
unlike the Psion's more interesting operating system,
and you could probably run PGP on that directly.)
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: PGP Encryption Proves Powerful

2003-06-04 Thread Bill Stewart
At 08:17 AM 06/03/2003 -0700, bear wrote:
what he said was with cryptanalysis alone.
Rubber-hose methods are not cryptanalysis, and
neither is password guessing.
Eh?  Password guessing certainly is.

I'm not aware of a PGP port to the Psion, but at least the
Psion 3/3a/3c generation were 8086-like processors,
and there was a C compiler ported to them,
so perhaps somebody ported one of the earlier PGPs.
IIRC, there was/is a psion linux port, with gcc.
Looks like it's still in active development,
mainly for the Psion 5 series - they've even got
X Windows running on them, as well as PGP.
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: New vs Old (was Snake Oil)

2003-06-04 Thread Bill Stewart
At 08:53 AM 06/03/2003 -0700, bear wrote:
IDEA is still a good cipher as far as I know, but PGP has been driven
away from it in the US due to intellectual-property issues.  Rather than
continue with incompatible versions for use inside/outside the USA, they're
switching to CAST (although this is causing more, rather than less, version
Actually, they switched to letting the user choose algorithms,
with CAST as the default but others such as 3DES available.
One of the compatibility issues is that people have written
patches for GPG that implement IDEA, so some users' systems support it
and others don't.  On the other hand, that mainly bothers the
people who've picked only accept IDEA for their symmetric algorithms.
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

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

2003-06-04 Thread Bill Stewart
At 11:38 AM 06/03/2003 -0400, Ian Grigg wrote:
I (arbitratrily) define the marketplace for SSL as browsing.
There, we can show statistics that indicate that SSL
has penetrated to something slightly less than 1% of servers.
For transmitting credit card numbers on web forms,
I'd be surprised if there were 1% of the servers that *don't* use SSL/TLS.
Virtually all deployed browsers support SSL, except a few
special-purpose versions.  The web servers supporting
almost all of the web support SSL if they have keys installed.
While many of them haven't bothered paying money for certified keys
or doing self-signed keys, I'd be surprised if it's really
as low as 1%.  What's your source for that figure?
While only a small fraction of web pages, and a much smaller
fraction of web bits transmitted, use SSL, that's appropriate,
because most web pages are material the publisher wants the public to see,
so eavesdropping isn't particularly part of the threat model,
and even integrity protection is seldom a realistic worry.
(By contrast, eavesdropping protection and integrity protection
are critical to telnet-like applications, so SSH is a big win.)
It's nice to have routine web traffic encrypted,
so that non-routine traffic doesn't stand out,
and so that traffic analysis is much harder,
but there is a significant CPU hit from the public-key phase,
which affects the number of pages per hour that can be served.
Corporate intranet web traffic carried across the public internet
sometimes uses SSL, but usually uses IPSEC because that also supports email.

In addition to web browsing and email submission,
there's an emerging market for SSL-based VPNs appliances.
Neoteris is one of the pioneers, and Aventail and some others are players.
The intention is that you can get clientless (browser-based)
support for intranet web browsing and email,
and lightweight client support for telnet,
while only having to buy an overpriced server box.
(And the box doesn't even need crypto accelerator help,
because the public-key phase only gets used for login,
while most sessions are long enough that this amortizes quickly.)
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Nullsoft's WASTE communication system

2003-05-31 Thread Bill Stewart - Overview - Security section - Network design 
- Slashdot discusssion

Nullsoft, who did Winamp and Gnutella, just released a package called W A S T E
which does encrypted communications within small groups of people.
It doesn't appear to have had outside analysis of its security yet,
but they do invite it, and they say it needs some work.
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]