Re: DOS attack on WPA 802.11?

[Niels Ferguson]

At 00:55 14/11/02 -0800, Bill Stewart wrote:
>At 12:03 PM 11/11/2002 -0500, Arnold G. Reinhold wrote:
>>One of the tenets of cryptography is that new security systems
>>deserve to be beaten on mercilessly without deference to their creator.
>
>In particular, I'd be interested in finding out if the new stuff
>has been beaten up by Ian, Nikita, and the other people who
>did the earlier shreddings of the WEP system -
>while it certainly needs broader attention than that,
>it at least needs to get by some of the usual suspects
>rather than just approval by the same sort of standards people
>who let the first one out the door.
>
>That doesn't mean that it's a solid guarantee,
>but all this talk of 20-bit MIC codes doesn't strike me as something
>that could pass the "Ian's Lunch Break" test, much less the
>kind of attention that AES got.

I would contend that I am not "the same sort of standards people that let
WEP out the door". Have a look at my website and list of publications
(http://niels.ferguson.net/). I've been designing cryptographic systems
since 1990. 

That doesn't mean that I don't make mistakes. I make many of them. Michael
is very much an on-the-edge design, due to the harsh requirements. It is
quite possible that someone will find a better attack against Michael, but
unless I really goofed it will take Ian more than a single lunch break. 

Cheers!

Niels


==
Niels Ferguson, [EMAIL PROTECTED], phone: +31 20 463 0977
PGP: 3EC2 3304 9B6E 27D9  72E7 E545 C1E0 5D7E

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

The National Strategy to Secure Cyberspace

[John F. McMullen]

>From Joe King
-- Forwarded message --
The draft of The National Strategy to Secure Cyberspace has been posted
for comment by the public at:
http://www.whitehouse.gov/pcipb/cyberstrategy-draft.html
In view of some of the views espoused by members of the Administration,
it is most important that we all read and comment on this initiative.
And while reading it, keep in mind the Law of Unintended Consequences
which Washington often fails to consider. The public comment period ends
on Monday.


Joe King, Producer/Host
The Personal Computer Show / WBAI-FM New York
3 Times winner Nat'l Computer Press Awards
18 Years of Service to the Tri-State region.
www.pcradioshow.org
---


  "When you come to the fork in the road, take it" - L.P. Berra
  "Always make new mistakes" -- Esther Dyson
  "Be precise in the use of words and expect precision from others" -
   Pierre Abelard
  "Any sufficiently advanced technology is indistinguishable from magic"
   -- Arthur C. Clarke
 John F. McMullen
  [EMAIL PROTECTED] ICQ: 4368412 Fax: (603) 288-8440 [EMAIL PROTECTED]
 http://www.westnet.com/~observer



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

Re: DOS attack on WPA 802.11?

[Arnold G Reinhold]

I agree that we have covered most of the issues. One area whre you have
not responded is the use of WPa in 802.11a. I see no justification for
intoducing a crippled authentication there.

Also here is one more idea for possibly improving Michael.

Scramble the output of Michael in a way that depends on the MIC key, K.
This could be as simple as rotating each output word a number of bits
derived from K. Or you could generate a 8 by 8 permutation from K and
apply it to the bytes in the Michael output. you might even be able to use the
small cipher that is used to generate the individual packed encryption
keys in WPA.

This would break up an attack that depends on messing with the bits of the
MIC in the message. It does nothing for attacks on parts of the message
body. Any additional integrety check on the message would catch that,
however.

On  the other hand it is very cheap and might interfere with future more
sophisticated attacks.


Arnold Reinhold



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

Encryption Technique Said to be Unbreakable

[Nancy Noell Burk]

From Edupage , 
November 15, 2002:

ENCRYPTION TECHNIQUE SAID TO BE UNBREAKABLE

Researchers at Northwestern University have developed a new form of
quantum cryptography that sends encrypted data at speeds of 250
megabits per second and is, according to the reasearchers, unbreakable.
Whereas other methods of quantum cryptography work by sending
individual photons, the new technique sends large bundles of photons.
According to Paul Kwiat, a professor of physics at the University of
Illinois at Urbana-Champaign and a leading authority on quantum
cryptography, the technique is extremely secure because "an
eavesdropper can't tap into it without disturbing the photons." If the
photons are disturbed, he said, they're gone. Quantum technologies
remain a long way from commercial use, but some observers say
cryptography could be the first of the quantum technologies to enter
real-world applications.

ZDNet, 15 November 2002
http://zdnet.com.com/2100-1104-965957.html



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

Re: Public Key Addressing?

[Bill Stewart]

Abstract: Maybe he's saying that phone calls could be implemented
like remailers or onion routers, or at least like ipsec tunnels,
where the contents of the call are kept separate from the
signalling information, so the ISPs only see what they need to.

At 01:05 PM 11/13/2002 +0100, Hadmut Danisch wrote:

  "When doing a phone call, phone numbers must be
  transmitted, and signals about the state of the
  connection as well."
Now a german professor of computer science, who
claims to be a cryptographer, denied this in
a way which I translate to english like this:
  "This is a wrong statement about the technical details.
  It is wrong to claim, that, when doing phone
  calls, phone numbers must be transmitted. The author
  seems to take only the currently practiced ISDN protocols
  into consideration and ignored that, e.g. in particular
  for Packet Switched Networking with Public Key Addressing,
  as researched by Donald Davies as the original fundament
  for the introduction of Packet Switched Networks, especially
  this problem was to be bypassed/avoided."

...

Does anybody have any idea, even an absurd one, what could
the professor have driven to this conclusion and what he
could have meant with Public Key Addressing?


I can think of a couple of things, some of which I even understand :-)

