Re: Cryptography Research wants piracy speed bump on HD DVDs

[Taral]

On Wed, Dec 22, 2004 at 10:58:11AM -0600, Matt Crawford wrote:
> 
> On Dec 15, 2004, at 11:54, Taral wrote:
> 
> >What stops someone using 3 players and majority voting on frame data
> >bits?
> 
> As I understand it, they use such a huge number of bits for marking, 
> that any reasonably-sized assembly of players will still coincide on 
> some marked bits.
> (However, I very much doubt whether they can blacklist all the players 
> in the assembly without blacklisting some "innocent" players as well!)

Is there really that much space for marking? Any substantial number of
marked bits will become obvious in the output stream, no?

-- 
Taral <[EMAIL PROTECTED]>
This message is digitally signed. Please PGP encrypt mail to me.
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?


pgpCUKLbedBvo.pgp
Description: PGP signature

solution, Re: The Pointlessness of the MD5 "attacks"

[Ed Gerck]

Ben Laurie wrote:
David Wagner wrote:
To give one contrived example, imagine that the Windows 2010 binary
comes with an image file that is displayed as part of the splash start
screen.  Imagine that the graphic designer is allowed to supply that
image, but the graphic designer has no other authorized access to the
source or binary of Windows.  Now a disgruntled graphic designer might
be able to arrange to find a MD5 collision MD5(img1) = MD5(img2) so that
img1 looks like an entirely reasonable Windows splash screen, but img2
contains some scrawled epithet ("Tired of Windows crashing all the time?
Try Linux!").  Or, even more contrived, imagine that img1.jpg looks
like a completely normal JPG file, but img2.jpg exploits some buffer
overrun in the startup screen's JPG decoder to overwrite the program's
image with some other malicious code.

They do not relate to the known MD5 collisions - these are general 
collisions, which we do not know how to create, not the restricted ones 
we do know how to create.
"we do not know how to create" != "we will not know how to create"
The fear of a possible (likely?) attack as described by Wagner should
be countered by a concrete solution, not by considering it a time bomb
with a hopefully long enough fuse.
I think such a concrete solution exists, still using MD5. Even though
MD5 is not collision-resistant. The solution applies to everything that
Ben says, as well.
If Microsoft chooses a salt value for an MD5-HMAC, which salt value
Microsoft does not disclose to the programmer and the world until the
file is (1) quality-controlled and (2) handled for distribution, the
programmer would NOT be able to find the collision. Security is easily
assured by Microsoft choosing the salt only after (1) QC. Distribution
of any software, or text, can be likewise protected -- just don't let
the attacker control everything.
The problem here is not MD5. The problem is allowing the attacker to
have too much power.
Cheers,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Florian Weimer]

* Victor Duchovni:

>> The Debian folks have recently stumbled upon a problem in this area:
>> Generating the ephemeral DH parameters is expensive, in terms of CPU
>> cycles, but especailly in PRNG entropy.  The PRNG part means that it's
>> not possible to use /dev/random on Linux, at least on servers.  The
>> CPU cycles spent on bignum operations aren't a real problem.
>> 
>> Would you recommend to switch to /dev/urandom (which doesn't block if
>> the entropy estimate for the in-kernel pool reaches 0), and stick to
>> generating new DH parameters for each connection, or is it better to
>> generate them once per day and use it for several connections?
>> 
>
> Actually reasoning along these lines is why Lutz Jaenicke implemented
> PRNGD, it is strongly recommended (at least by me) that mail servers
> use PRNGD or similar.  PRNGD delivers psuedo-random numbers mixing in
> real entropy periodically.
>
> EGD, /dev/random and /dev/urandom don't produce bits fast enough.

Is this the only criticism of /dev/urandom (on Linux, at least)?  Even
on ancient hardware (P54C at 200 MHz), I can suck about 150 kbps out
of /dev/urandom, which is more than enough for our purposes.  (It's
not a web server, after all.)

I'm slightly troubled by claims such as this one:

  

I know that Linux' /dev/random implementation has some problems (I
believe that the entropy estimates for mouse movements are a bit
unrealistic, somewhere around 2.4 kbps), but the claim that generating
session keys from /dev/urandom is a complete no-no is rather
surprising.

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

Re: The Pointlessness of the MD5 "attacks"

[Ben Laurie]

John Kelsey wrote:
From: Ben Laurie <[EMAIL PROTECTED]> Sent: Dec 22, 2004 12:24 PM 
To: David Wagner <[EMAIL PROTECTED]> Cc:
cryptography@metzdowd.com Subject: Re: The Pointlessness of the MD5
"attacks"

...
Assuming you could find a collision s.t. the resulting decryption
looked safe with one version and unsafe with the other (rather than
gibberish), which I find an even bigger stretch than the idea that
you could find a block that looked safe in one version and unsafe
in another, I would have said that the mere fact of using a
pointless decryption to control the action of the code would be
suspect.

Hmm.  So maybe I'm missing something.  Here's my scenario:
a.  Alice decides to use GOST for encryption.  She finds an
implementation in C from Eve, which includes the S-boxes hard-coded
in.  Note that the specific S-boxes used for GOST are potentially
pretty important for their security.
b.  She also finds a review from some well-known cryptanalyst, Bob,
discussing the requirements on the S-boxes, and verifying that the
above implementation uses good S-boxes, which includes the md5 hash
of the C source code.
c.   Alice downloads the C source code, and checks the md5 hash.
Since the hash is correct, she compiles the code, and starts using
her known-secure version of GOST to encrypt sensitive data.
d.   Unknown to her, though, Eve has slipped in a changed version of
the C source code, with the S-boxes changed in a way that makes the
encryption much weaker.
What prevents this attack from working?  Alice counts on a review
done by someone competent and a hash of the source code, but the
weakness of the hash function means that she's vulnerable to an
attack.  The only thing that might keep it from working is if it
happens to be impossible to choose a pair of sets of S-boxes so that
one is weak, the other is strong, and the pair allows an md5
collision.  I don't know whether this is possible or not, but there's
no inherent reason to think it's impossible--just making some of the
4-bit wide S-boxes in GOST non-bijective has pretty big security
implications.  (Though 32 rounds covers a lot of sins in S-box
selection, in terms of practical attacks rather than academic ones.)
There is certainly no inherent reason to think its impossible. What 
prevents this attack _right now_ is that we don't know how to generate a 
collision that satisfies the required properties.

Indeed. Not the point I am making. In a nutshell, yes, it is scary
that Wang found collisions. No, it is not _more_ scary that you can
use those collisions to fool people who aren't looking anyway.
I think you can use them in ways that may fool people who *are*
looking.  All you need is a legitimate reason to have a more-or-less
arbitrarily chosen block of bits in a part of your program, and then
the person reviewing the code says "okay, that's random-looking, but
reasonable enough."
As an alternative example, consider embedding a large prime number in
your code, to be used as the modulus when you're doing
Diffie-Hellman.  Someone reviews the code, and verifies that the
number is prime and has all the other required properties.  Then, you
swap in a different bitstring of equal length, but which is composite
and yields a reasonably easy attack on Diffie-Hellman.  What prevents
this?
Blimey. Finally. An attack I can actually believe in. Excellent.
Indeed, here is such a pair:
D131DD02C5E6EEC4693D9A0698AFF95C2FCAB58712467EAB4004583EB8FB7F8955AD340609F4B30283E488832571415A085125E8F7CDC99FD91DBDF280373C5BD8823E3156348F5BAE6DACD436C919C6DD53E2B487DA03FD02396306D248CDA0E99F33420F577EE8CE54B67080A80D1EC69821BCB6A8839396F9652B6FF72A70001B 
is prime

D131DD02C5E6EEC4693D9A0698AFF95C2FCAB50712467EAB4004583EB8FB7F8955AD340609F4B30283E4888325F1415A085125E8F7CDC99FD91DBD7280373C5BD8823E3156348F5BAE6DACD436C919C6DD53E23487DA03FD02396306D248CDA0E99F33420F577EE8CE54B67080280D1EC69821BCB6A8839396F965AB6FF72A70001B 
is not prime

both have MD5 b4b12dc7ec1b9422f6596d2a863d7900.
Cool.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: The Pointlessness of the MD5 "attacks"

[John Kelsey]

>From: Ben Laurie <[EMAIL PROTECTED]>
>Sent: Dec 22, 2004 12:24 PM
>To: David Wagner <[EMAIL PROTECTED]>
>Cc: cryptography@metzdowd.com
>Subject: Re: The Pointlessness of the MD5 "attacks"

...
>Assuming you could find a collision s.t. the resulting decryption looked 
>safe with one version and unsafe with the other (rather than gibberish), 
>which I find an even bigger stretch than the idea that you could find a 
>block that looked safe in one version and unsafe in another, I would 
>have said that the mere fact of using a pointless decryption to control 
>the action of the code would be suspect.

Hmm.  So maybe I'm missing something.  Here's my scenario:

a.  Alice decides to use GOST for encryption.  She finds an implementation in C 
from Eve, which includes the S-boxes hard-coded in.  Note that the specific 
S-boxes used for GOST are potentially pretty important for their security.  

