Re: cryptograph(y|er) jokes?

2004-06-24 Thread Arnold G. Reinhold
At 11:56 PM +0200 6/19/04, Hadmut Danisch wrote:
does anyone know good jokes about
cryptography, cryptographers, or security?

Q: How many cryptographers does it take to change a light bulb?
There was a story in the NY Times many years ago  about an apartment 
dweller who was frequently burgled. Every time that happened she had 
a new lock added to her front door. While installing her eighth lock, 
the locksmith suggested she only lock half of the locks. Her place 
was never robbed again, but sometime she came home to find the locks 
she had locked open and the ones she hadn't locked were locked.

Also see numbers 2.3 and 2.4 in the humorous list of proof techniques 

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

Re: Is finding security holes a good idea?

2004-06-16 Thread Arnold G. Reinhold
The Mythical Man-Month is a great book, but it's almost 30 years 
old. Brooks considered OS/360 to be hopelessly bloated. My favorite 
quote (from Chapter 5, The Second System Effect, p. 56):

For example, OS/360 devotes 26 bytes of the permanently resident 
date-turnover routine to the proper handling of December 31 on leap 
years (when it is Day 366). That might have been left to the 

Modern operating system are 2 to 3 orders of magnitude larger than 
OS/360.. They are far more reliable than OS/360 was in its early days 
and do not presume the availability of an on-site team of operators 
and system programmers.  For the most part they are still maintained 
one bug at a time The bug fixing process has not reached Brook's 
predicted crisis.

My other concern with the thesis that finding security holes is a bad 
idea is that it treats the Black Hats as a monolithic group. I would 
divide them into three categories: ego hackers, petty criminals, and 
high-threat attackers (terrorists, organized criminals and evil 
governments).  The high-threat attackers are  likely accumulating 
vulnerabilities for later use. With the spread of programming 
knowledge to places where labor is cheap, one can imagine very 
dangerous systematic efforts to find security holes.  In this context 
the mere ego hackers might be thought of as beta testers for IT 
security.  We'd better keep fixing the bugs.

Arnold Reinhold

At 5:10 PM -0400 6/14/04, Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], Ben Laurie writes:
What you _may_ have shown is that there's an infinite number of bugs in
any particularly piece of s/w. I find that hard to believe, too :-)
Or rather, that the patch process introduces new bugs.  Let me quote
from Fred Brooks' Mythical Man-Month, Chapter 11:
The fundamental problem with program administration is that fixing
a defect has a substantial (20-50 percent) chance of introducing
another.  So the whole process is two steps forward and one step
Why arene't defects fixed more cleanly?  First, even a subtle
defect shows itself as a local failure of some kind.  In fact it
often has system-wide ramifications, usually nonobvious.  Any
attempt to fix it with minimum effort will repair the local and
obvious, but unless the structure is pure or the documentation
very fine, the far-reaching effects of the repair will be
overlooked.  Second, the repairer is usually not the man who wrote
the code, and often he is a junior programmer or trainee.
As a consequence of the introduction of new bugs, program
maintenance requires far more system testing per statement written
than any other programming.
Lehman and Belady have studied the history of successive release
in a large operating system.  They find that the total number of
modules increases linearly with release number, but that the
number of modules affected increases exponentially with release
number.  All repairs tend to destroy the structure, to increase
the entropy and disorder of the system.  Less and less effort is
spent on fixing original design flaws; more and more is spent on
fixing flaws introduced by earlier fixes.  As time passes, the
system becomes less and less well-ordered.  Sooner or later the
fixing ceases to gain any ground.  Each forward step is matched by
a backward one.
Etc.  In other words, though the original code may not have had an
infinite number of bugs, the code over time will produce an infinite
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: Satellite eavesdropping of 802.11b traffic

2004-05-28 Thread Arnold G. Reinhold
At 9:19 PM -0400 5/27/04, Perry E. Metzger wrote:
R. A. Hettinga [EMAIL PROTECTED] writes:
 At 12:35 PM -0400 5/27/04, John Kelsey wrote:
Does anyone know whether the low-power nature of wireless LANs protects
them from eavesdropping by satellite?
 It seems to me that you'd need a pretty big dish in orbit to get that kind
 of resolution.
 The Keyholes(?) are for microwaves, right?