Please excuse the brief explanation of telephony terms first:
There have been several popular approaches to telephone signalling
over the years, which have different security levels against
eavesdropping and manipulation by different users
- Step-by-step transmits the signalling along with the call,
and each piece of equipment uses a digit to route the
audio channel for the call to the next piece of equipment,
but ignores everything else except call tear-down signals.
(Nobody does this any more)  Phone Phreaks liked this.
Eavesdroppers can listen to future signalling and audio.
- Stored-program-control in-band signalling sends the call setup
information in the same channel as the call (either as
audio tones or electrical dial pulses, or "robbed bits" in the US),
but the first switch receives all the digits,
makes some decision about where to send the call,
and if the next step is a stored-program switch,
sends the (possibly translated) signalling information
to the next switch, followed by the audio call.
(If the next step is a phone, it sends ring tones,
and if the next step is step-by-step, it sends
individual step signals at a standard speed.)
Phone Phreaks liked this also!
- Common-channel signalling sends call-setup instructions along
a data network, which tells the control interfaces of
voice switches to connect an audio channel.
This obviously requires stored-program-control switches.
Phone phreaks didn't like this unless they were really expert.
Signalling System 7 (SS7), CCIS, and CCS were versions of this.
Most modern telephone company switches work this way.
- ISDN has signalling protocols that use data carried along with a
group of audio-or-user-data channels.  (1 or 2 data + 2, 23 or 30 
voice.)
In telephone company networks, ISDN is commonly used as an
interface from the user to the telephone company,
which uses common-channel signalling to complete the call
to its destgination (or at least to the last intelligent
common-channel signalling switch in the path,
then either ISDN or in-band audio or step-by-step,
depending on how obsolete the phone switches at the destination are.)
In customer-owned networks, such as business PBXs,
the trunks between switches might also be ISDN,
which would carry the signalling in the data channels
in the same group as the voice channels.

Another digression - in US wiretapping law, a "pen register" is
a device that detects the signalling information on a customer's
telephone line, and records the signalling but not the audio.
(Originally, this used moving pens and paper to show the electrical
impulses from pulse dials.)  Unfortunately, US courts decided that
pen registers don't record private information, because the user
is telling the telephone company who they want to talk to,
which is therefore "public" information, so it should not receive
the same legal protection as wiretaps that actually listen to the
speech part of a telephone call.  Another unfortunate consequence
is that every time somebody develops a new technology for
eavesdropping or wiretapping, the police try to claim that it is
like a pen register, not a real wiretap, and every time somebody
develops a new communication medium, the police try to claim that
it's not like a private telephone call that has some legal protection,
or a person-to-person conversation or personal papers that have
more legal protection, but instead is only like

Secure Electronic and Internet Voting

[Ed Gerck]

List:

I want to spread the word about a newly published book
by Kluwer, where I have a chapter explaining Safevote's
technology and why we can do in voting (a much harder
problem) what e-commerce has not yet accomplished (it's
left as an exercise for the reader to figure out why 
e-commerce has not yet done it; hints by email if you 
wish). This book serves as a good introduction to other 
systems and some nay-sayers.  The book's URL is
http://www.wkap.nl/prod/b/1-4020-7301-1

With the US poised to test Internet voting in 2004/6, 
this book may provide useful, timely points for the 
discussion. We can't audit electrons but we can certainly
audit their pattern.

Cheers,
Ed Gerck

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

Re: DOS attack on WPA 802.11?

[Niels Ferguson]

At 18:15 15/11/02 -0500, Arnold G Reinhold wrote:
>I agree that we have covered most of the issues. One area whre you have
>not responded is the use of WPa in 802.11a. I see no justification for
>intoducing a crippled authentication there.

>From the point of the standard there is little difference between 802.11,
802.11a, and 802.11b. The differences are purely in the PHY layer. That is,
the exact radio modulations are different, but the whole MAC layer is
identical. It would break modularisation to link a MAC layer feature to a
PHY layer feature.

The other reason is that 802.11a hardware is already being shipped, and the
AES-based cryptographic protocol has not been finalised. 


>Also here is one more idea for possibly improving Michael.
>
>Scramble the output of Michael in a way that depends on the MIC key, K.
>This could be as simple as rotating each output word a number of bits
>derived from K. Or you could generate a 8 by 8 permutation from K and
>apply it to the bytes in the Michael output. you might even be able to use
the
>small cipher that is used to generate the individual packed encryption
>keys in WPA.
>
>This would break up an attack that depends on messing with the bits of the
>MIC in the message. It does nothing for attacks on parts of the message
>body. Any additional integrety check on the message would catch that,
>however.

This would provide at most a very marginal security improvement. A
differential attack can leave the final MIC value unchanged, and adding an
extra encryption would not help. See the Michael security analysis for
details.

Rotating the output in a key-dependent way is dangerous. You expose the
rotation constants to discovery using a differential attack.

Additional integrety checks would require extra cycles, which we could also
have spent on a more secure Michael version.



Cheers!

Niels
==
Niels Ferguson, [EMAIL PROTECTED], phone: +31 20 463 0977
PGP: 3EC2 3304 9B6E 27D9  72E7 E545 C1E0 5D7E

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

[Bruce Schneier] CRYPTO-GRAM, November 15, 2002

[Perry E. Metzger]

--- Begin Message ---
  CRYPTO-GRAM

   November 15, 2002

   by Bruce Schneier
Founder and CTO
   Counterpane Internet Security, Inc.
[EMAIL PROTECTED]
  


A free monthly newsletter providing summaries, analyses, insights, and 
commentaries on computer security and cryptography.

Back issues are available at 
.  To subscribe, visit 
 or send a blank message 
to [EMAIL PROTECTED]

Copyright (c) 2002 by Counterpane Internet Security, Inc.


** *** * *** *** *

In this issue:
  New Book
  Crypto-Gram Reprints
  News
  Counterpane News
  Security Notes from All Over: Japanese Honeybees
  The Doghouse
  Comments from Readers