b.  She also finds a review from some well-known cryptanalyst, Bob, discussing 
the requirements on the S-boxes, and verifying that the above implementation 
uses good S-boxes, which includes the md5 hash of the C source code.

c.   Alice downloads the C source code, and checks the md5 hash.  Since the 
hash is correct, she compiles the code, and starts using her known-secure 
version of GOST to encrypt sensitive data.

d.   Unknown to her, though, Eve has slipped in a changed version of the C 
source code, with the S-boxes changed in a way that makes the encryption much 
weaker.  

What prevents this attack from working?  Alice counts on a review done by 
someone competent and a hash of the source code, but the weakness of the hash 
function means that she's vulnerable to an attack.  The only thing that might 
keep it from working is if it happens to be impossible to choose a pair of sets 
of S-boxes so that one is weak, the other is strong, and the pair allows an md5 
collision.  I don't know whether this is possible or not, but there's no 
inherent reason to think it's impossible--just making some of the 4-bit wide 
S-boxes in GOST non-bijective has pretty big security implications.  (Though 32 
rounds covers a lot of sins in S-box selection, in terms of practical attacks 
rather than academic ones.)

...
>Indeed. Not the point I am making. In a nutshell, yes, it is scary that 
>Wang found collisions. No, it is not _more_ scary that you can use those 
>collisions to fool people who aren't looking anyway.

I think you can use them in ways that may fool people who *are* looking.  All 
you need is a legitimate reason to have a more-or-less arbitrarily chosen block 
of bits in a part of your program, and then the person reviewing the code says 
"okay, that's random-looking, but reasonable enough."  

As an alternative example, consider embedding a large prime number in your 
code, to be used as the modulus when you're doing Diffie-Hellman.  Someone 
reviews the code, and verifies that the number is prime and has all the other 
required properties.  Then, you swap in a different bitstring of equal length, 
but which is composite and yields a reasonably easy attack on Diffie-Hellman.  
What prevents this?

>Ben

--John

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

Re: Cryptography Research wants piracy speed bump on HD DVDs

[John Kelsey]

>From: Ian Grigg <[EMAIL PROTECTED]>
>Sent: Dec 15, 2004 12:08 PM
>To: cryptography@metzdowd.com
>Subject: Re: Cryptography Research wants piracy speed bump on HD DVDs

...
>A blockbuster worth $100m gets cracked ... and
>the crack gets watermarked with the Id of the
>$100 machine that played it.

Think about the effect on P2P systems, if having one extracted movie from your 
player available for sharing meant that your player would stop working for all 
new content  

I'm not saying I think this (or any other technical solution I've seen) will 
work.  I'm saying that it's a pretty reasonable attempt to undermine 
participation in P2P systems.  

>iang

--John

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

Re: Do We Need a National ID Card?

[Matt Crawford]

On Dec 22, 2004, at 8:53, R.A. Hettinga wrote:
Do we need a national ID card?
The comment period on NIST's draft FIPS-201 (written in very hasty  
response to Homeland Security Presidential Directive HSPD-12) ends  
tomorrow.  The draft, as written, enables use of the card by "Smart  
IEDs" and for improved selection of kidnapping victims.

One cabinet department's Associate CIO for Cybersecurity said of this  
project, "Eventually this is going to lead to a national ID card."

Refs:
http://csrc.nist.gov/piv-project/
http://www.fas.org/irp/offdocs/nspd/hspd-12.html
http://csrc.nist.gov/publications/drafts/draft-FIPS_201-110804- 
public1.pdf

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

Re: The Pointlessness of the MD5 "attacks"

[Ben Laurie]

James A. Donald wrote:
--
On 15 Dec 2004 at 8:51, Ben Laurie wrote:
People seem to be having a hard time grasping what I'm trying
to say, so perhaps I should phrase it as a challenge: find me
a scenario where you can use an MD5 collision to mount an
attack in which I could not mount an equally effective attack
without using an MD5 collision.

I could circulate watermarked versions of copyrighted material
without it being apparent that they were watermarked. 
That was the attack I was not disputing :-)
--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: The Pointlessness of the MD5 "attacks"

[Ben Laurie]

David Wagner wrote:
Ben Laurie writes:
Indeed, but what's the point? If you control the binary, just distribute 
the malicious version in the first place.