Dunno if it would work in orbit,, but you can get surprising results
right here on earth using phased arrays.
Vivato is selling very long range phased array equipment as long
range/high quality 802.11 basestations, but you could do precisely the
same trick to eavesdrop instead of to communicate. With enough
computing power, one device could listen in on every 802.11
communication in a very large radius.
I don't know how practical it would be to set up some sort of large
scale phased array in orbit -- I suspect the answer is not practical
at all -- but the principle could apply there, too.
I would say quite practical. A huge advantage for the attacker is 
that 802.11b/g is in a fixed frequency band. A half-wave dipole is 
6.25 cm long. A large phased array could be assembled out of printed 
circuit board tiles, each with many antennas.

The outdoor range for 802.11 is up to 100 m.  Low earth orbit is 
about 150 km.  That is a factor of 1500. Power attenuation is the 
square of that, which works out to a 64 db loss.  Throw in another 10 
db for slant range, building attenuation, etc. The loss has to be 
made up by a combination of antenna gain, improved receiver 
performance and better signal processing. That doesn't sound undoable.

A single LEO satellite would only have a few minutes of visibility 
per day over any one location on Earth. That suggests an active 
attack, where the satellite looks for files or even changes data. The 
satellite's ability to transmit at much higher power levels is an 

A third option is spot jamming. Here high power means one can get 
away with a smaller antenna, perhaps wrapped around a cheaper spin 
stabilized satellite.  Such a system could be used to briefly disable 
802.11-based security systems, perhaps allowing a spy to gain access 
to a building.

Other interesting possibilities include long endurance 
remotely-piloted aircraft, balloons and small receiving stations that 
could be planted by spies or even parachuted into position. I'm sure 
802.11 has given the SIGINT community much joy.

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

Re: The future of security

2004-05-25 Thread Arnold G. Reinhold
At 8:21 PM +0100 4/26/04, Graeme Burnett wrote:
Hello folks,
I am doing a presentation on the future of security,
which of course includes a component on cryptography.
That will be given at this conference on payments
systems and security:
Would anyone there have any good predictions on how
cryptography is going to unfold in the next few years
or so?  I have my own ideas, but I would love
to see what others see in the crystal ball.
Here are my thoughts on the future of cryptography:
A major use of crypto will be in efforts to restrict the 
dissemination of information to the public (corporate security, 
digital rights management, state censorship)

Human factors will be regarded as equal in importance with algorithms 
and protocols.

Servers and workstations will incorporate video and other sensors to 
provide self protection against physical intrusions.

As cellphones and PDAs merge there will be a new generation of 
privacy applications for text messaging and/or  voice that use light 
weight protocols and, perhaps symmetric keys.

Cellphone cameras will be used for stenographic communication.
Cellphones and PDAs will be used as security tokens for 
desktop/laptop access, perhaps using Bluetoth

Self-booting, open source CDs will become available that turn any PC 
into a secure messaging system with private keys and messages stored 
on an encrypted disk image on a memory stick.

4096-bit RSA keys will become the standard (RSA is already 
recommending 1024-bit keys be phased out by 2010.)

Key stretching techniques will be enhanced and standardized to allow 
password-based security to remain viable.

Password entry will be done using mouse and display screen, rather 
than keyboards because of all the risks keyboards represent (software 
and hardware loggers, video cameras, acoustic analysis, etc.)

Desktop systems with no hard drive and no I/O ports will become 
required for processing confidential information.

One or more secure networks will emerge that parallel the existing 
Internet. They will use IPv6 and have mandatory encryption and 

Cameras and audio recorders will be equipped with GPS, digital 
signing and secure time stamping technologies to restore confidence 
in  recorded evidence.

Stored value smart-cards will finally become popular in the U.S. 
through use in public transportation systems.

Hashcash will be used to bring spam under control and to protect 
networks against zombie attacks.

Anti-spam white listing will be the killer app that finally creates a 
universal public key infrastructure.

Patent concerns will be a major barrier to progress.
Arnold Reinhold
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: Definitions of Security?

2004-04-15 Thread Arnold G. Reinhold
At 4:01 PM +0200 4/14/04, [EMAIL PROTECTED] wrote:

I'm looking for interesting and unusal defitions of the
term Security (or secure).
I'm fully aware that it is difficult or impossible to give
a precise, compact, and universal definitions, and some
book authors explicitely say so. However, there are definitions
(or attempts to give those), and I'd be interested to compare
them. If you know of any definition that might be interesting
for any reason, please send me a link or citation. thanx
Here is one of mine that is biology inspired:

A division of a set of actors into 'self' and 'other' with a 
mechanism that allows self actors  to perform certain activities that 
are effectively denied to others.

Arnold Reinhold

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

Re: AES suitable for protecting Top Secret information

2004-04-15 Thread Arnold G. Reinhold
I was the one who updated the Wikipedia entry . It was shortly before 
the cryptography list came back up.  I found the June 2003 CNSS fact 
sheet while looking for other information on NIST's standards 
program. The first reference that I found that suggested AES could be 
used for classified was in a slide presentation at a Dec. 4, 2002 
NIST Wireless Security workshop  by 
Timothy Havighurst of NSA on DOD Wireless Policy

One slide reads:

 SECRET and TOP  SECRET data must be approved with a Type I algorithm
- AES (sufficient key length)
(I believe the BATON algorithm itself is still classified.)

This is a major milestone in cryptography. I believe it is the first 
time in modern history that the public knowingly has access to a 
cipher that the U.S. Government currently considers strong enough for 
Top Secret information.

Note that the CNSS fact sheet goes on to say:

The  implementation of AES in products intended to protect national 
security systems and/or  information must be reviewed and certified 
by NSA prior to their acquisition and use.

Another interesting  presentation at the same NIST workshop was by 
Bill Burr on NIST's Cryptographic Standards Program. It 
has a nice chart comparing the strengths of various crypto primitives 
based on their key length (page 7).  Anther slide (page 13) contains 
the following interesting statement:

Proposed 80-bit crypto end of use date: 2015

Based on the page 7 chart, this presumably includes SHA1, Skipjack, 
1024-bit RSA/DSA and 160-bit ECC.

Arnold Reinhold

At 12:34 PM -0400 4/14/04, Vin McLellan wrote:
I missed that announcement too -- but Wikipedia, the web-based Free 
Encyclopedia, caught it!  See Wikipedia on AES at:

The Wikipedia module on AES Security has a link to the same NSA fact 
sheet Steve mentioned.

I was surprised.  I thought, as in so many other things, the NSA was 
going to say one thing and do another.

At 4/14/2004, Steve Bellovin wrote:

I haven't seen this mentioned on the list, so I thought I'd toss it
out.  According to ,
AES is acceptable for protecting Top Secret data.  Here's the crucial
   The design and strength of all key lengths of the AES algorithm
   (i.e., 128, 192 and 256) are sufficient to protect classified
   information up to the SECRET level. TOP SECRET information will
   require use of either the 192 or 256 key lengths.
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: voting

2004-04-09 Thread Arnold G. Reinhold
At 8:24 AM -0400 4/8/04, Perry E. Metzger wrote:
Trei, Peter [EMAIL PROTECTED] writes:
 I think Perry has hit it on the head, with the one exception that
 the voter should never have the receipt in his hand - that opens
 the way for serial voting fraud.
 The receipt should be exposed to the voter behind glass, and
 when he/she presses the 'accept' button, it visibly drops into
 the sealed, opaque ballot box.
Seems fine by me, except I'd make the ballot box only lightly frosted
-- enough that you can't read the contents, but light enough that poll
inspectors can visually assure themselves that the contents aren't
mysteriously altered during the course of the day.
I can see one potential problem with having the machine produce the 
receipts. Let's say the system is well designed and completely fair. 
There will be a certain percentage of voters who will complain that 
the receipt recorded the wrong vote because they in fact 
inadvertently pressed the wrong button.  Over time, that percentage 
and its variance will become well known.  Call that rate r.' A party 
with the ability to make surreptitious changes to the voting software 
can then have it occasionally record a vote and print a receipt 
contrary to what the voter chose as long as the number of such bogus 
votes is small enough relative r and its variance to escape notice. 
They can then determine what fraction, f, of voters who get wrong 
receipts  report them. They can then increase the fraction of bogus 
votes by 1/f.  Over the course of several elections they can slowly 
grow the fraction of bogus votes, claiming that voters are getting 
sloppy. Since major elections are often decided by less than one 
percent of the vote, this attack can be significant.

We have a system now in Cambridge, Massachusetts where we are given a 
paper mark sense ballot and fill in little ovals, like those on 
standardized tests. We then carry our ballot to a machine that sucks 
it in and reads it. The totals are reported after the polls close, 
but the mark sense ballots are saved inside the machine (which I 
assume is inspected before the voting starts and then locked) can 
easily be recounted at any time. This system seems ideal to me.