** *** * *** *** *

   New Book



This is a short issue of Crypto-Gram, because I'm finishing up a new book.

We are being told that we are in graver danger than ever, and that we 
must change our lives in drastic and inconvenient ways in order to be 
secure.  We are being told that we must give up privacy or anonymity, 
or accept restrictions on our actions.  We are being told that the 
police need new investigative powers, that domestic spying capabilities 
need to be instituted, and that our militaries must be brought to bear 
on countries that support terrorism.  What we're being told is mostly 
untrue.  Most of the changes we're being asked to endure don't result 
in good security.  They don't make us safer.  Some of the changes 
actually make things worse.

My new book, still untitled, is a book about security.  Not computer 
security, but security in general.  Its goal is to teach readers how to 
think differently, how to tell good security from bad security, and to 
be able to explain why.  Its goal is to instill in readers a healthy 
skepticism about security, especially the technologies surrounding 
security.  Its goal is to convince readers that good security is about 
people.

The book walks the reader, step by step, through security: what works, 
what doesn't, and why.  It gives general principles that the reader can 
use to understand and evaluate security.  It illustrates those 
principles with anecdotes from all over: crime, war, history, sports, 
natural science, myth, literature, and movies.  And it gives the reader 
a simple process that he can use to understand the difference between 
good security and bad security.

Real-world security looks a whole lot like computer security.  It's not 
just that computers are everywhere; the same concepts and methodologies 
that allow us to make sense of computer security also apply to the real 
world.  In my previous book, "Secrets and Lies," I used real-world 
metaphors to explain computer and network security.  In this book I am 
going to explain real-world security using the techniques, processes, 
and formalism from the computer world, without assuming any computer 
knowledge.

Book publishing is second only to furniture delivery in slowness.  My 
deadline for the book is the end of the month, but it's not going to be 
available in stores until next September.


** *** * *** *** *

 Crypto-Gram Reprints



Crypto-Gram is currently in its fifth year of publication.  Back issues 
cover a variety of security-related topics, and can all be found on 
.  These are a selection 
of articles that appeared in this calendar month in other years.

Full Disclosure:


Why Digital Signatures are Not Signatures


Programming Satan's Computer:  Why Computers Are Insecure


Elliptic Curve Public-Key Cryptography


The Future of Fraud:  Three reasons why electronic commerce is different


Software Copy Protection: Why copy protection does not work




** *** * *** *** *

  News



Red Hat vs. the DMCA.  Red Hat publishes information about a security 
patch ONLY to people outside the United States, because of fear of the 
DMCA.  It seems that a description of a fix to a vulnerability also 
contains information about the vulnerability itself, which could be a 
violation of the DMCA.  Ridiculous?  Of course it is.  But that's the 
law for you.


And while we're on the subject of ridiculous, here are some of the 
"digital media devices" that would be required to incorporate 
government-approved copy-protect

Security holes... Who cares?

[Eric Rescorla]

I thought this paper might be of interest to the cryptography folks.

  Security holes... Who cares?

  Eric Rescorla
  RTFM, Inc.   

We report on an observational study of user response following the
OpenSSL remote buffer overflows of July 2002 and the worm that exploited
it in September 2002.  Immediately after the publication of the bug and
its subsequent fix we identified a set of vulnerable servers. In the
weeks that followed we regularly probed each server to determine whether
it had applied one of the relevant fixes. We report two primary
results. First, we find that administrators are generally very slow to
apply the fixes. Two weeks after the bug announcement, more than two
thirds of servers were still vulnerable. Second, we identify several
weak predictors of user response and find that the pattern differs in
the period following the release of the bug and that following the
release of the worm.

The paper can be downloaded from:
http://www.rtfm.com/upgrade.pdf
http://www.rtfm.com/upgrade.ps

-Ekr

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

Information Awareness Office

[Hadmut Danisch]

Hi,

a lovely anthology of concepts about human and
civil rights (american flavour) can be found at

http://www.darpa.mil/iao/

best regards
Hadmut


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

Why we spent a decade+ building strong crypto & security

[John Gilmore]

The US government's moves to impose totalitarian control in the last
year (secret trials, enemies lists, massive domestic surveillance) are
what some of the more paranoid among us have been expecting for years.
I was particularly amused by last week's comments from the
Administration that it'll be too hard to retrain the moral FBI agents
who are so careful of our civil rights -- so we'll need a new
domestic-spying agency that will have no compunctions about violating
our civil rights and wasting our money by spying on innocent people.

While there's plenty of fodder for argument among the details, the
overall thrust of the effort seems pretty clear.

Now's a great time to deploy good working encryption, everywhere you
can.  Next month or next year may be too late.  And even honest ISPs,
banks, airlines (hah), etc, may be forced by law or by secret pressure
to act as government spies.  Make your security work end-to-end.

Got STARTTLS?
Got IPSEC?
Got SSH?

Use it or lose it.

John Gilmore


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

"'Noisy light' is new key to encryption" Pfft.

[Steven Soroka]

re article:
http://news.zdnet.co.uk/story/0,,t269-s2126017,00.html

Correct me if I'm wrong, but isn't this extremely bad? Don't they realize
the system fails if they send more than one photon? the redundancy allows an
attacker with sensitive equipment to read a single photon (or maybe a few)
without the receiving end noticing! (Due to their fancy less-sensitive,
error correcting receiver) This renders the whole system completely useless
for cryptographic purposes.

Hope they didn't spend too much money developing it.



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

Digital ID papers

[R. A. Hettinga]

--- begin forwarded text


Status: RO
To: Bob Hettinga <[EMAIL PROTECTED]>
From: "David G.W. Birch" <[EMAIL PROTECTED]>
Date: Mon, 18 Nov 2002 14:36:19 +
Subject: Digital ID papers

Hi Bob,

Can you post this in all the usual places thanks!