Where this argument breaks down is that someone might have partial
but not total control over the binary.  This partial control might
not be enough for them to distribute a malicious version straightforwardly,
but just enough to exploit a MD5 collision.  It is hard to be confident
that such an attack scenario is impossible.
To give one contrived example, imagine that the Windows 2010 binary
comes with an image file that is displayed as part of the splash start
screen.  Imagine that the graphic designer is allowed to supply that
image, but the graphic designer has no other authorized access to the
source or binary of Windows.  Now a disgruntled graphic designer might
be able to arrange to find a MD5 collision MD5(img1) = MD5(img2) so that
img1 looks like an entirely reasonable Windows splash screen, but img2
contains some scrawled epithet ("Tired of Windows crashing all the time?
Try Linux!").  Or, even more contrived, imagine that img1.jpg looks
like a completely normal JPG file, but img2.jpg exploits some buffer
overrun in the startup screen's JPG decoder to overwrite the program's
image with some other malicious code.
Sure, these scenarios are contrived and unlikely.  But how do you
know that there is not some other (possibly more complex but less
contrived) scenario that you would consider more troubling?
They do not relate to the known MD5 collisions - these are general 
collisions, which we do not know how to create, not the restricted ones 
we do know how to create.

People seem to be having a hard time grasping what I'm trying to say, so 
perhaps I should phrase it as a challenge: find me a scenario where you 
can use an MD5 collision to mount an attack in which I could not mount 
an equally effective attack without using an MD5 collision.
I've got a better challenge: show me a convincing argument that no such
scenario exists.
I claim I already have.
What I'm trying to get at is that you've got the burden of proof
backwards.  Implicit in your challenge is the idea that we should
keep trusting MD5 until someone finds a convincing argument that it is
insecure in practice.  My argument is that this is much too trusting.
I believe that, given the theoretical results on MD5, we should not have
any trust whatsoever in the security of MD5 as a collision-resistant
hash until someone is able to offer a convincing argument that MD5 is
secure enough in practice despite its known weaknesses.
Absolutely not, I would not argue for a second that we should continue 
to trust MD5, I am merely making a very narrow argument about the nature 
and utility of the newly found collisions.

I could try to answer your challenge.  I might even be able to devise
some solution to your challenge that would satisfy you.  For instance,
maybe the image file attack above qualifies as a solution.
It would if it were possible, but it isn't.
 Or maybe
the S-box table attack in my previous email is good enough.  But I don't
really want to argue about whether I have found a valid answer to your
challenge.  I shouldn't be required to meet that burden -- the burden
of proof should be on whoever wants to believe that MD5 is secure.
Why should the burden be on MD5 defenders?  Not just because I said so.
Part of the reason is that there are just too many complex scenarios
to consider.  Suppose I conceded that I couldn't find a scenario you'd
accept.  What would that prove?  Very little.  Even if I can't think of
a suitable scenario for you off the top of my head, that doesn't mean
that with more thought I wouldn't find one.  Even if I spent a month
trying and still couldn't find one, that doesn't mean that others can't.
I have made, I think, quite clear arguments why this attack is pointless.
My experience is that if it is possible to find a theoretical attack with
one day's work, it is often possible to extend this to a more practical
attack with, say, one week's work.  Bruce Schneier puts this concisely:
"Attacks always get better."  Trusting in MD5's collision-resistance
amounts to assuming that "cryptanalysts of MD5 will get this far, but
no farther", and that seems like a pretty questionable assumption to me.
I am not suggesting we trust MD5. My point is that this attack does not 
cause me to trust it any less than I already did, and nor does it offer 
any more useful exploit of MD5 than we already had.

Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: The Pointlessness of the MD5 "attacks"

[Ben Laurie]

David Wagner wrote:
Ben Laurie writes:
Dan Kaminsky's recent posting seems to have caused some excitement, but 
I really can't see why. In particular, the idea of having two different 
executables with the same checksum has attracted attention.

But the only way I can see to exploit this would be to have code that 
did different things based on the contents of some bitmap. My contention 
is that if the code is open, then it will be obvious that it does 
"something bad" if a bit is tweaked, and so will be suspicious, even if 
the "something bad" is not triggered in the version seen.

So, to exploit this successfully, you need code that cannot or will not 
be inspected. My contention is that any such code is untrusted anyway, 
so being able to change its behaviour on the basis of embedded bitmap 
changes is a parlour trick. You may as well have it ping a website to 
find out whether to misbehave.

I guess I disagree.  Imagine that the code has some block cipher with
some S-boxes hardcoded into it.  The code uses this block cipher to
decrypt an associated ciphertext and outputs (or takes some action based
on) the resulting message.  This is an example of code that could be
used to fool a MD5 checksum.  Moreover, I don't have a great deal of
confidence that even a careful code inspection would cause the code to
be considered suspicious.  Consequently, I don't have great confidence
that such an attack would be detected.
Assuming you could find a collision s.t. the resulting decryption looked 
safe with one version and unsafe with the other (rather than gibberish), 
which I find an even bigger stretch than the idea that you could find a 
block that looked safe in one version and unsafe in another, I would 
have said that the mere fact of using a pointless decryption to control 
the action of the code would be suspect.

I know it is tempting to think that, look, Wang et al only found a pair
of random-looking messages that collide; they didn't claim to find a pair
of meaningful messages that collide; and maybe we can hope that there is
no way to come up with a pair of meaningful-looking colliding messages.
That kind of thinking may tempt you, but it doesn't tempt me. I am not 
discussing what it might be possible to do, I am discussing what it is 
possibile to do.

But I think that kind of hope is unfounded, and acting on hope is
asking for trouble.  I believe the only safe course now is to assume
that MD5's collision resistance is totally broken.
I had assumed that years ago.
If Wang et al can
find meaningless-looking collisions today, it seems all too likely that
someone else may be able to find meaningful-looking collisions tomorrow.
Hoping that the latter will be hard even though the former is known to
be easy seems too optimistic for my tastes.
Indeed. Not the point I am making. In a nutshell, yes, it is scary that 
Wang found collisions. No, it is not _more_ scary that you can use those 
collisions to fool people who aren't looking anyway.

Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL/TLS passive sniffing

[Victor Duchovni]

On Sun, Dec 19, 2004 at 05:24:59PM +0100, Florian Weimer wrote:

> * Victor Duchovni:
> 
> > The third mode is quite common for STARTTLS with SMTP if I am not
> > mistaken. A one day sample of inbound TLS email has the following cipher
> > frequencies:
> >
> > 8221(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
> > 6529(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
> 
> The Debian folks have recently stumbled upon a problem in this area:
> Generating the ephemeral DH parameters is expensive, in terms of CPU
> cycles, but especailly in PRNG entropy.  The PRNG part means that it's
> not possible to use /dev/random on Linux, at least on servers.  The
> CPU cycles spent on bignum operations aren't a real problem.
> 
> Would you recommend to switch to /dev/urandom (which doesn't block if
> the entropy estimate for the in-kernel pool reaches 0), and stick to
> generating new DH parameters for each connection, or is it better to
> generate them once per day and use it for several connections?
> 

Actually reasoning along these lines is why Lutz Jaenicke implemented
PRNGD, it is strongly recommended (at least by me) that mail servers
use PRNGD or similar.  PRNGD delivers psuedo-random numbers mixing in
real entropy periodically.

EGD, /dev/random and /dev/urandom don't produce bits fast enough. Also
Postfix internally seeds the built-in OpenSSL PRNG via the tlsmgr process
and this hands out seeds for smtp servers and clients, so the demand for
real entropy is again reduced.

Clearly a PRNG is a compromise (if the algorithm is found to be weak we
could have problems), but real entropy is just too expensive.

I use PRNGD.

-- 

 /"\ ASCII RIBBON  NOTICE: If received in error,
 \ / CAMPAIGN Victor Duchovni  please destroy and notify
  X AGAINST   IT Security, sender. Sender does not waive
 / \ HTML MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

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

Re: Cryptography Research wants piracy speed bump on HD DVDs

[Matt Crawford]

On Dec 15, 2004, at 11:54, Taral wrote:
What stops someone using 3 players and majority voting on frame data
bits?
As I understand it, they use such a huge number of bits for marking, 
that any reasonably-sized assembly of players will still coincide on 
some marked bits.
(However, I very much doubt whether they can blacklist all the players 
in the assembly without blacklisting some "innocent" players as well!)

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

RE: International meet on cryptology in Chennai

[Anish]

Hi all,
 I thought I should add one more piece of information; it didn't say which
conference it was. It is Indocrypt 2004
(http://www-rocq.inria.fr/codes/indocrypt2004/).
Regards
Anish

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of R.A. Hettinga
Sent: 20 December 2004 18:11
To: cryptography@metzdowd.com; [EMAIL PROTECTED]
Subject: International meet on cryptology in Chennai




Chennai Online News Service - View News

 Dec 20, 2004 Mon
 Dharana
  
International meet on cryptology in Chennai
Search for More News

 Chennai, Dec 19: A three-day international conference on cryptology will
get underway here tomorrow with the aim of providing secure communication
to the business and military sectors.

Over 140 researchers in the field, including some from abroad, would
participate in the conference, Dr M S Vijyaraghavan, executive director,
Society for Electronics Transactions and Security (SETS), told reporters
here today.

Cryptography is the art of providing secure information over insecure
channels. It encodes texts and provides a method of decoding. Cryptanalysis
is the art of breaking into cryptographic information.

The new science - cryptology - was a study of both, he said.

India had not made any headway in cryptology, he said and added that the
conference would help develop this in a big way.

President A P J Abdul Kalam would address the participants through video
conferencing. Dr R Chidambaram, principal scientific adviser, Government of
India, would inaugurate the conference. (Our Correspondent)


  
Published: Sunday, December 19, 2004


-- 
-
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]



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

Re: SSL/TLS passive sniffing

[John Denker]

Florian Weimer wrote:
Would you recommend to switch to /dev/urandom (which doesn't block if
the entropy estimate for the in-kernel pool reaches 0), and stick to
generating new DH parameters for each connection, 
No, I wouldn't.
> or ...
generate them once per day and use it for several connections?
I wouldn't do that, either.

If the problem is a shortage of random bits, get more random bits!
Almost every computer sold on the mass market these days has a sound
system built in. That can be used to generate industrial-strength
randomness at rates more than sufficient for the applications we're
talking about.  (And if you can afford to buy a non-mass-market
machine, you can afford to plug a sound-card into it.)
For a discussion of the principles of how to get arbitrarily close
to 100% entropy density, plus working code, see:
  http://www.av8n.com/turbid/
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Cryptography Research wants piracy speed bump on HD DVDs

[Taral]

On Wed, Dec 15, 2004 at 09:29:46AM -0500, R.A. Hettinga wrote:
> The virtual machine players create movie outputs that are artistically
> identical but each one is altered if some minor way. This alteration is
> just the changing of a few bits of data every few seconds, so every 50
> frames or so. And the CR system works such that if ten separate players are
> used in collusion in a copying process, taking samples of frames from each,
> it will not only identify one of the players, but all of them and they can
> be revoked from all future content.

What stops someone using 3 players and majority voting on frame data
bits?

-- 
Taral <[EMAIL PROTECTED]>
This message is digitally signed. Please PGP encrypt mail to me.
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?


pgpsTiOaa1ZhJ.pgp
Description: PGP signature

Do We Need a National ID Card?

[R.A. Hettinga]

--- begin forwarded text


From: [EMAIL PROTECTED]
Date: Wed, 22 Dec 2004 07:54:11 EST
Subject: Richard Rahn's "Do We Need a National ID Card?" (The Washington Times)
To: undisclosed-recipients: ;

The Washington Times
www.washingtontimes.com

Do we need a national ID card?
By Richard W. Rahn
Published December 22, 2004

Are you in favor of a national identity card? Even though many Americans
are against the idea of a national identity card, it is coming. In fact, in
many ways, it is already here. Every American citizen and every foreign
worker in America is required to have a Social Security card. Your Social
Security card is only supposed to be used to gain employment and receive
Society Security benefits, but try applying for credit without giving your
Social Security number -- and most often you will be turned down.

You cannot board an airliner or certain trains, cash a check, go to a
hospital, obtain a hotel room or even enter some office buildings without
showing a photo ID. You cannot travel to foreign countries without a
passport. Yes, we have no national ID card but, instead, we are required to
have many ID cards just to engage in the normal activities of life.

We are torn on the issue of a national ID because we do not want big
brother government to monitor us (we all know the potential horrors from
the Gestapo and sci-fi movies).

On the other hand, we understand the legitimate needs of many purveyors of
public and private services to know who we are. We also worry about the
theft of our identity. We want to be able to provide our medical history to
those who need it to help us in a medical emergency, but we don't want
those who might abuse or embarrass us with that knowledge to have the
information.

In the current world, we are required to know and give more passwords than
most of us can remember to access our bank and credit card accounts,
frequent flyer accounts, e-mail and Internet providers, and other
information service accounts.

If the question posed at the beginning of this commentary was: "Would you
be in favor of a card that could prove your ID while at the same time
protect you from giving information about yourself (including medical and
financial information) that you do not wish to provide?" I am sure that
more people would give a yes response.

The fact is we do not need nor should we have a government issued national
ID card. What we need is for the government to specify for what purposes
and when it positively must know our identity, and what constitutes
acceptable proof. Private organizations, such as airlines, banks and
merchants already do the same thing. Then the private sector will develop
the most user-privacy-friendly and cost-effective devices. Tiny computer
chips containing all of the necessary biometric information coupled with
nearly unbreakable encryption have already been developed. Consumers will
be able to choose what information they wish to have stored in such
devices, and who is allowed to have access to what. The chips can be placed
in "smart cards," cell phones and PDAs, or even implanted in the body.

In my ideal world, the government would know with certainty who has voted
(but not their vote), who is coming into the country, to whom it is making
payments and from whom it is receiving taxes. I would like to be able to
prove my identity to government agencies, airlines, banks, etc., and have
access to all my password accounts and computers, and deliver such
additional information about myself to those I choose to (such as my
medical history to a hospital in case of an emergency), while protecting
all my information from those with whom I choose not to share it.

In addition, I do not want to have to carry more than one device with me
(such as a card or PDA), nor do I want to have to remember any passwords.

Fortunately, the current technology will indeed allow all of the above (my
thumbprint could give me access to my PDA with all of the passwords, etc.).

The Government Passport Agency is in the process of developing new
passports to prevent counterfeiting and to give more secure ID. In reality,
it is not necessary for us to have passports. What is necessary is for the
government to know whether or not I am a U.S. citizen when I am entering
the country, and whether or not I should be detained because of some
criminal act. If I provide the government with a high quality ID, including
proof of citizenship, they should instantaneously be able to determine if I
am on a wanted list (including my foreign travel history). The idea of
having passports stamped is not only obsolete and useless, but just plain
silly. (Obviously, foreign governments would also have to agree to do away
with the existing passport system, to get the full advantages of the new
private ID systems.)

Again, we do not need a government issued ID. Those who require information
about us (including government agencies) should merely specify what
information they need and what forms are acce

Border Patrol hails new ID system

[R.A. Hettinga]

The Washington Times
 www.washingtontimes.com

Border Patrol hails new ID system
By Jerry Seper
THE WASHINGTON TIMES
Published December 21, 2004
Border Patrol agents assigned to U.S. Customs and Border Protection (CBP)
identified and arrested 23,502 persons with criminal records nationwide
through a new biometric integrated fingerprint system during a three-month
period beginning in September, CBP officials said yesterday.
 Most of those arrested were foreign nationals.
 "This 21st-century biometric identification technology is a critical
law-enforcement tool for our CBP Border Patrol agents," said CBP
Commissioner Robert C. Bonner. "It allows CBP Border Patrol agents to
quickly identify criminals by working faster, smarter and employing
technology to better secure the nation."
 Mr. Bonner has described the new system as "absolutely critical" to
CBP's priority mission of keeping terrorists and terrorist weapons out of
the country, adding that it gives the agents the ability to identify those
with criminal backgrounds "we could never have identified before."
 The program, known as the Integrated Automated Fingerprint
Identification System (IAFIS), is a biometric identification technology
enabling Border Patrol agents to search CBP's Automated Biometric
Identification System (IDENT) and the FBI's criminal fingerprint database
simultaneously, CBP spokesman Mario Villarreal said.
 It allows Border Patrol agents to rapidly identify people with
outstanding warrants and criminal histories by electronically comparing a
live-scanned 10-fingerprint entry against a comprehensive national database
of previously captured fingerprints, he said.
 The IAFIS/IDENT system went on line this year at all 148 Border Patrol
station throughout the country. It began as a pilot project in San Diego,
where it was employed at the Border Patrol's Brown Field, Calif., station,
and at the Calexico, Calif., port of entry.
 During the three-month period this year, the agents identified and
detained 84 homicide suspects, 37 kidnapping suspects, 151 sexual assault
suspects, 212 robbery suspects, 1,238 suspects for assaults of other types,
and 2,630 suspects implicated in dangerous narcotics-related charges.
 CBP is the unified border agency within the Department of Homeland
Security charged with the management, control and protection of the
nation's borders at and between the ports of entry. CBP is charged with
keeping terrorists and terrorist weapons out of the country while enforcing
hundreds of U.S. laws.

-- 
-
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: International meet on cryptology in Chennai

[R.A. Hettinga]

--- begin forwarded text


Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Date: Tue, 21 Dec 2004 00:08:49 -0800 (PST)
From: Sarad AV <[EMAIL PROTECTED]>
Subject: Re: International meet on cryptology in Chennai
To: "R.A. Hettinga" <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]


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



They call it IndoCrypt
http://www-rocq.inria.fr/codes/indocrypt2004/

Sarad.



__
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com


--- 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]

Digipass Starts to Make a Mark

[R.A. Hettinga]

The Wall Street Journal

  December 20, 2004

Digipass Starts to Make a Mark
Vasco Enhances Online Security
 As Web Banks Gain Popularity

By STEVE DE BONVOISIN
DOW JONES NEWSWIRES
December 20, 2004


BRUSSELS -- Life-insurance salesman Renaud Bruneels, 34 years old, says he
doesn't have time to take care of "life's little administrative issues" by
visiting a bank during regular business hours.

The Belgian has solved the problem by becoming one of 12 million users
world-wide of Vasco Data Security International Inc.'s Digipass. The
pocket-size gadget, which looks like a calculator, lets him use a single
password to pay everything from garbage fees to phone bills over the
Internet.

INSIDE TECH

1
See complete coverage2 of Europe's technology sector, from cellphones to
software.

"It gives me the level of security I need to ... do all my banking
transactions," Mr. Bruneels says.

Vasco, which is based in Brussels and Chicago, is riding an uptick in
online banking -- particularly in Europe, which has moved ahead of the
U.S.; the company believes that the U.S. market will take off within the
next two years, as banks roll out the service to retail customers.

Digipass can be used to access anything online, from bank accounts to
secure servers to a corporate intranet. Given a username and password, it
issues a one-time code to be used for purchases or transactions on the Web.
Because the code only works once, hackers who infiltrate a computer can't
use it again. The added level of security sets the Digipass system apart
from other online transactions via mobile handsets or laptop computers.

Vasco was founded in 1997 by Digipass inventor Jan Valcke, a Belgian, and
Ken Hunt, an American who ran an online-authentication software company.
But after the Internet bubble burst in 2000, customers hesitated to invest
in Internet banking security.

Digipass "came out a little too early ... when the big focus was on viruses
and not on identity theft," said Edward Ching, technology analyst at Rodman
& Renshaw in New York.

The stock fell from a high of $25 (¤18.81) in February 2000 to under $1 in
early 2003, forcing Vasco to delist from Nasdaq's National Market and move
on to the SmallCap Market.

In 2002, Mr. Hunt took over as chief executive. Vasco switched to "just in
time" production, and spent hundreds of thousands of dollars training
resellers to tackle the corporate-access market.

In November, the company posted its third consecutive quarterly sales
increase. Vasco forecasts 2004 sales will rise between 23% and 25% from
$22.87 million in 2003, and on Thursday Vasco said it expects 2005 sales to
grow 35% to 45% with gross margins in the range of 60% to 65%.

On Friday, Vasco shares fell eight cents to $6.40 in 4 p.m. Nasdaq Stock
Market trading.

Vasco still faces stiff competition. It has only about $10 million in cash,
putting it at a disadvantage against U.S. rival RSA Security Inc., when
chasing big contracts. In September, RSA signed a landmark deal with Time
Warner Inc.'s America Online service to provide authentication for users
signing into their online e-mail accounts.

"We don't have the brand recognition we deserve," says Mr. Hunt, who admits
Vasco wasn't even invited to bid on the Time Warner contract. As a result,
the company has increased its presence in trade shows together with
partners such as Novell Inc. and Lucent Technologies Inc., and is bringing
prospective and current clients together in workshops to help them solve
operational problems.

More than 100 million households world-wide now bank online, and that
number is expected to triple to 300 million or more households by the end
of the decade. Europe has taken the lead. About 37% of all Internet users
on the Continent bank online, as opposed to 17% in the U.S., according to
reports from research firms Gartner and Forrester Research. The number of
Europeans carrying out financial transactions on the Net is expected to
rise to 130 million by 2007, compared with 67 million Americans.

Banks are Digipass's main customers. "Digipass is the most secure system
available and the one which offers the greatest mobility," said Liliane
Tackaert, spokeswoman for Belgo-Dutch banking giant Fortis NV. About
775,000 of the bank's clients in Belgium and Luxembourg use the service.

Rabobank, of the Netherlands, Europe's biggest online bank in terms of
online customers, has more than two million Digipasses in use.

Vasco hopes it will become a lead supplier for the new European EMV payment
card next year. Developed jointly by Europay International, MasterCard Inc.
and Visa International, the card requires a PIN number in addition to a
usual signature when buying goods in a shop, as well as a one-time code --
such as the one generated by Digipass -- to buy goods online or over the
phone. In addition to Vasco, Xiring, of Suresnes, France, and U.S.-based
ActivCard Corp., Fremont, Californ

Best-Kept Secrets

[R.A. Hettinga]

Scientific American:
  
December 20, 2004

Best-Kept Secrets

Quantum cryptography has marched from theory to laboratory to real products

By Gary Stix

 At the IBM Thomas J. Watson Research Laboratory, Charles Bennett is known
as a brilliant theoretician--one of the fathers of the emerging field of
quantum computing. Like many theorists, he has not logged much experience
in the laboratory. His absentmindedness in relation to the physical world
once transformed the color of a teapot from green to red when he left it on
a double boiler too long. But in 1989 Bennett and colleagues John A. Smolin
and Gilles Brassard cast caution aside and undertook a groundbreaking
experiment that would demonstrate a new cryptography based on the
principles of quantum mechanics.

 The team put together an experiment in which photons moved down a
30-centimeter channel in a light-tight box called "Aunt Martha's coffin."
The direction in which the photons oscillated, their polarization,
represented the 0s or 1s of a series of quantum bits, or qubits. The qubits
constituted a cryptographic "key" that could be used to encrypt or decipher
a message. What kept the key from prying eavesdroppers was Heisenberg's
uncertainty principle--a foundation of quantum physics that dictates that
the measurement of one property in a quantum state will perturb another. In
a quantum cryptographic system, any interloper tapping into the stream of
photons will alter them in a way that is detectable to the sender and the
receiver. In principle, the technique provides the makings of an
unbreakable cryptographic key.

 Today quantum cryptography has come a long way from the jury-rigged
project assembled on a table in Bennett's office. The National Security
Agency or one of the Federal Reserve banks can now buy a
quantum-cryptographic system from two small companies--and more products
are on the way. This new method of encryption represents the first major
commercial implementation for what has become known as quantum information
science, which blends quantum mechanics and information theory. The
ultimate technology to emerge from the field may be a quantum computer so
powerful that the only way to protect against its prodigious code-breaking
capability may be to deploy quantum-cryptographic techniques.

 The arrival of the quantum computer may portend the eventual demise of
ciphers based on factorization.

The challenge modern cryptographers face is for sender and receiver to
share a key while ensuring that no one has filched a copy. A method called
public-key cryptography is often used to distribute the secret keys for
encryption and decoding of a full-length message. The security of
public-key cryptography depends on factorization or other difficult
mathematical problems. It is easy to compute the product of two large
numbers but extremely hard to factor it back into the primes. The popular
RSA cipher algorithm, widely deployed in public-key cryptography, relies on
factorization. The secret key being transferred between sender and receiver
is encrypted with a publicly available key, say, a large number such as
408,508,091 (in practice, the number would be much larger). It can be
decrypted only with a private key owned by the recipient of the data, made
up of two factors, in this case 18,313 and 22,307.

 The difficulty of overcoming a public-key cipher may hold secret keys
secure for a decade or more. But the advent of the quantum information
era--and, in particular, the capability of quantum computers to rapidly
perform monstrously challenging factorizations--may portend the eventual
demise of RSA and other cryptographic schemes. "If quantum computers become
a reality, the whole game changes," says John Rarity, a professor in the
department of electrical and electronics engineering at the University of
Bristol in England.

 Unlike public-key cryptography, quantum cryptography should remain secure
when quantum computers arrive on the scene. One way of sending a
quantum-cryptographic key between sender and receiver requires that a laser
transmit single photons that are polarized in one of two modes. In the
first, photons are positioned vertically or horizontally (rectilinear
mode); in the second, they are oriented 45 degrees to the left or right of
vertical (diagonal mode). In either mode, the opposing positions of the
photons represent either a digital 0 or a 1. The sender, whom
cryptographers by convention call Alice, sends a string of bits, choosing
randomly to send photons in either the rectilinear or the diagonal modes.
The receiver, known as Bob in crypto-speak, makes a similarly random
decision about which mode to measure the incoming bits. The Heisenberg
uncertainty principle dictates that he can measure the bits in only one
mode, not both. Only the bits that Bob measured in the same mode as sent by
Alice are guaranteed to be in the correct orientation, thu

International meet on cryptology in Chennai

[R.A. Hettinga]

Chennai Online News Service - View News

 Dec 20, 2004 Mon
 Dharana
  
International meet on cryptology in Chennai
Search for More News

 Chennai, Dec 19: A three-day international conference on cryptology will
get underway here tomorrow with the aim of providing secure communication
to the business and military sectors.

Over 140 researchers in the field, including some from abroad, would
participate in the conference, Dr M S Vijyaraghavan, executive director,
Society for Electronics Transactions and Security (SETS), told reporters
here today.

Cryptography is the art of providing secure information over insecure
channels. It encodes texts and provides a method of decoding. Cryptanalysis
is the art of breaking into cryptographic information.

The new science - cryptology - was a study of both, he said.

India had not made any headway in cryptology, he said and added that the
conference would help develop this in a big way.

President A P J Abdul Kalam would address the participants through video
conferencing. Dr R Chidambaram, principal scientific adviser, Government of
India, would inaugurate the conference. (Our Correspondent)


  
Published: Sunday, December 19, 2004


-- 
-
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]