By the way, I should mention that an important part of such a system
is the principle that representatives from the candidates on each side
get to oversee the entire process, assuring that the ballot boxes
start empty and stay untampered with all day, and that no one tampers
with the ballots as they're read. The inspectors also serve to assure
that the clerks are properly checking who can and can't vote, and can
do things like hand-recording the final counts from the readers,
providing a check against the totals reported centrally.
The adversarial method does wonders for assuring that tampering is
difficult at all stages of a voting system.
A important thing to remember is that these poll watchers, along with 
the workers running the voting for the election authorities are often 
retired people who have very little computer skills. It is much 
easier for them to understand and safeguard systems based on paper 
and mechanical locks.

Arnold Reinhold

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

Re: [Mac_crypto] Apple should use SHA! (or stronger) to authenticate software releases

2004-04-05 Thread Arnold G. Reinhold
Dobbertin's 1996 collision demonstration is another good reason not 
to use md5, but is obviously hasn't gotten the open source community 
or Apple to stop.  Whether my attack will be any more successful in 
effecting change remains to be seen. Publishing SHA1 hashes in 
parallel with md5 seems like such an inexpensive thing to do, but one 
should never underestimate cryptographic inertia. For the record, I 
first published my attack on Perry Metzger's cryptography list in 
February, 2002.

Arnold Reinhold

At 5:56 PM -0400 4/4/04, Don Davis wrote:
hi, mr. reinhold --

there's stronger reason than the ones you cite,
to distrust md5 as a message-digest.  see these
old sci.crypt threads, and the google-search below,
for discussions of hans dobbertin's 1996 crack
of md5:

btw, in a phone conversation, dobbertin emphasized
to me that his attack only works when md5 is used
as a message-digest; it doesn't work when md5 is
used with a key to prepare a MAC.  he also mentioned
that while sha-1 may be vulnerable to an attack of
a similar style (because sha-1 is similar in struc-
ture to md5), he himself was forbiddden by german
law to work to cryptanalyze sha-1, because he worked
at that time for the german federal security service,
and so wasn't allowed to attack the USG's standard
ciphers.  now he's at ruhr university (in bochum),
but i don't know whether he's more of a free agent.
- don davis, boston

 From: Arnold G. Reinhold [EMAIL PROTECTED]
 Subject: [Mac_crypto] Apple should use SHA! (or stronger) to authenticate
 List-Id: Macintosh Cryptography
 Date: Sun, 4 Apr 2004 06:17:55 -0500
 The cryptographic hash function MD5 has long been used to
 authenticate software packages, particularly in the Linux/Unix/open
 source community. This has carried over to Apple's OS-X. The MD5 hash
 of an entire package is calculated and its value is transmitted
 separately from the package. Users who download the package compute
 the hash of the copy they received and match that value against the

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

Re: [Mac_crypto] Apple should use SHA! (or stronger) to authenticate software releases

2004-04-05 Thread Arnold G. Reinhold
At 4:51 PM +0100 4/5/04, Nicko van Someren wrote:
While I agree that it is somewhat lax of Apple to be using MD5 for 
checking its updates it's far from clear to me that an attack of the 
sort described above would ever be practical.  The problem is that 
the while there are methods for finding has collisions by brute 
force, not only do they require a work factor around the size of the 
square root of the output space, and a large amount of storage, but 
the work factor is multiplied by a factor linear in the size of the 
data that follows the part of the message that you can manipulate. 
When all you are doing is trying to find a single collision on the 
hash function (or perhaps trying to forge a matching pair of small 
key exchange messages) this can be made quite small but when it 
comes to breaking a package distribution system it is much harder.

Consider that the real package is represented by M, the subtly 
modified version is M1 and the bogus package is represented by M2. 
Each of these has some high resolution TIFF image T that we can get 
away with tweaking into T1 and T2.  We probably don't have control 
where this image comes out in the package because the file ordering 
is deterministic.
The file ordering may be deterministic, but someone who is well 
versed in the configuration control and release engineering process 
might well be able to have a chosen file placed at the end of of the 
package. The method for getting stuff at the end needn't be perfect. 
The attacker can keep trying until he succeeds.