The presentations from the 3rd Annual Consult Hyperion Digital Identity
Forum are now available for downloading from the Forum web site at
www.digitalidforum.com, including presentations from Microsoft, Liberty
Alliance, the UK Office of the e-Envoy, Royal Bank of Scotland and others.

The Forum was very successful: some of the delegate comments received were

* "You get the finest audiences for these events - it was a *real* forum,
and there were powerful cylinders firing throughout the room."

* "I found the event both interesting and stimulating. The quality of papers
was very good, and quite a lot of open discussion was allowed"

* "Just to say thanks again for a very enlightening event - I hope other
delegates got as much out of it as I did!"

* "I think I made some potentially useful contacts, and the content itself
was fascinating. I thought it was really well run as well - brilliantly
done!"

Regards,
Dave Birch.

-- 
-- David Birch, Director, Consult Hyperion
-- 
-- tel +44 (0)1483 301793, fax +44 (0)1483 561657
-- mail [EMAIL PROTECTED], web http://www.chyp.com
-- 
-- See you at the Benelux Cards conference in Brussels
-- Dec. 4th/5th 2002, see http://www.smi-online.co.uk/benelux.asp

--- end forwarded text


-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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

Re: DOS attack on WPA 802.11?

[Arnold G Reinhold]

[please ignore previous mesage, sent by mistake -- agr]
On Sat, 16 Nov 2002, Niels Ferguson wrote:

> At 18:15 15/11/02 -0500, Arnold G Reinhold wrote:
> >I agree that we have covered most of the issues. One area whre you have
> >not responded is the use of WPa in 802.11a. I see no justification for
> >intoducing a crippled authentication there.
>
> >From the point of the standard there is little difference between 802.11,
> 802.11a, and 802.11b. The differences are purely in the PHY layer. That is,
> the exact radio modulations are different, but the whole MAC layer is
> identical. It would break modularisation to link a MAC layer feature to a
> PHY layer feature.
>
> The other reason is that 802.11a hardware is already being shipped, and the
> AES-based cryptographic protocol has not been finalised.
>

Modularization is a poor excuse for shipping a cryptographically weak
product. Second in this case the PHY layer does affect a MAC layer
feature. 802.11a is much faster than 11b. That makes Michael
even more vulnerable to attack.  If Michael is subject to one forged
packet per year on 11b, it is vulnerable to one every 10 weeks or so in
11a. Third, a stronger variant of WPA designed for 11a could also run on
11b hardware if  there is enough processing power, so modularization is
not broken.

As for shipped hardware, does anyone know that it couldnot run with a
stronger version of Michael? And a few shipped units, is far less
justification than the 10's of millions of 802.11b units out there.

>
> >Also here is one more idea for possibly improving Michael.
> >
> >Scramble the output of Michael in a way that depends on the MIC key, K.
> >This could be as simple as rotating each output word a number of bits
> >derived from K. Or you could generate a 8 by 8 permutation from K and
> >apply it to the bytes in the Michael output. you might even be able to use
> the
> >small cipher that is used to generate the individual packed encryption
> >keys in WPA.
> >
> >This would break up an attack that depends on messing with the bits of the
> >MIC in the message. It does nothing for attacks on parts of the message
> >body. Any additional integrety check on the message would catch that,
> >however.
>
> This would provide at most a very marginal security improvement. A
> differential attack can leave the final MIC value unchanged, and adding an
> extra encryption would not help. See the Michael security analysis for
> details.
>

A marginal improvement on a marginal algorithm can be worthwhile. It does
break up one attack mode at negligable cost. It might prevent other
attacks that have not been envisioned.

> Rotating the output in a key-dependent way is dangerous. You expose the
> rotation constants to discovery using a differential attack.

If the rotation constants are derived from the MIC key using a strong hash
(e.g. SHA1) there is little risk of recovering key bits. Since this only
needs to be done when the MIC key changes, the computation time should be
afordable.

There is a risk that an attacker who is doing an exhaustive key search
could use knowledge of the rotation bits to rule out most trial keys with
just a hash computation. But even if they could completely test all MIC
key candidates with just the hash, that would require 2**63 SHA1 trials to
recover the MIC key on average. That is a reasonable level of security
compaired to WPA, and with 10 rotation bits we are very far from even that
situation.

Another cheap varient would be to derive the rotation constants from the
hash of the last two MIC keys. This eliminates even this minute risk.

 >
> Additional integrety checks would require extra cycles, which we could also
> have spent on a more secure Michael version.
>

I wasn't suggesting they be done by 802.11, but by  higher layers.

With greetings form Las Vegas,

Arnold Reinhold



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

Re: DOS attack on WPA 802.11?

[Niels Ferguson]

At 21:58 18/11/02 -0500, Arnold G Reinhold wrote:
>Modularization is a poor excuse for shipping a cryptographically weak
>product. 

The current alternative would be to ship _no_ 802.11a products. That might
be intellectually preferable, but that's not how the real world works.

>Second in this case the PHY layer does affect a MAC layer
>feature. 802.11a is much faster than 11b. That makes Michael
>even more vulnerable to attack.  If Michael is subject to one forged
>packet per year on 11b, it is vulnerable to one every 10 weeks or so in
>11a. 

Well, no. The time it takes for an attacker to forge a Michael packet
consists mostly of the 1-minute delays of the countermeasures. Using a
faster PHY protocol doesn't speed up the attack, so Michael has the same
strength for 802.11a and 802.11b.

>Third, a stronger variant of WPA designed for 11a could also run on
>11b hardware if  there is enough processing power, so modularization is
>not broken.

But there _isn't_ enough processing power to run a super-Michael. If there
were, I'd have designed Michael to be stronger. 