DIMACS Workshop on Large-Scale Games at Northwestern University

[Linda Casals]

**Call For Papers
*
 
DIMACS Workshop on Large-Scale Games
 April 17 - 19, 2005
 **Location:  Evanston Campus, Northwestern University,
   Evanston, Illinois**

Organizers:
 Lance Fortnow, University of Chicago, [EMAIL PROTECTED] 
 Rakesh Vohra, Northwestern University, [EMAIL PROTECTED] 
 
Presented under the auspices of the Special Focus on Computation and
the Socio-Economic Sciences.

 

On the Internet we have games with a large number of agents,
asynchronous play, and an the absence of full knowledge about the
number of agents one is playing against or the beliefs they
possess. The Internet is not the only institution to possess these
features nor the first. Markets for traditional goods and services as
well as travel networks all possess these features.

This workshop is devoted to the analysis of large scale games of the
kinds inspired by the Internet and other computer networks, markets,
traffic networks and other large systems. We invite papers that will
show how to adapt and extend classical game theoretic models to deal
with a large number of players, accommodate the absence of common
knowledge, common priors, asynchrony in play and distributed
computation.

Examples of the kind of work that would be suitable for this workshop
include price of anarchy models, robust and on-line mechanism design,
timing games, asymptotic analysis of traditional auctions, continuous
double auctions (two-sided markets) and network formation.