The package can be broken down into three parts: the bit before the 
tweakable part, the tweakable image and the bit after that:
	M  = M1a | T  | M1b
	M1 = M1a | T1 | M1b
	M2 = M2a | T2 | M2b
For the purposes of finding a collision we can pre-compute the hash 
blocks of M1a and M2a but we can't do the same for M1b and M2b. 
This means if L(x) is the function for the number of hash blocks in 
message x then the cost of finding a hash collision in our packages 
is L(T1|M1b) + L(T2|M2b) times harder than just finding a simple 
collision by brute force.  In MD5 the blocks are 64 bytes, so for 
every 1K in M1b the process of finding a collision gets 16 times 
harder.  Finding a collision in SHA1 is about 2^16 times harder than 
finding a collision in MD5, so unless you find something that you 
can alter without it being noticed in the last 2MB of the package 
then this sort of forgery is actually going to be harder than 
finding a simple hash collision in SHA1!  In practice you'll 
probably find something that you can alter in the last few hundred 
KB but still the raw processing cost will be a few orders of 
magnitude harder than a simple hash collision problem.  Furthermore, 
since you have to process the tail of the message any specialised 
hardware for doing this will have a hard time doing it's processing 
in a usefully pipelined fashion and will need access to large 
amounts of very fast RAM to store the tail of the message, and this 
will also cost you another order of magnitude or so.
Having a tail 2 MB or longer may make the processing time comparable 
to finding an SHA1 collision, but it is still a 64-bit problem and 
thus requires far less memory than finding an SHA1 collision.

I am not saying that my attack is easy, but that it is feasible for a 
large organization and very dangerous and stealthy if it succeeds. 
History has shown, over and over and over again, the folly of 
ignoring cryptographic attacks that are theoretically possible but 
seem too hard to implement. On the other hand, defending against my 
attack certainly is easy, just publish an SHA1 (or stronger) hash 
alongside the MD5 hash.

Arnold Reinhold

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

Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]

2004-01-09 Thread Arnold G. Reinhold
I did a Google search on irrebuttable presumption and found a lot 
of interesting material. One research report on the State of 
Connecticut web site

says: The Connecticut Supreme Court and the U. S. Supreme Court have 
held that irrebuttable presumptions are unconstitutional when they 
are not necessarily or universally true and the state has reasonable 
alternative means of making the determination.

The comment appears to apply to statutes and regulations (as opposed 
to contracts).  Still the two tests mentioned seem very appropriate 
to a discussion of non-repudiation as used in cryptography. In 
deciding whether the existence of a verified signature should 
automatically lead to some real world action, we should consider both 
the adequacy of the technology and the nature of the application.

So, for example, the military might adopt an irrebuttable presumption 
that a cryptographically signed order comes from the registered owner 
of a cryptographic key, because it has vetted all the technology 
employed, it can't tolerate delay, and  is willing to impose a duty 
on a key holders to protect their key or suffer the consequences.

On the other end of the scale, anti-spam software might accept a 
signature validated by a public key that is included in a user's 
white list as conclusive proof that the message should be transmitted 
to that user because the consequences of doing so with a forged 
message are so minute.

In the case of ordinary consumer transactions, an irrebuttable 
presumption for public key signatures would not seem to pass muster. 
There are too many problems with the technology (its not just a 
question of protecting the private key, but also of insuring the the 
document actually signed is the one the user thought he was signing) 
and there are usually other forms of evidence (e.g. delivery records) 
to substantiate the transaction.

This is apparently a very complex area of law. Another paper
includes these quotes:
Every writer of sufficient intelligence to appreciate the 
difficulties of the subject matter has approached the topic of 
presumptions with a sense of hopelessness and left it with a feeling 
of despair.5  Commenting on the law of presumptions, Judge Learned 
Hand has commented: Judges have mixed it up until nobody can tell 
what on earth it means.6

It sounds like the legal profession long ago recognized the 
difficulties the cryptographic community is now grappling with regard 
to non-repudiation.  We should be very wary of assuming 
mathematical constructs naturally transform into the legal arena.

Arnold Reinhold
(who is not a lawyer)
 5  Edmund M. Morgan, Presumptions, 12 Wash. L. Rev. 255, 255 (1937).
 6  L. Hand, 18 ALI Proceedings 217-18 (1941).
At 5:32 PM -0800 1/5/04, Ed Gerck wrote:

In business, when repudiation of an act is anticipated we're reminded by
Nicholas Bohm (whose clear thinking I know and appreciate for 6 years)
that some lawyers find it useful to define irrebuttable presumptions  -- a
technique known to the law and capable of being instantiated in 
statute or contract.

For example, a legal irrebuttable presumption can take the form of 
a bank check
contract stating that a check (even though it can be *proven* a 
posteriori to be a
forgery) is payable by the bank if the account holder did not notify 
the bank to
repudiate the check *before* the check was presented to the bank for payment.
The requirement can be seen an out-of-band signal from the account holder to
the bank, which absence makes the check's payability an irrebuttable 
by the bank. In this case, as long as the check's signature does not 
look like a
(obvious) forgery and there is enough balance in the account, the bank has no
liability to that customer in paying the check. Note also that the 
effectiveness of
this method relies on an indirect proof -- the absence of a 
previous communication
makes the check payable.

Likewise, in a communication process, when repudiation of an act by a party is
anticipated, some system security designers find it useful to define 
as a service that prevents the effective denial of an act. Thus, 
lawyers should
not squirm when we feel the same need they feel -- to provide for processes
that *can be* conclusive.
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: why penny black etc. are not very useful

2003-12-31 Thread Arnold G. Reinhold
At 11:12 AM + 12/31/03, Ben Laurie wrote:
Perry E. Metzger wrote:
In my opinion, the various hashcash-to-stop-spam style schemes are not
very useful, because spammers now routinely use automation to break
into vast numbers of home computers and use them to send their
spam. They're not paying for CPU time or other resources, so they
won't care if it takes more effort to send. No amount of research into
interesting methods to force people to spend CPU time to send mail
will injure the spammers.
If you set the price to 1 minute of CPU, and spammers own 10% of all 
machines on the 'net, then the average machine can only receive 144 
spams per day. That's a significant improvement on my situation.

Plus I'd've thought that having 100% CPU utilisation all the time 
might attract attention. But maybe not.


There is something else one can do that might help. The hashcash 
stamp algorithm can be designed to provide a strong, constant 
signature to virus detectors. For example, in my HEKS-1 algorithm, I 
populate a large array with pseudo random words. It would be easy 
enough to have some fraction (say 1/8th or 1/16th) of those words be 
a special constant (or one of a few special constants).  There would 
be no way for the spammer to avoid exhibiting the same constants 
while generating stamps without incurring a severe computational 
penalty. So any stamp generation activity would be easy to detect. 
Since the signature would never change, the detection software could 
be built into the operating system (or even the CPU itself).

Legitimate stamp generation would have to be distinguished, perhaps 
by code signing or some Touring test.  A sufficiently clever virus 
writer with root access might be able commandeer the legitimate stamp 
generator. If this happens, periodic required updates of the hashcash 
software can be issued that thwart viruses in the field. Also a large 
number of countermeasure variants can be generated, making it hard 
for the virus to recognize them all. This reverses the tactical 
advantage normally enjoyed by virus writers. Illegitimate stamp 
generators are forced to present a fixed target while legitimate 
programs and counter measures can continuously morpf.

Arnold Reinhold

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

RE: Protection against offline dictionary attack on static files

2003-11-16 Thread Arnold G. Reinhold
Jill's approach to key stretching is not quite the same as the 
traditional iterated hash.  It imposes no cost at encryption time, 
you only have to work at decryption. This might be valuable when you 
want to save your files as the Gestapo is breaking down your door.

I've been working on a similar method for use as an anti-censorship 
tool. Files would be encrypted with a random key and posted on the 
Internet. The key size would be selected to require a long time to 
crack: hours, days or even weeks. People in countries behind national 
Internet filtering could download these files and crack them, 
possibly telling friends the recovered key. Censors would have to 
expend a lot of effort trying to learn the files that contained 
forbidden ideas. It would be inexpensive to create many different 
encryptions of the same file and mirror them in multiple locations or 
to flood them on Usenet. The URLs of good stuff could be spread by 
word of mouth.

Arnold Reinhold

At 2:26 PM -0500 11/12/03, Steve Wang wrote:
Check PKCS #5:


-Original Message-
[mailto:[EMAIL PROTECTED] On Behalf Of Arcane Jill
Sent: Thursday, October 23, 2003 3:21 AM
Subject: Protection against offline dictionary attack on static files

It's possible I may be reinventing the wheel here, so my apologies if
that's so, but it occurs to me that there's a defence against an offline
dictionary attack on an encrypted file. Here's what I mean: Say you have

a file, and you want to keep it secret. What do you do? Obviously you
either encrypt it directly, or you store it in an encrytped volume
(thereby encrypting it indirectly). Problem? Maybe an attacker can
somehow get hold of the encrypted file or volume ... maybe your laptop
gets stolen  maybe other people have access to your machine. In
principle, you're protected by your passphrase, but if an attacker can
get hold of the file, they can try an offline dictionary attack to guess
your passphrase, so unless you're very good at inventing high entropy
passphrases /and remembering them without writing them down/, there may
still be a risk.
Here's the defence:

To encrypt a file:
Generate a random number R between 0 and M-1 (for some fixed M, a
power of 256)
Type in your passphrase P
Let S = R || P (where || stands for concatenation)
Let K = hash(S)
K is now your encryption key. R is to be thrown away.
To decrypt the same file:
Generate a random number r between 0 and M-1
Type in your passphrase P
for (int i=r; ; i=(i+1)%M)
Let S = I || P
Let K = hash(S)
Try to decrypt using key K
This places a computational burden on your PC at decrypt-time. The
larger you choose M, the more CPU time it will take to figure out K. So,
you choose M such that it takes your PC about one second to find K, then

your attacker will experience the same burden - but multiplied a
squillionfold (a squillion being the entropy of your passphrase). This
means that even if your passphrase consists of just two words from a
dictionary, /and/ your attacker suspects this, it will still take him or
her over a hundred and fifty years to decrypt (assuming your attacker
has a PC of equivalent power). Even if your attacker has a faster PC
than you, it will still be relatively easy to pick a
strong-yet-memorable passphrase, since better tech can only ease the
attacker's problem, not remove it. All of a sudden, weak passphrases
turn into strong ones, and strong passphrases turn into computationally
infeasible ones.
Is this useful?
Has anyone come up with it before? (Someone must have ... but I don't
recall seeing the technique used in applications)

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

Re: quantum hype

2003-09-21 Thread Arnold G. Reinhold
At 6:38 PM -0400 9/18/03, John S. Denker wrote:
Yes, Mallory can DoS the setup by reading (and thereby
trashing) every bit.  But Mallory can DoS the setup by
chopping out a piece of the cable.  The two are equally
effective and equally detectable.  Chopping is cheaper and
Other key-exchange methods such as DH are comparably
incapable of solving the DoS problem.  So why bring up
the issue?
It seems to me that because key-exchange methods such as DH only 
depend on exchanging bits (as opposed to specifying a physical 
layer), they can rely on a wide variety of techniques to combat DoS. 
If Bob and Alice can safeguard their local connections to the 
Internet, its multi-routing properties provide significant DoS 
protection. Other options available to them include the switched 
telephone network, wireless, LEO satellites, cybercafes, 
steganography,  HF radio, and even postal mail. In addition, DH users 
have no need to call attention to themselves by leasing a fiber-optic 

Arnold Reinhold

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

Re: PGP Encryption Proves Powerful

2003-05-31 Thread Arnold G. Reinhold
At 1:22 PM -0400 5/29/03, Ian Grigg wrote:
The following appears to be a bone fide case of a
threat model in action against the PGP program.
Leaving aside commentary on the pros and cons
within this example, there is a desparate lack of
real experience in how crypto systems are attacked.
IMHO, this leads to some rather poorly chosen
engineering decisions that have shown themselves
to stymie or halt the success of otherwise good
crypto systems.
Does anyone know of a repository for real life
attacks on crypto systems?  Or are we stuck with
theoretical and academic threats when building
new systems?
There is a lot of material from the World War II era (e.g Silk and 
Cyanide by Leo Marks) and the early cold war (e.g.

Government cryptographic successes are usually highly classified and 
kept that way for decades. There was one recent story about the FBI's 
apparent use of a keyboard logger to get a accused organized 
criminal's password. The latest U.S. Government wiretap report (they are now 
required to report on encryption incidents) says: Encryption was 
reported to have been encountered in 16 wiretaps terminated in 2002 
and in 18 wiretaps terminated in calendar year 2001 or earlier but 
reported for the first time in 2002; however in none of these case 
was encryption reported to have prevented law enforcement officials 
from obtaining the plain text of the communications intercepted. By 
comparison they reported 1358 intercepts authorized in 2002.

Arnold Reinhold

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