Maybe you are suggesting is to add yet another cryptographic function; the
current Michael for existing hardware and a super-Michael for newer 802.11a
hardware. Developing super-Michael would cost a couple of month and a lot
of money. I would consider that a waste of effort that should have been
spent on the AES-based security protocols. That is where we are going, and
we need to get there ASAP. It is perfectly possible to design 802.11a
hardware today that will be able to implement the future AES-based security
protocols. That is what software updates are for.


>As for shipped hardware, does anyone know that it couldnot run with a
>stronger version of Michael? And a few shipped units, is far less
>justification than the 10's of millions of 802.11b units out there.

There are millions of 802.11b chips out there. I don't know how many
802.11a chips there are in the field, but certainly a few orders of
magnitude fewer. Creating a significant slow-down for millions of fielded
units is unacceptable. The whole point of WPA is to work well on fielded
units. New hardware should implement the AES-stuff.


[...]
>A marginal improvement on a marginal algorithm can be worthwhile. It does
>break up one attack mode at negligible cost. 

Aah, but the cost isn't negligible. The per-packet overhead is significant
for small packets, and adding more computations for each packet will reduce
the system throughput even further. 

> It might prevent other
>attacks that have not been envisioned.

For a performance-critical design this is a non-argument. We could apply an
FFT, and it may prevent certain attacks, but we won't.

>
>> Rotating the output in a key-dependent way is dangerous. You expose the
>> rotation constants to discovery using a differential attack.
>
>If the rotation constants are derived from the MIC key using a strong hash
>(e.g. SHA1) there is little risk of recovering key bits. Since this only
>needs to be done when the MIC key changes, the computation time should be
>afordable.

But you'd need to implement SHA1 in software. I don't know whether there is
enough code and memory space on each of the fielded chip sets. Do you? And
do we have a cost estimate for implementing SHA1 on all fielded chip sets?
And how does that cost estimate compare to security improvement? Is this
worthwhile? 

Those are standard design questions. I looked at better mixing at the end
of the Michael function and decided against it. It would slow things down
and the attack that changes the last message word and the MIC value had
much the same security bound as the differential attack that does not
change the MIC value. There is no point in strengthening one link of the
chain if there is another weak link as well. Of course, this isn't how I
normally design cryptographic functions, but Michael is a severely
performance-limited design. 

[...]
>Another cheap varient would be to derive the rotation constants from the
>hash of the last two MIC keys. This eliminates even this minute risk.

No, that doesn't work. It would mean that doing a re-key protocol does not
ensure that the keys on both sides agree. It would be easier just to ask
for 128 key bits from the key management system. It has a PRF and should be
able to do it.

>> Additional integrety checks would require extra cycles, which we could also
>> have spent on a more secure Michael version.
>>
>
>I wasn't suggesting they be done by 802.11, but by  higher layers.

If you are suggesting to run IPsec over 802.11, I'm all for it. That is the
configuration that I would suggest. IPsec over 802.11, with the best 802.11
crypto switched on of course. But the higher layers are outside the scope
of our discussion. We are providing 802.11 security and can't count on the
higher layers.

Cheers!

Niels
==
Niels Ferguson, [EMAIL PROTECTED], phone: +31 20 463 0977
PGP: 3EC2 33

Fwd: [fc] list of papers accepted to FC'03

[R. A. Hettinga]

--- begin forwarded text


Status: RO
Date: Thu, 14 Nov 2002 13:14:12 -0800
To: [EMAIL PROTECTED]
From: Fearghas McKay <[EMAIL PROTECTED]>
Subject: Fwd: [fc] list of papers accepted to FC'03
Reply-To: "Usual People List" <[EMAIL PROTECTED]>
Sender: <[EMAIL PROTECTED]>


--- begin forwarded text


From: "Rebecca N. Wright" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: [fc] list of papers accepted to FC'03
Sender: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.12
List-Help: 
List-Post: 
List-Subscribe: ,

List-Id: Financial Cryptography Conference Announcements 
List-Unsubscribe: ,

List-Archive: 
Date: Wed, 13 Nov 2002 12:42:38 -0500 (EST)

Here is the list of papers accepted to Financial Cryptography '03.  In
addition, there will be several invited talks and panels.  A
preliminary program will be available shortly.  For more info, see
www.ifca.ai/fc03.

==
Rebecca Wright phone: +1 201 216-5015
Department of Computer Science fax:   +1 201 216-8249
Stevens Institute of Technology
Castle Point on Hudson e-mail: [EMAIL PROTECTED]
Hoboken, NJ 07030Web: www.cs.stevens-tech.edu/~rwright
==

List of papers accepted to FC'03


A Micro-Payment Scheme Encouraging Collaboration in Multi-Hop Cellular
Networks
Markus Jakobsson and Jean-Pierre Hubaux and Levente Buttyan

Using Trust Management to Support Transferable Hash-Based
Micropayments
Simon N Foley

Fully Private Auctions in a Constant Number of Rounds
Felix Brandt

Verifiable Secret Sharing for General Access Structures, with
Application to Fully Distributed Proxy Signatures
Javier Herranz and Germ·n S·ez

Cryptanalysis of the OTM signature scheme from FC'02
Jacques Stern and Julien P. Stern

Squealing Euros: Privacy Protection in RFID-Enabled Banknotes
Ari Juels and Ravikanth Pappu

Preventing Tracking and ''Man in the Middle'' Attacks on Bluetooth
Devices
Dennis K¸gler

Traversing Hash Chain with Constant Computation
Yaron Sella

Retrofitting Fairness on the Original RSA-Based E-Cash
Shouhuai Xu and Moti Yung

Fault based cryptanalysis of the Advanced Encryption Standard (AES)
Johannes Bl–mer and Jean-Pierre Seifert

How Much Security is Enough to Stop a Thief?
Stuart E. Schechter and Michael D. Smith

Fair Off-Line e-Cash made easier
Matthieu Gaud and Jacques TraorÈ