Please submit an extended abstract or paper (in .pdf form only) to
[EMAIL PROTECTED] by January 15, 2005. Include the
word `DIMACS' in the subject heading.  Acceptance decisions will be
made by February 15, 2005.

It will consist of 5 invited overview talks (hour long) and a
collection of submitted talks (half hour). The overview talks are
listed below. This workshop is supported by DIMACS, the Managerial
Economics and Decision Sciences Department of the Kellogg School
(http://www.kellogg.nwu.edu/meds/index.htm) and Northwestern
University's Institute for Complex Systems
(http://ccl.northwestern.edu/nico/).

The workshop will take place at Northwestern University's Evanston
Campus. It will start on the morning of the 17th and end around lunch
time on the 19th.

OVERVIEW TALKS:

*   Network and Coalition Formation: Matthew Jackson
*   Price of Anarchy Models: Tim Roughgarden
*   Equilibrium Notions for Games with Many Players: Ehud Kalai
*   Mechanism Design Models without the Common Prior: Jason Hartline
*   Asymptotic Analysis of Market Mechanisms: Mark Satterthwaite


**
Call For Participation:

Please submit an extended abstract or paper (in .pdf form only) to
[EMAIL PROTECTED] by January 15, 2005. Include the
word `DIMACS' in the subject heading.  Acceptance decisions will be
made by February 15, 2005.

**
Registration Fees:

(Pre-registration deadline: March 15, 2005)

Please see website for additional registration information.

*
Information on participation, registration, accomodations, and travel 
can be found at:

http://dimacs.rutgers.edu/Workshops/Games/

   **PLEASE BE SURE TO PRE-REGISTER EARLY**

***

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

All Horsemen, All the Time: On the Open Internet, a Web of Dark Alleys

[R.A. Hettinga]

Horsemen of the Infocalypse, that is...

Cheers,
RAH
---



The New York Times

December 20, 2004

On the Open Internet, a Web of Dark Alleys
 By TOM ZELLER Jr.


The indictment early this month of Mark Robert Walker by a federal grand
jury in Texas might have seemed a coup for the government in its efforts to
police terrorist communications online. Mr. Walker, a 19-year-old student,
is accused, among other things, of using his roommate's computer to
communicate with - and offer aid to - a federally designated terrorist
group in Somalia and with helping to run a jihadist Web site.

 "I hate the U.S. government," is among the statements Mr. Walker is said
to have posted online. "I wish I could have been flying one of the planes
on Sept. 11."

By international terror standards, it was an extremely low-level bust. But
the case, which was supposedly broken only after Mr. Walker's roommate
tipped off the police, highlights the near impossibility of tracking
terrorist communications online.

 Even George J. Tenet, the former director of central intelligence,
speaking on the vulnerabilities of the nation's computer networks at a
technology security conference on Dec. 1, noted the ability of terrorists
to "work anonymously and remotely to inflict enormous damage at little cost
or risk to themselves." He called for a wholesale taming of cyberspace.

 "I know that these actions would be controversial in this age where we
still think the Internet is a free and open society with no control or
accountability," Mr. Tenet said, "But, ultimately, the Wild West must give
way to governance and control."