Asynchronous Optimistic Fair Exchange Based on Revocable Item
Holger Vogt

Secure Generalized Vickrey Auction using Homomorphic Encryption
Koutarou Suzuki and Makoto Yokoo

Non-interactive Zero-Sharing with Applications to Private Distributed
Decision Making
Aggelos Kiayias and Moti Yung

Timed Fair Exchange of Arbitrary Signatures
Juan Garay and Carl Pomerance

On the Economics of Anonymity
Alessandro Acquisti and Roger Dingledine and Paul Syverson
___
fc mailing list
[EMAIL PROTECTED]
http://mail.ifca.ai/mailman/listinfo/fc

--- end forwarded text

--- end forwarded text


-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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

Re: Fwd: [fc] list of papers accepted to FC'03

[IanG]

> List of papers accepted to FC'03
> 

I see pretty much a standard list of crypto papers
here, albeit crypto with a waving of finance salt.

What ever happened to Financial Cryptography?  The
organisers did say they were going to look at wider
accessibility for the coming year, but I see only
these papers that are, from the titles at least,
anything that speaks to non-cryptographers:

> Fully Private Auctions in a Constant Number of Rounds
> Felix Brandt

> Squealing Euros: Privacy Protection in RFID-Enabled Banknotes
> Ari Juels and Ravikanth Pappu

> How Much Security is Enough to Stop a Thief?
> Stuart E. Schechter and Michael D. Smith

> On the Economics of Anonymity
> Alessandro Acquisti and Roger Dingledine and Paul Syverson

Even they're a stretch.  All are specialised, and
none are of interest to the non-deep-techies.

On a related front, how much interest is there in
running EFCE this coming June?

-- 
iang

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

Re: Fwd: [fc] list of papers accepted to FC'03

[James A. Donald]

--


On 15 Nov 2002 at 10:55, IanG wrote:

>
> > List of papers accepted to FC'03 
> > 
>
> I see pretty much a standard list of crypto papers here,
> albeit crypto with a waving of finance salt.

Theory of what could be implemented has run well ahead of what
has in fact been implemented.

This has doubtless reduced enthusiasm for the theory. 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 XmqKAbnJ3zxWonUYjLQTEauIWVuczMy3fiZXjszK
 4BOXbFJHRJ+piLFRffQdmB84zd8OiOgRKr7wytw+r


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

Re: Fun with Rosslyn Chapel, or, What *was* the Templar's Cipher,anyway?

[R. A. Hettinga]

--- begin forwarded text


Status:  U
To: <[EMAIL PROTECTED]>
From: "T. Wolf" <[EMAIL PROTECTED]>
Date: Sun, 17 Nov 2002 00:00:51 +0100
Subject: Re: Fun with Rosslyn Chapel, or, What *was* the Templar's Cipher,
anyway?

Dear RAH,

I just found the old attached message of yours doing a web search.
Coincidentally, I'm currently looking for the very the same thing (i.e. the
ciphers the Templars used for their bearer certificates).

Since your message is two years old already, I'm hoping you found the
solution by now. If you did, PLEASE PLEASE PLEASE tell me!

Thanks,
Thomas

-
Your old message
(http://archives.neohapsis.com/archives/crypto/2000-q2/0315.html)
-
I'm dong an IBUC shirt for EFCE2K, and, given that we're in Edinburgh, and
Rosslyn Chapel, the famous Templar, um, Mecca, is here, and the Templars
ran the original money transfer business, using cryptography no less,
Fearghas and I popped out to Roslin to root around for stuff to stick on
the aforesaid shirt.


Close, but, more or less, no cigar. We saw the faded remains of a Templar
floriated cross on the Earl of St. Clair's supposed crypt-cover (kinda
small, people speculate about all kinds of goodies in there), which might
have been cool, but it was all eroded and I haven't found line art of one
on the web and it's late.


I've gotten a couple kinda-crypto things, of which I'll pick one for the
shirt tomorrow morning before we mail it out to the silkscreener, but what
I'd *really* like to know, if it's not one of the many "secrets" of the
Templars [like the shroud of Turin is DeMolay, or that the Templars were
Masons, or vice versa, or that they had the head of John the Baptist (or
christ, or Joseph, or the original Green Man) or that they *really* had the
Ark of the Covenent, or the Holy Grail, or that DeMolay was the Second
Gunman on the Grassy Knoll :-), or, whatever] is...


Has anyone ever figured out, or "discovered" or whatever, what kind of
cryptosystem the Templars used to encrypt, decrypt, sign/modify the chits
(dare I say bearer certificates? ;-)) they used so that people could go
from preceptory to preceptory, getting cash/food/whatever, all the way to
the holy land (and get the remains of their money back, or a bill :-), when
they returned home?


Cheers,
RAH,
Who, oddly enough, and by the sheerest coincidence (and I swear on a stack
of Illuminati), lives in the Roslindale section of Boston, named for
Roslin, home of Rosslyn Chapel

--- end forwarded text


-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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

Re: AIR TRAVELER ID REQUIREMENT CHALLENGED

[R. A. Hettinga]

--- begin forwarded text


Status: RO
From: Somebody
To: "R. A. Hettinga" <[EMAIL PROTECTED]>
Subject: Re: AIR TRAVELER ID REQUIREMENT CHALLENGED
Date: Sun, 17 Nov 2002 22:40:59 -0500

Bob,

I was browsing some of my old mail when I came across this.  What's the
status of Gilmore's case?

Has there been a secret trial?




- Original Message -
From: "R. A. Hettinga" <[EMAIL PROTECTED]>
To: "Digital Bearer Settlement List" <[EMAIL PROTECTED]>
Sent: Friday, July 19, 2002 2:51 PM
Subject: AIR TRAVELER ID REQUIREMENT CHALLENGED