Even if the government is able to shore up its networks against attack -
one of many goals set forth by the intelligence reform bill passed last
week - the ability of terrorists and other dark elements to engage in
covert communications online remains a daunting security problem, and one
that may prove impossible to solve.

 Late last month, an Internet privacy watchdog group revealed that the
Central Intelligence Agency had contributed money for a counterterrorism
project that promised, among other things, an automated surveillance system
to monitor conversations on Internet chat rooms. Developed by two computer
scientists at Rensselaer Polytechnic Institute in Troy, N.Y., as part of a
National Science Foundation program called Approaches to Combat Terrorism,
the chat room project takes aim at the possibility that terrorists could
communicate through crowded public chat channels, where the flurry of
disconnected, scrolling messages makes it difficult to know who is talking
to whom. The automated software would monitor both the content and timing
of messages to help isolate and identify conversations.

 Putting privacy concerns aside, some Internet specialists wonder whether
such projects, even if successful, fail to acknowledge the myriad other
ways terrorists can plot and communicate online. From free e-mail accounts
and unsecured wireless networks to online programs that can shield Internet
addresses and hide data, the opportunities to communicate covertly are
utterly available and seemingly endless.

Even after the Sept. 11 attacks, "the mass media, policy makers, and even
security agencies have tended to focus on the exaggerated threat of
cyberterrorism and paid insufficient attention to the more routine uses
made of the Internet," Gabriel Weimann, a professor of communication at
Haifa University in Israel, wrote in a report for the United States
Institute of Peace this year. "Those uses are numerous and, from the
terrorists' perspective, invaluable."

 Todd M. Hinnen, a trial attorney with the United States Justice
Department's computer crime division, wrote an article on terrorists' use
of the Internet for Columbia Science and Technology Law Review earlier this
year. "There's no panacea," Mr. Hinnen said in an interview. "There has
always been the possibility of meeting in dark alleys, and that was hard
for law enforcement to detect."

 Now, every computer terminal with an Internet connection has the potential
to become a dark alley.

 Shortly after Sept. 11, questions swirled around steganography, the
age-old technique of hiding one piece of information within another. A
digital image of a sailboat, for instance, might also invisibly hold a
communiqué, a map or some other hidden data. A digital song file might
contain blueprints for a desired target.

 But the troubling truth is that terrorists rarely have to be technically
savvy to cloak their conversations. Even simple, prearranged code words can
do the job when the authorities do not know whose e-mail to monitor or
which Web sites to watch. Interviews conducted by Al Jazeera, the Arab
television network, with the terror suspects Khalid Shaikh Mohammed and
Ramzi bin al-Shibh two years ago (both have since been arrested), suggested
that the Sept. 11 attackers communicated

Re: SSL/TLS passive sniffing

[Florian Weimer]

* Victor Duchovni:

> The third mode is quite common for STARTTLS with SMTP if I am not
> mistaken. A one day sample of inbound TLS email has the following cipher
> frequencies:
>
> 8221(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
> 6529(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))

The Debian folks have recently stumbled upon a problem in this area:
Generating the ephemeral DH parameters is expensive, in terms of CPU
cycles, but especailly in PRNG entropy.  The PRNG part means that it's
not possible to use /dev/random on Linux, at least on servers.  The
CPU cycles spent on bignum operations aren't a real problem.

Would you recommend to switch to /dev/urandom (which doesn't block if
the entropy estimate for the in-kernel pool reaches 0), and stick to
generating new DH parameters for each connection, or is it better to
generate them once per day and use it for several connections?

(There's a second set of parameters related to the RSA_EXPORT mode in
TLS, but I suppose it isn't used much, and supporting it is not a top
priority.)

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

Re: The Pointlessness of the MD5 "attacks"

[Jon Callas]

So, are you sure there can never be a program which allows such an 
exploit?  I've seen programs that had embedded components (state 
machines in particular) which were not easily human-readable, and had 
themselves been generated by computer.  And even large graphics, 
sound, or video sequences can really change the meaning of a program's 
actions in some ways; those might be susceptible to the requirements 
of the attack.  I agree it's hard to see how to exploit the existing 
MD5 collision attacks in programs that would look innocent, but I 
don't see what makes it *impossible*.

That's not what Ben is saying at all. He's saying that once you give 
the adversary the power to do the sorts of things that are required for 
this (like being able to replace a give C with C'), there are easier 
ways for the attacker to get the desired result than playing with 
collisions.

I do, however, feel the need to be a bit pedantic and say that tables 
for state machines are seldom random (for some suitable definition of 
random). Nor are graphics, sound, nor video. Inserting the artifacts 
into them you need to make this work is really, really obvious for the 
same reasons that Shamir and Van Someren showed that finding key 
material is so easy.

I have an attack that I just came up with that pretty much proves Ben's 
point. I can, using this technique, make any MD5 preimage give you any 
desired hash value. It's trivial, once I can replace code C with C'.

Give up? Answer below.
Hint: it works just as well against SHA1. Or SHA-256. Or Whirlpool. Or 
pick your hash.

Answer:



patch the md5 software. put in a table that gets searched -- when you 
see hash x, return y. if you want to be clever, obfuscate the check and 
the result. toss in some xoring so you don't have the direct target and 
result hashes there, so simple grepping doesn't give the trick away. 
But once you can replace C with C', why bother doing bit-flipping when 
you can just compile the code you want, and replace the code that rats 
you out?

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

Fwd: The PoinFULLness of the MD5 'attacks'

[james hughes]

For this discussion, I think we are missing the point here...
1. With a rogue binary distribution with correct hash, this is -at 
least- a denial of service where the customer will install the rogue 
binary and it will crash in the area that the information was changed. 
MD5 based Tripwire will not catch this happening if this is done on the 
distribution machine.

2. If the rogue binary is a driver that gets into the kernel, it could 
cause a crash and that crash -could- cause a kernel exploit.

3. A modification to an seldom used section of code that can be invoked 
in some non-typical way can cause a machine to crash on command.

4. Offline, the attacker could automate a trial and error scheme to 
create random collisions and testing each until one produces an effect 
to their advantage and then substitute it for the real one.

Again, anything that gives the legitimate user a feeling of security 
(because the hashes match) and allows the attacker to do anything to 
their advantage is a failure of the MD5 algorithm.

Maybe these are low probabilities... Are you willing to step up and say 
there is nothing that the attacker can ever do using these collisions? 
I'm not.

My suggestion is that all distributions publish the MD5 and SHA-256 
hashes for a while and then drop the MD5 based ones in a year or so.

thanks
jim

On Dec 15, 2004, at 10:45 AM, Tim Dierks wrote:
On Wed, 15 Dec 2004 08:51:29 +, Ben Laurie <[EMAIL PROTECTED]> 
wrote:
People seem to be having a hard time grasping what I'm trying to say, 
so
perhaps I should phrase it as a challenge: find me a scenario where 
you
can use an MD5 collision to mount an attack in which I could not mount
an equally effective attack without using an MD5 collision.
Here's an example, although I think it's a stupid one, and agree with
you that the MD5 attack, as it's currently known to work, isn't a
material problem (although it's a clear signal that one shouldn't use
MD5):
I send you a binary (say, a library for doing AES encryption) which
you test exhaustively using black-box testing. The library is known
not to link against any external APIs (in fact, perhaps it's
implemented in a language and runtime with a decent security sandbox
model, e.g., Java). You then incorporate it into your application and
sign the whole thing with MD5+RSA to vouch for its accuracy.
I incorporate several copies of a suitable MD5 collision block in my
library, so one of them will be at the correct 64-byte block boundary.
I can then modify bits inside of my library, which car checked by the
library code and cause it to change the functionality of the library,
yet the signature will still verify.
This would be pretty easy to do as a proof-of-concept, but I don't
have the time.
- Tim
-
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: The Pointlessness of the MD5 "attacks"

[Ondrej Mikle]

On Wed, 15 Dec 2004 10:06:10 -0500 (GMT-05:00), John Kelsey
<[EMAIL PROTECTED]> wrote:
> 
> So, are you sure there can never be a program which allows such an exploit?  
> I've seen programs that had embedded components (state machines in 
> particular) which were not easily human-readable, and had themselves been 
> generated by computer.  And even large graphics, sound, or video sequences 
> can really change the meaning of a program's actions in some ways; those 
> might be susceptible to the requirements of the attack.  I agree it's hard to 
> see how to exploit the existing MD5 collision attacks in programs that would 
> look innocent, but I don't see what makes it *impossible*.
> 
> Finally, I'm very skeptical that the attacks that have been found recently 
> are the best or only ones that can be done.
> Do we have any special reason to think that there will never be a way to 
> adapt the attack to be able to slip something plausible looking into a C 
> program?  Once your hash function starts allowing collisions, it really just 
> becomes a lot less valuable.
> 

Exactly.

Yes, malware can be distributed without any use of any hash function.
I try to demonstrate on an example, what the MD5 collision provides
and how to make it 'innocent'. You don't have to put malicious code in
the program. For example, telnet is not secure, but there are uses of
it which don't need encryption/authentication. Similarly, HTTP is
widely used, but HTTPS can be used when needed. Take a bank as an
example. Some transactions require secure connection, but not every
page on the bank server has to be transmitted using a secure
connection. If an attacker would cause the software to switch from
HTTPS to HTTP in the "right" moment, it could lead to disaster.