>
> --- begin forwarded text
>
>
> Status: RO
> Date: Fri, 19 Jul 2002 14:12:25 -0400
> To: [EMAIL PROTECTED]
> From: "Duncan Frissell" <[EMAIL PROTECTED]>(by way of Duncan Frissell
>   <[EMAIL PROTECTED]>)
> Subject: AIR TRAVELER ID REQUIREMENT CHALLENGED
> Sender: [EMAIL PROTECTED]
>
> Gilmore v. Ashcroft -- FAA ID
Challenge
> AIR TRAVELER ID REQUIREMENT CHALLENGED
> Secret rule demanding 'Your Papers Please' claimed unconstitutional
>
> San Francisco - Civil libertarian John Gilmore today challenged as
> unconstitutional a secret federal rule that requires domestic US travelers
> to identify themselves.
>
>
>
>
>
> Smooth move. Attempt to board a flight to DC on July 4th "to petition the
> government for redress of grievances". Even if not successful, it will be
> annoying and will be worthwhile if it manages to crack out copies of the
> secret security directives (like FAA SD 96-05)establishing the system.
>
> Keep in mind that until the end of the first Clinton administration, it
was
> perfectly legal to fly domestically without ID.
>
> --
> Posted by Duncan Frissell to The
> Technoptimist at 7/18/2002 11:12:20 AM
>
> Powered by Blogger Pro
>
> --- end forwarded text
>
>
> --
> -
> R. A. Hettinga 
> The Internet Bearer Underwriting Corporation 
> 44 Farquhar Street, Boston, MA 02131 USA
> "... however it may deserve respect for its usefulness and antiquity,
> [predicting the end of the world] has not been found agreeable to
> experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
>

--- end forwarded text


-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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

Re: AIR TRAVELER ID REQUIREMENT CHALLENGED

[John Gilmore]

> I was browsing some of my old mail when I came across this.  What's the
> status of Gilmore's case?

The regulations I'm challenging purport to require air and train
travelers to show a "government issued ID".  Every traveler has been
subjected to these "requirements", but it turns out that they aren't
really required by any published law or regulation.  And if you refuse
to meet the supposed requirements, you find out that there are
alternative requirements, that they weren't telling you about.

The government has responded, as have the airlines.  Their response is
to ask the court to dismiss the case, as expected.  See the web site

   http://cryptome.org/freetotravel.htm

for copies of their motions.

The Federal one has the most interesting arguments.  In summary, they
argue that I can't challenge the no-fly list or anything other than
the ID demand because, having not shown ID, the no-fly list was not
applied to me; that I can't sue in a District Court anyway because the
Court of Appeals is supposed to have original jurisdiction; that the
government can make any rule it wants which relates to air security,
and penalize the public over violations, without ever telling the
public what the rule is; that being refused passage unless I present
an ID does not infringe my constitutional right to travel anyway; that
being prevented from traveling anoymously does not implicate any First
Amendment interests; that every possible form of airport security is a
fully constitutional 4th-Amendment search; and that since my right
to travel is not being infringed, these searches give me equal
protection just like all members of the public, because any 'rational'
reason for singling out anonymous travelers will suffice.

If everyone shows ID to fly, and they can get away with preventing
anonymous travel, it becomes easy for the government to single out
e.g. members of the Green Party.  (If no ID was required, any
persecuted minority would soon learn to book their tickets under
assumed names.)  The Nixon Administration had its "enemies list", who
it subjected to IRS audits and other harassment.  But even that evil
President didn't prevent his "enemies" from moving around the country
to associate with anyone they liked.  The Bush Administration's list
interferes with freedom of association and with the constitutional
right to travel.

As my experience on July 4th, 2002, in the San Francisco airport
demonstrated, citizens are free to not show ID to fly, if they spend
half an hour arguing with security personnel over what the secret
rules actually say.  But then, catch-22, the citizen can board the
plane only if they'll submit to a physical search like the ones that
Green Party members and other "on the list" people are subjected to.

So, you can identify yourself to them and be harassed for your
political beliefs, unconstitutionally.  Or you can stand up for your
right to travel anonymously, and be searched unconstitutionally.  Or
you can just not travel.  That's why I'm suing Mr. Ashcroft and his
totalitarian buddies.

The government motion to dismiss my case is filed at:

  http://cryptome.org/gilmore-v-usa-fmd.pdf

The index to all the related documents is at:

  http://cryptome.org/freetotravel.htm

> Has there been a secret trial?

No.  We will file a response to this motion by approx Dec 1.  Then
they will file their reply in mid December or so.  Both of those will
go on the web site.  (If anybody wants to OCR the PDFs of the gov't
documents, please go for it and email me the text.)  Then the court
will read all this stuff, and we'll have a hearing, which is
tentatively scheduled for mid-January.

John

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

Re: Why we spent a decade+ building strong crypto & security

[Adam Shostack]

On Sun, Nov 17, 2002 at 11:29:59PM -0800, John Gilmore wrote:
| Now's a great time to deploy good working encryption, everywhere you
| can.  Next month or next year may be too late.  And even honest ISPs,
| banks, airlines (hah), etc, may be forced by law or by secret pressure
| to act as government spies.  Make your security work end-to-end.
| 
| Got STARTTLS?
| Got IPSEC?
| Got SSH?

I've done up a very short web page explaining how to use STARTTLS for
opportunitistic email encryption between servers running postfix.

http://www.homeport.org/~adam/starttls.html

If you have STARTTLS enabled for client authentication, it should take
less than 5 minutes to set it up for server-server. 

Adam


-- 
"It is seldom that liberty of any kind is lost all at once."
   -Hume



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

17 Cypherpunks subscribers on watch list, Project Lookout

[R. A. Hettinga]

--- begin forwarded text


Status: RO
Date: Tue, 19 Nov 2002 14:06:35 -0800
Subject: 17 Cypherpunks subscribers on watch list, Project Lookout
From: Tim May <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]

A company I am involved with has been on the distribution list for the
FBI's Project Lookout watch list, the list being shared with banks,
electronics companies, consulting firms, transportation companies, and
1100 other firms.

Cross-indexing with the CP subscriber list, I find 17 names on both
lists.

We must be vigilant! Civil rights are only for innocents, not guilty
persons.

--Tim May
-- 
Timothy C. May [EMAIL PROTECTED]Corralitos, California
Political: Co-founder Cypherpunks/crypto anarchy/Cyphernomicon
Technical: physics/soft errors/Smalltalk/Squeak/ML/agents/games/Go
Personal: b.1951/UCSB/Intel '74-'86/retired/investor/motorcycles/guns
Recent interests: category theory, toposes, algebraic topology

--- end forwarded text


-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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

Re: 17 Cypherpunks subscribers on watch list, Project Lookout

[R. A. Hettinga]

--- begin forwarded text


Status: RO
Date: Tue, 19 Nov 2002 15:59:42 -0800
Subject: Re: 17 Cypherpunks subscribers on watch list, Project Lookout
From: Tim May <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]

On Tuesday, November 19, 2002, at 02:06  PM, Tim May wrote:

> A company I am involved with has been on the distribution list for the
> FBI's Project Lookout watch list, the list being shared with banks,
> electronics companies, consulting firms, transportation companies, and
> 1100 other firms.
>
> Cross-indexing with the CP subscriber list, I find 17 names on both
> lists.
>
> We must be vigilant! Civil rights are only for innocents, not guilty
> persons.
>
>

Wow, what a response, at least in private! Four of you have so far
contacted me about the Watch List, asking "out of curiousity" if they
are on the list or if the list is available online someplace. (One of
the four got the message from a forwarding by a list member here. I
really wish you, "E.L.," would not forward messages to unrelated lists.)

But I need a fifth name. HomeSec promised my own name would be removed
if I provided the name of _five_ (5) other suspects.

And I need to get off that list by April 1st, which has been designated
Roundup Day.



--Tim May
"To those who scare peace-loving people with phantoms of lost liberty,
my message is this: Your tactics only aid terrorists."  --John
Ashcroft, U.S. Attorney General

--- end forwarded text


-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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

[ANNOUNCE] OpenSSL 0.9.7 beta 4 released

[Richard Levitte - VMS Whacker]

  The fourth beta release of OpenSSL 0.9.7 is now available from the
  OpenSSL FTP site ftp://ftp.openssl.org/source/>.  This beta
  contains numerous fixes (among others, security-related ones) since
  beta 3, which explains the long time that has passed between the
  two.

  This is NOT a final beta.  Beta 5, which is planned to be the final
  one, will be released in two weeks if everything works well.  The
  final release of OpenSSL 0.9.7 is scheduled for Tuesday 2002-12-10.
  To make sure that it will work correctly, please test beta 4
  thoroughly, for example with your favorite piece of software, and
  please report back to us!  Also, please test on as many platforms as
  you have available and you have time for, especially on less common
  platforms.

  If you're interested in helping further, please join the
  [EMAIL PROTECTED] list, where test requests on specific
  development snapshots will be announced.

  Changes between 0.9.7 beta 3 and 0.9.7 beta 4 include:

  o Support for new platforms: Windows CE, Tandem OSS, A/UX, AIX 64-bit
  o Extended support for some platforms: VxWorks
  o Enhanced support for shared libraries.
  o Support for pkg-config.
  o Lots of new manuals.
  o A few new engines added in the demos area.

  The full set of changes between 0.9.6{x} and 0.9.7 beta 4 include:

  o New library section OCSP.
  o Complete rewrite of ASN1 code.
  o CRL checking in verify code and openssl utility.
  o Extension copying in 'ca' utility.
  o Flexible display options in 'ca' utility.
  o Provisional support for international characters with UTF8.
  o Support for external crypto devices ('engine') is no longer
a separate distribution.
  o New elliptic curve library section.
  o New AES (Rijndael) library section.
  o Support for new platforms: Windows CE, Tandem OSS, A/UX, AIX 64-bit
  o Extended support for some platforms: VxWorks
  o Enhanced support for shared libraries.
  o Support for pkg-config.
  o Lots of new manuals.
  o Change DES API to clean up the namespace (some applications link also
against libdes providing similar functions having the same name).
Provide macros for backward compatibility (will be removed in the
future).
  o Unify handling of cryptographic algorithms (software and engine)
to be available via EVP routines for asymmetric and symmetric ciphers.
  o NCONF: new configuration handling routines.
  o Change API to use more 'const' modifiers to improve error checking
and help optimizers.
  o Finally remove references to RSAref.
  o Reworked parts of the BIGNUM code.
  o Support for new engines: Broadcom ubsec, Accelerated Encryption
Processing, IBM 4758.
  o A few new engines added in the demos area.
  o Extended and corrected OID (object identifier) table.
  o PRNG: query at more locations for a random device, automatic query for
EGD style random sources at several locations.
  o SSL/TLS: allow optional cipher choice according to server's preference.
  o SSL/TLS: allow server to explicitly set new session ids.
  o SSL/TLS: support Kerberos cipher suites (RFC2712).
  o SSL/TLS: allow more precise control of renegotiations and sessions.
  o SSL/TLS: add callback to retrieve SSL/TLS messages.
  o SSL/TLS: support AES cipher suites (RFC3268).

  The distribution file name is:

  o openssl-0.9.7-beta4.tar.gz
MD5 checksum: 43cf89b428fbdd7873b5aae2680cd324

  The checksum was calculated using the following commands:

openssl md5 < openssl-0.9.7-beta4.tar.gz

-- 
Richard Levitte [EMAIL PROTECTED]
OpenSSL Project http://www.openssl.org/~levitte/

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