Most of data (file) formats have some sort of header. An attacker can
do this: He will say that the colliding block is a header, with first
four bytes being the 'magic bytes' as you know from many formats (e.g.
exe has MZ, bmp has BM, elf executables have ELF). Next, he will
proclaim that the rest of the 1024 bits are some data, e.g. some
counts of something and the differing bits/bytes will be some flags.
The point is to use the bits in some calculation that is legitimate.
That means, it "moves the question of trust" onto the data package. A
person doing inspection would not find anything wrong, since the
person receives correct executable and the "good" data package. That
is the difference between use and non-use of MD5 collision. An
obfuscated malicious code can be discovered, even though it may be
difficult. When you use collision, it may not be discovered, since
there is no "evil" action in the code. The "evil" is created as a race
condition using the "evil" colliding package.

Now, I try an example (I know it's not the best one, but I hope it
makes the point clear):

Suppose an attacker is packager in a company and his role is to take
software, pack it up and create installation scripts. The package is
still reviewed after his packaging. Let's suppose the company is
working on some server-bundle-software which installs http server, IDS
and optionally SSH and Telnet. By default, Telnet is disabled.
Telnet's role may be for example so that anyone could telnet to the
machine and have e.g. statistics of server usage or some non-sensitive
information or computation. That's the justification of having the
telnet there in the software. If one wanted to use it, he would enable
it and configure it correctly so that anonymous users can't do any
harm or get to sensitive information.

Well, there is the flag in the header (=the colliding block) saying if
it should be installed or not. After packaging is complete, it is
inspected once more and if no flaw is found, it is put on company's
ftp/web server for distribution along with MD5 sums published on
multiple places. Then the attacker (as an insider) swaps the two
packages. Anyone believing the MD5 sums would install the software and
wouldn't realize that telnet is installed and not configured
(documentation says something different). That could open a way for
anyone in.

To sum it up, the MD5 collision allows:
-have code and data, that do not do anything unwanted (can be proven
by inspecting the code)
-the other colliding package does the same, but it creates some
unnecesary service/action that is dangerous in given context. The
presence of the service is justified, though. In default installation
it is disabled. So says the manual. But that's not true. So the MD5
collision itself does not do much, but with additional trickery it
could be used.

If the flaw would be discovered in the software, who would be held
responsible in the company? The testers, inspectors of code. Not the
packager. He could sell the knowledge of the security hole to
spammers, virus writers, etc. I'm not saying the MD5 collision allows
for a highly practical attack (at least the example involves an
insider), but when we know it's possible, why should we c

pgp "global directory" bugged instructions

[Adam Back]

So PGP are now running a pgp key server which attempts to consilidate
the inforamtion from the existing key servers, but screen it by
ability to receive email at the address.

So they send you an email with a link in it and you go there and it
displays your key userid, keyid, fingerprint and email address.

Then it says:

| Please verify that the email address on this key, [EMAIL PROTECTED],
| is your email address, and is properly configured to send and
| receive PGP secured email.
|
| If the information is correct, click 'Accept'. By clicking 'Accept',
| your key will be published to the directory, where other PGP users
| will be able to retrieve it in order to encrypt messages to you and
| verify signed messages from you.
|
| If this information is incorrect, click 'Cancel'. By clicking
| 'Cancel', this key will not be published. You may then submit
| another key with the correct information.

So here's the problem: it does not mention anything about checking
that this is your fingerprint.  If it's not your fingerprint but it is
your email address you could end up DoSing yourself, or at least
perpetuating a imposter key into the new supposedly email validated
keyserver db.

(For example on some key servers there are keys with my name and email
that are nothing to do with me -- they are pure forgeries).

Suggest they add something to say in red letters check the fingerprint
AND keyid matches your key.

Adam

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

Re: Cryptography Research wants piracy speed bump on HD DVDs

[Ian Grigg]

> What CR does instead is much simpler and more direct. It tries to cut off
> any player that has been used for mass piracy.

Let me get this right. ...

> "When a pirate makes a copy of a film encoded as SPDC, the output file is
> cryptographically bound to a set of player decryption keys. So it is easy
> when looking at a pirated work on a peer to peer network, or any copies
> found on copied DVDs, to identify which player made those copies," said
> Laren "When the content owner sends out any further content it can contain
> on it a revocation of just the player that was used to make a pirated copy."

A blockbuster worth $100m gets cracked ... and
the crack gets watermarked with the Id of the
$100 machine that played it.

> "We picture a message popping up on a screen saying something like 'Disney
> movies won't play on your player any more please call this number for
> further information.' Or perhaps 'To fix this please call Disney with your
> credit card,' something like that anyway.

So the solution is to punish the $100 machine by
asking them to call Disney with a CC in hand?

As described this looks like snake oil.  Is this
for real?

iang

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

Re: The Pointlessness of the MD5 "attacks"

[Ben Laurie]

Jay Sulzberger wrote:
On Tue, 14 Dec 2004, Ben Laurie wrote:
Ondrej Mikle wrote:
[snipped many assertions without supporting evidence that MD5 cracks 
improve attacks]

So, to exploit this successfully, you need code that cannot or will not
be inspected. My contention is that any such code is untrusted anyway,
so being able to change its behaviour on the basis of embedded bitmap
changes is a parlour trick.
That's true in theory, but it's different in real world. Take
Microsoft software as an example. Many banks use their software (and
sometimes even military). I don't think that all of them reviewed
Microsoft's source code (I guess only a few, if any at all). There was
an incident of a worm attacking ATMs.
No, and they are therefore vulnerable to Microsoft. Note that MD5 is 
not required for Microsoft to attack them.
Again, the MD5 crack helps.  Here one attack is obvious: third parties may
more easily make substitutions of code.
No, they may not. This crack does _not_ allow a third party to do 
anything interesting.

Another example, Enigma was being sold after WW 2, but the Allies knew
it could be broken. The purchasers did not. Same as when US army sold
some radio communications that used frequency hopping to Iraq during
1980's. US knew that it could be broken ("just in case...").

And MD5 helps with this how?
Cheers,
Ben.

The MD5 crack helps here in several ways.  Perhaps the most important is
that if MD5 is thought to be uncracked, that simple MD5 checking might be
considered so safe that no second check is used, at points where a second
and third check would help, thus opening up a possible avenue of attack.
You are simply restating the supposed attack here, without providing any 
evidence it is useful.

Indeed, even before MD5 was widely known to be cracked, competent security
folk often recommended that several hashes be used since in most
applications the cost of computing hashes is small.
This is true, but not germane.
One point to remember
is that the published cracks are likely only a small part of the cracks
known to well funded professionals.  The parallel to the case of the weak
Enigmas is that many people buying the weak Enigmas thought they were
uncracked, else they would not have bought them.  Despite the recent
published MD5 cracks, it is clear that the most interesting cracks of MD5
are as yet unpublished.
Again, probably true, but definitely not germane. I am saying nothing 
about what future MD5 cracks may enable, I am only commenting on the 
cracks currently known.

To be clear, I am not advocating the use of MD5, nor have I for many 
years. I am simply contesting the theory that the ability to produce 
collisions, as currently known[1], actually provides any useful attack 
vectors.

Cheers,
Ben.
[1] I agree, future possible methods of producing collisions are likely 
to have a real impact on security. This is not what I am discussing.

--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: The Pointlessness of the MD5 'attacks'

[Ben Laurie]

C. Scott Ananian wrote:
On Wed, 15 Dec 2004, Tim Dierks wrote:
Here's an example, although I think it's a stupid one, and agree with
[...]
I send you a binary (say, a library for doing AES encryption) which
you test exhaustively using black-box testing.

The black-box testing would obviously be the mistake.  How can you tell 
that the library doesn't start sending plain-text for messages which 
start with a particular magic bytes, or some other evilness?  You can't 
hope to test *all* messages.  The word 'exhaustively' is where your 
example goes wrong.

I'll play Ben's part and claim that if you can provide a library which 
will *only* be checked using black-box testing, it's much easier to skip 
the whole MD5 aspect and have it use a covert channel (leak key bits in 
padding or some such) or transmit plain-text after the first 100M of 
data encrypted or some such.  There are lots of easy ways to get your 
maliciousness past a black-box test.  The use of MD5 (a relatively 
*hard* way to be malicious) doesn't appreciably change the threat.
Exactly so, thankyou.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: The Pointlessness of the MD5 "attacks"

[Ben Laurie]

John Kelsey wrote:
So, to exploit this successfully, you need code that cannot or will
not be inspected. My contention is that any such code is untrusted
anyway, so being able to change its behaviour on the basis of
embedded bitmap changes is a parlour trick. You may as well have it
ping a website to find out whether to misbehave.
So, are you sure there can never be a program which allows such an
exploit?  I've seen programs that had embedded components (state
machines in particular) which were not easily human-readable, and had
themselves been generated by computer.  And even large graphics,
sound, or video sequences can really change the meaning of a
program's actions in some ways; those might be susceptible to the
requirements of the attack.  I agree it's hard to see how to exploit
the existing MD5 collision attacks in programs that would look
innocent, but I don't see what makes it *impossible*.
I did not say it was impossible, I said that such exploits would work 
just as well without MD5 collisions. For example, if you are going to 
trigger on some subtle distinction such as a single bit flipped, then 
make that a bit in a counter, or a bit in the input stream.

Then you have data files, as Adam Back mentioned, which are often not
human readable, but you'd still like to know if the signature on them
is valid, or if they've been changed surreptitiously since the last
time they were checked over.
Finally, I'm very skeptical that the attacks that have been found
recently are the best or only ones that can be done. Do we have any
special reason to think that there will never be a way to adapt the
attack to be able to slip something plausible looking into a C
program?  Once your hash function starts allowing collisions, it
really just becomes a lot less valuable.
I do not have a special reason to think anything about future attacks on 
MD5. I am discussing the present attacks.

Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: The Pointlessness of the MD5 "attacks"

[James A. Donald]

--
On 15 Dec 2004 at 8:51, Ben Laurie wrote:
> People seem to be having a hard time grasping what I'm trying
> to say, so perhaps I should phrase it as a challenge: find me
> a scenario where you can use an MD5 collision to mount an
> attack in which I could not mount an equally effective attack
> without using an MD5 collision.

I could circulate watermarked versions of copyrighted material
without it being apparent that they were watermarked. 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 brRAUUDlwL/ZhPKf51gh0pzlr6ISDbBPNAbnzJfI
 41Hx46udB9H+g9Lkm68G20fQMC+F6YzLxJhmwuZu4


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

Re: The Pointlessness of the MD5 'attacks'

[C. Scott Ananian]

On Wed, 15 Dec 2004, Tim Dierks wrote:
Here's an example, although I think it's a stupid one, and agree with
[...]
I send you a binary (say, a library for doing AES encryption) which
you test exhaustively using black-box testing.
The black-box testing would obviously be the mistake.  How can you tell 
that the library doesn't start sending plain-text for messages which start 
with a particular magic bytes, or some other evilness?  You can't hope to 
test *all* messages.  The word 'exhaustively' is where your example goes 
wrong.

I'll play Ben's part and claim that if you can provide a library which 
will *only* be checked using black-box testing, it's much easier to skip 
the whole MD5 aspect and have it use a covert channel (leak key bits in 
padding or some such) or transmit plain-text after the first 100M of data 
encrypted or some such.  There are lots of easy ways to get your 
maliciousness past a black-box test.  The use of MD5 (a relatively 
*hard* way to be malicious) doesn't appreciably change the threat.
 --scott

[it should be noted that any security-conscious tester will/ought to 
screen your binary for all of the *published* MD5 collisions, so 
you'll have to generate one yourself if you want to get away with this.]

HTLINGUAL Hager Kennedy AEFOXTROT global action network assassinate
   Register to vote!  http://www.yourvotematters.org/VerifiedVoting
 ( http://cscott.net/ )
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

The Pointlessness of the MD5 "attacks"

[David Wagner]

Ben Laurie writes:
>Indeed, but what's the point? If you control the binary, just distribute 
>the malicious version in the first place.

Where this argument breaks down is that someone might have partial
but not total control over the binary.  This partial control might
not be enough for them to distribute a malicious version straightforwardly,
but just enough to exploit a MD5 collision.  It is hard to be confident
that such an attack scenario is impossible.

To give one contrived example, imagine that the Windows 2010 binary
comes with an image file that is displayed as part of the splash start
screen.  Imagine that the graphic designer is allowed to supply that
image, but the graphic designer has no other authorized access to the
source or binary of Windows.  Now a disgruntled graphic designer might
be able to arrange to find a MD5 collision MD5(img1) = MD5(img2) so that
img1 looks like an entirely reasonable Windows splash screen, but img2
contains some scrawled epithet ("Tired of Windows crashing all the time?
Try Linux!").  Or, even more contrived, imagine that img1.jpg looks
like a completely normal JPG file, but img2.jpg exploits some buffer
overrun in the startup screen's JPG decoder to overwrite the program's
image with some other malicious code.

Sure, these scenarios are contrived and unlikely.  But how do you
know that there is not some other (possibly more complex but less
contrived) scenario that you would consider more troubling?

>People seem to be having a hard time grasping what I'm trying to say, so 
>perhaps I should phrase it as a challenge: find me a scenario where you 
>can use an MD5 collision to mount an attack in which I could not mount 
>an equally effective attack without using an MD5 collision.

I've got a better challenge: show me a convincing argument that no such
scenario exists.

What I'm trying to get at is that you've got the burden of proof
backwards.  Implicit in your challenge is the idea that we should
keep trusting MD5 until someone finds a convincing argument that it is
insecure in practice.  My argument is that this is much too trusting.
I believe that, given the theoretical results on MD5, we should not have
any trust whatsoever in the security of MD5 as a collision-resistant
hash until someone is able to offer a convincing argument that MD5 is
secure enough in practice despite its known weaknesses.

I could try to answer your challenge.  I might even be able to devise
some solution to your challenge that would satisfy you.  For instance,
maybe the image file attack above qualifies as a solution.  Or maybe
the S-box table attack in my previous email is good enough.  But I don't
really want to argue about whether I have found a valid answer to your
challenge.  I shouldn't be required to meet that burden -- the burden
of proof should be on whoever wants to believe that MD5 is secure.

Why should the burden be on MD5 defenders?  Not just because I said so.
Part of the reason is that there are just too many complex scenarios
to consider.  Suppose I conceded that I couldn't find a scenario you'd
accept.  What would that prove?  Very little.  Even if I can't think of
a suitable scenario for you off the top of my head, that doesn't mean
that with more thought I wouldn't find one.  Even if I spent a month
trying and still couldn't find one, that doesn't mean that others can't.

My experience is that if it is possible to find a theoretical attack with
one day's work, it is often possible to extend this to a more practical
attack with, say, one week's work.  Bruce Schneier puts this concisely:
"Attacks always get better."  Trusting in MD5's collision-resistance
amounts to assuming that "cryptanalysts of MD5 will get this far, but
no farther", and that seems like a pretty questionable assumption to me.

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

The Pointlessness of the MD5 "attacks"

[David Wagner]

Ben Laurie writes:
>Dan Kaminsky's recent posting seems to have caused some excitement, but 
>I really can't see why. In particular, the idea of having two different 
>executables with the same checksum has attracted attention.
>
>But the only way I can see to exploit this would be to have code that 
>did different things based on the contents of some bitmap. My contention 
>is that if the code is open, then it will be obvious that it does 
>"something bad" if a bit is tweaked, and so will be suspicious, even if 
>the "something bad" is not triggered in the version seen.
>
>So, to exploit this successfully, you need code that cannot or will not 
>be inspected. My contention is that any such code is untrusted anyway, 
>so being able to change its behaviour on the basis of embedded bitmap 
>changes is a parlour trick. You may as well have it ping a website to 
>find out whether to misbehave.

I guess I disagree.  Imagine that the code has some block cipher with
some S-boxes hardcoded into it.  The code uses this block cipher to
decrypt an associated ciphertext and outputs (or takes some action based
on) the resulting message.  This is an example of code that could be
used to fool a MD5 checksum.  Moreover, I don't have a great deal of
confidence that even a careful code inspection would cause the code to
be considered suspicious.  Consequently, I don't have great confidence
that such an attack would be detected.

I know it is tempting to think that, look, Wang et al only found a pair
of random-looking messages that collide; they didn't claim to find a pair
of meaningful messages that collide; and maybe we can hope that there is
no way to come up with a pair of meaningful-looking colliding messages.
But I think that kind of hope is unfounded, and acting on hope is
asking for trouble.  I believe the only safe course now is to assume
that MD5's collision resistance is totally broken.  If Wang et al can
find meaningless-looking collisions today, it seems all too likely that
someone else may be able to find meaningful-looking collisions tomorrow.
Hoping that the latter will be hard even though the former is known to
be easy seems too optimistic for my tastes.

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

Re: The Pointlessness of the MD5 'attacks'

[Sidney Markowitz]

This isn't worked out enough to be a proof of concept, but I can imagine 
a piece of code that has a comment "This can't overflow because value X 
computed from the magic bits table will always be between A and B. Get 
0.1% speed boost by leaving out range check here but don't change magic 
bits".

That doesn't even have to be so obscure. It provides a place to 
introduce a security hole that will not be noticed by substituting a new 
magic bits table without the protective property. Unless someone takes 
their copy of the source code that has MD5 equal to the MD5 of the 
sources that have been reviewed by the experts and verifies for 
themselves whether their magic bits table does compute a value X between 
A and B, they are vulnerable. If MD5 is trusted, there is no reason to 
audit every downloaded copy of the source code like that, as long as you 
are sure that someone has done the audit.

 -- sidney
http://www.sidney.com/
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]