Re: small crypto that isn't predictable

2001-01-24 Thread Paul Crowley

Bill Stewart [EMAIL PROTECTED] writes:
 If you've got room for an IV, you _could_ do something like
 XORing the IV with the key, not the data stream -
 that means that it isn't really using the same algorithm
 for the IV as for the rest of the data stream, but you may not care.

With RC4, it's better simply to append the IV to the key rather than
XORing it.  It sounds like the RC4-based CipherSaber is exactly the
algorithm you want: http://ciphersaber.gurus.com/

CipherSaber prepends a 10-byte IV to the ciphertext, so your
ciphertext is 10 bytes longer than the plaintext, and you have to
generate an expected 2^40 or so ciphertexts with the same key before you get 
a disastrous IV collision.

Nitpick: here I'm using "IV" to mean "any nonce for a randomized
stream cipher".  A purist might restrict the meaning to mean an
initial state for a block cipher chaining mode.
-- 
  __
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/




Re: Perfect compression and true randomness

2001-01-08 Thread Paul Crowley

"Arnold G. Reinhold" [EMAIL PROTECTED] writes:
 In any case, as I tried to point out before, perfect compression, what
 ever it may be, does not prevent a know-plaintext attack.

Actually it does: if the compression is perfect with respect to the
document model of the attacker, and the plaintext is known, then it
compresses down to zero bits so the attacker learns nothing.

This supports your main point: perfect compression is a *much* less
realistic idea than true randomness!
-- 
  __
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/




Re: Cryptographic Algorithm Metrics

2001-01-03 Thread Paul Crowley

Peter Fairbrother [EMAIL PROTECTED] writes:
 Not so. Perfect compression with encryption works too.

Er, does it?  I get a 1k message from you, perfectly compressed and
then encrypted with some strong algorithm and a 128-bit key.  As a
godlike being unhindered by constraints of computational power, I try
all 2^128 possible keys, and find due to the perfect compression that
each of the 2^128 plaintexts is equally likely.  From an information
theoretic point of view, I'm much better off than I was before: I used 
to be missing 8192 bits of entropy, but now I'm only missing 128 - the 
space of possible messages has been vastly reduced.  Put it this way,
if all I want to know is whether you're asking for a ticket to the
dance, I might well learn the answer since I might find that none of
the candidate messages include that request.

A 1k message encrypted with OTP, however, tells me nothing whatsoever.
-- 
  __
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/




Re: copy protection

2000-12-24 Thread Paul Crowley

"Perry E. Metzger" [EMAIL PROTECTED] writes:
 Getting around the license stuff will always be trivial, however, in
 spite of the pipe dreams of fools. If the software can be read by the
 user's computer, it can be copied. If it can be copied, automated
 tools will be developed to permit it.

"Trivial" is overstating it, I think.  I've seen dongle-based license
code designed such that if you tried modifying the code to skip the
dongle check, the program's pointer arithmetic would go screwy and it
would crash in horrible ways.  It was a damn clever design, which I
can't say much about here except that it depended on a fairly detailed 
understanding of the innards of several parts of a large and complex
program, and so making the appropriate fix would be a sizeable job for 
a very skilled and patient hacker; for example, it did not depend on 
branches that were only taken when the dongle was absent.

Of course, it could be cracked, but it wouldn't have been trivial.
-- 
  __
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/




Re: IBM press release - encryption and authentication

2000-12-11 Thread Paul Crowley

Rich Salz [EMAIL PROTECTED] writes:

  No word, of course, on how the thing actually works, or whether they
  intend to patent it.
 
 Not so.  Search your nearest IETF internet-drafts repository for 
   draft-jutla-ietf-ipsec-esp-iapm-00.txt

Eh?  It would be bad if a patented system became an IETF standard.
And if we could make such a standard, it should almost certainly be
one of the other proposals heard by NIST, Galois-field OCB.

[A draft does not imply an IETF standard in the making. Anyone can
publish a draft, or even an RFC.  --Perry]

-- 
  __
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/




Re: migration paradigm (was: Is PGP broken?)

2000-12-10 Thread Paul Crowley

Rick Smith at Secure Computing [EMAIL PROTECTED] writes:
 Now, just how do we intend to address such concerns in our memory-based 
 authentication systems? Our whole technology for using memorized secrets is 
 built on the belief that people will remember and recite these secrets 
 perfectly. Some applications could take more of a 'biometric pattern 
 matching' strategy that measures the distance between the actual passphrase 
 and a stored pattern. But this won't provide us with a secret we can use in 
 crypto applications like PGP.

There has been some work on addressing this issue.  See

http://www.counterpane.com/personal-entropy.html
-- 
  __
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/




Re: migration paradigm (was: Is PGP broken?)

2000-12-10 Thread Paul Crowley

Bram Cohen [EMAIL PROTECTED] writes:
  Is there a reason not to use AES block cipher in a hashing mode
  if you need a secure digest of some data? 
 
 Hashing modes of block ciphers require a re-key for every block, and hence
 are really, really slow.

Well, Rijndael can re-key faster than it can encrypt, so it's less of
a problem than with other block ciphers.  Of course, there are not
unrelated worries that Rijndael's key schedule may not offer the
strength required for hashing modes, though the designers are
confident that the strength of the round function ensures everything
will be OK.
-- 
  __
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/




Re: Lots of random numbers

2000-11-18 Thread Paul Crowley

Bill Sommerfeld [EMAIL PROTECTED] writes:

  Eh?  You should *never* need to encrypt information before shoving
  it in the pool.  If you've got a secret you could use for such
  encryption, shove it in the pool and then forget about it - it will do 
  precisely as much good.
 
 I'm inclined to agree with Don here, from principles of conservative
 cryptographic engineering.  By using a keyed one-way function before
 adding data to the pool, you add an additional layer of defense
 against an attacker guessing the pool contents.

If you want to design a new kind of pool based on encrypting the
incoming data, that could be an effective way to do it, but it will be 
part of the pool.  If you start doing that sort of thing outside the
pool, you're just building a bigger pool around the pool you've
already got.  If the pool is Yarrow, then you will be very hard
pressed to build a better pool than the Yarrow designers, by this
strategy or any other.

Conservative cryptographic engineering says complexity is the enemy of
security.  Once you've chosen your components, trust them to do the
job they're designed for - don't pre-encrypt your encrypted data, and
don't build a randomness pool around your randomness pool.
-- 
  __
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/




Re: Lots of random numbers

2000-11-17 Thread Paul Crowley

Don Davis [EMAIL PROTECTED] writes:
perhaps surprisingly, i disagree with the other
 respondents.  as long as you encrypt or MAC the
 incoming packets ( their interarrival times),
 with a closely-guarded secret key, before you
 stuff the bits into your entropy pool,  then you
 should do fine.

Eh?  You should *never* need to encrypt information before shoving
it in the pool.  If you've got a secret you could use for such
encryption, shove it in the pool and then forget about it - it will do 
precisely as much good.

I'm tempted to agree with the thrust of what you're saying, though -
I'm not as convinced as everyone else that Rich's idea is without
merit.  However, I wouldn't bother putting in the packet contents,
just the arrival times.

As you say, I wouldn't use it as your only entropy source - the
Pentium RNG would make a good primary source - and once you've got
enough entropy in the pool you can pull out all the keys you like
without worrying the pool will "run out" of entropy.

The Yarrow paper is great for this: http://www.counterpane.com/yarrow.html
-- 
  __
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/




Re: Lots of random numbers

2000-11-16 Thread Paul Crowley

[EMAIL PROTECTED] writes:
 Why don't you stick a sound card (the noisier, the better) into each
 node, and dump /dev/dsp (LSB) input at max amplification into the
 randomness pool?

There's no reason to put only the LSBs in the randomness pool, if the
pool is properly designed.  Put all the data in.

Has any research gone into estimating the entropy from such a source?
-- 
  __
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/




Re: Multi-part security solutions (Was: Re: Rijndael Hitachi)

2000-10-12 Thread Paul Crowley

Meyer Wolfsheim [EMAIL PROTECTED] writes:
 The only reasons I see for having a security system (be it an encryption
 product, or a physical access device) with a large discrepancy in the level
 of security that the individual components provide is either:

[snip reasons a, b and c]

I'm sure you've thought of this, but there's also a reason (d):
because the most convenient component for a particular application is
vastly more secure than you need.  When using a cipher as a component,
you might as well use a ludicrously strong one like Rijndael or
Blowfish, because there's nothing to be gained from using a weaker
one.  Good locks are more expensive than bad ones, but strong crypto
is free.
-- 
  __
\/ o\ Employ me! Cryptology, security, Perl, Linux, TCP/IP, and smarts.
/\__/ [EMAIL PROTECTED]http://www.cluefactory.org.uk/paul/cv/




NIST, modes of operation and patents.

2000-10-12 Thread Paul Crowley

NIST is running a Modes of Operation workshop on Friday 20th.  See 
http://csrc.nist.gov/encryption/aes/modes/

It seems likely that NIST will demand the same licensing conditions
from anyone proposing a mode of operation for standardisation that
they did for the AES cipher itself.  Does anyone know for sure?  I ask 
because one of the papers listed for discussion at the modes of
operation workshop is a very cute technique for doing authentication
at little extra cost over encryption, but it's patented by IBM, so
it'd be good to see the world get a royalty-free license for this one.
-- 
  __
\/ o\ Employ me! Cryptology, security, Perl, Linux, TCP/IP, and smarts.
/\__/ [EMAIL PROTECTED]http://www.cluefactory.org.uk/paul/cv/




Re: reflecting on PGP, keyservers, and the Web of Trust

2000-09-06 Thread Paul Crowley

I'm still far from convinced that the Web of Trust achieves what it's
supposed to achieve, even when used correctly.  

Consider this question: what do you need to know about a person in
order to feel confident that they are the intended recipient of your
secure communication?  Because I bet the answer is hardly ever "their
legal name".

I recently exchanged some email with a Ruediger Weis I met at a
conference.  When verifying his signature, I wanted to be sure that it
was sent by the person I met.  It would *not* have satisfied me to
know that it was sent by someone of that name, since there are
probably hundreds of people with that name.  And conversely, I don't
actually care if that's his real name - his real legal name can be
Jurgen Schmidt for all I care.  I used the business card he beamed me
to check out his PGP fingerprint, and could therefore be confident
that I was corresponding with the person I met.  If you use this
technique, make sure it's difficult to plant business cards into your
pockets.

I know that the signed information includes an email address as well
as a name.  I'm ignoring that and everyone else should too - there's
no burden on the signer of a key to verify the email address, only the
name.  I can turn up to a keysigning party with my passport and get my
key signed as "Paul Crowley [EMAIL PROTECTED]", because no-one's
expected to check that part.  I think it appears as an ineffective fix
to the problems I'm trying to highlight here.  Note that it does make
sense to sign your *own* key with your email address, so that once
your correspondents decide your key is the right one, they can be
confident of which email address to correspond with!

I don't think the idea of key signing is fundamentally flawed, but I
think we need far more flexibility on what information we bind to a
public key.  I'd like a way of saying "this is the John Smith that I
know, not just any John Smith, and if you've met my friend John Smith
then this is his public key".  I want to bind photographs to keys.
I'd like to say "This is John Smith the famous author", or "This is
the John Smith from the famous case Smith v. Justice 1992".

Are there any commonplace circumstances where confidence in someone's
legal name is enough?
-- 
  __
\/ o\ Employ me! Cryptology, security, Perl, Linux, TCP/IP, and smarts.
/\__/ [EMAIL PROTECTED]http://www.cluefactory.org.uk/paul/cv/




Re: Tipster voluntary payment protocol

2000-08-24 Thread Paul Crowley

"Fred Hapgood" [EMAIL PROTECTED] writes:
 Stick *what* into a standard contract?  What would that provision
 look like?  "Artist agrees not to accept gifts from fans?"   "Artist
 agrees not to possess or publicize public key or digital signature?"  

"Artist shall not in any way participate in any system designed to
assist recipients of digitally copied music to reward the artist
directly."
-- 
  __
\/ o\ Employ me! Cryptology, security, Perl, Linux, TCP/IP, and smarts.
/\__/ [EMAIL PROTECTED]http://www.cluefactory.org.uk/paul/cv/




Re: Extracting Entropy?

2000-07-17 Thread Paul Crowley

A variant on this question that we might see for lots of questions
soon: what's the best way to do this given only AES as a primitive?

Here's a simple way that uses all of the passphrase to control a
cryptographic PRNG that can be used to generate keys or whatever: use
the passphrase as the key to the block cipher, and run it in counter
mode.

If the passphrase is less than 256 bits (32 characters), this works
directly.  If it's less than 64 characters, use Triple-AES.  In
general, I assume that to use a key n times longer than the native key
length of the block cipher, you need to run it in 2n-1 mode; I'm
pretty sure this is so if the meet-in-the-middle attack is the only
one you have to worry about.  Append a 1 bit to the passphrase, then
fill to the next key boundary with zeroes as usual.

This takes O(mn) time, where n is the passphrase length and m is the
number of key bits you need.  I suspect any good solution will have
this property.  Still, you only have to keyschedule n times and things
should be pretty fast after that.

Any thoughts on the security or efficiency of this proposal?
-- 
  __
\/ o\ [EMAIL PROTECTED]   *NOTE NEW EMAIL ADDRESS* \ /
/\__/ Paul Crowley   http://www.cluefactory.org.uk/paul/ /~\




Re: FYI: Intelectual property discussion on AES

2000-07-14 Thread Paul Crowley

"Heyman, Michael" [EMAIL PROTECTED] writes:
   Mentioning Dan Bernstein, does anyone know the license that twofish
   will be under? I think Bernstein was one of the orginal authors.

The Twofish team was Bruce Schneier, John Kelsey, Doug Whiting, David
Wagner, Chris Hall, and Niels Ferguson.  Since then the team has grown 
to the "extended Twofish team", which includes Mike Stay and Tadayoshi
Kohno. Perhaps others, I forget...

 Twofish is a (the?) leading contestant for the Advanced Encryption
 Standard (AES) to be chosen by NIST.

There are five remaining candidates for the AES.  Twofish and Rijndael 
have always been explicitly free from any patent restrictions and
accompanied by liberally-licensed source code.  Serpent was at one
stage going to be patented, but the authors changed their minds and it 
is now unencumbered.  RC6 and Mars are patented and defended, but (as
with all AES entrants) the authors have signed a waiver granting the
world a royalty-free license in perpituity should their cipher be an
AES winner.  Recently NIST asked for, and received, a further waiver
that authors would license all of their patents for use with whichever 
cipher wins the AES.

Going by the summary of the feedback forms from the AES 3 conference
on NIST's web pages (as well as by the "buzz" at the conference
itself), the three unencumbered ciphers are the most popular on
technical grounds.  In fact, the final submission from the Twofish
authors argues that any of those three would make excellent winners;
FWIW I agree.  It's far from clear that Twofish is ahead of the other
two.

That the three best-regarded ciphers should be the unpatented ones
should be of interest to patent watchers.
-- 
  __
\/ o\ [EMAIL PROTECTED]   *NOTE NEW EMAIL ADDRESS* \ /
/\__/ Paul Crowley   http://www.cluefactory.org.uk/paul/ /~\




Re: Extracting Entropy?

2000-06-28 Thread Paul Crowley

John Kelsey [EMAIL PROTECTED] writes:
 If you don't mind the limitation of 1k of internal state, then
 Panama could be used directly; push in your salt and passphrase,
 padding to the edge of the block with one followed by zeroes, then
 do 32 blank pulls and start pulling out your key.

 A generalization of this idea is:
 
 S(K,len) is stream cipher output with key K and length of output len.
 hash(X) is hash function output of same size as K.
 
 Key = S(hash(passphrase),desired key length)

I don't think I see how this is a generalisation; what are you
identifying with "K" in my description?  It's not the output from
Panama after hashing the input; that's "Key" itself.  It can't be the
internal state before the blank pulls, that would make "hash(X)" a bad 
hash function, and I think if it were the internal state after the
blank pulls then that would make "S(K,len)" a bad stream cipher.  So
I'm not sure that using Panama directly fits the model you describe.

Of course, you could use Panama in the mode you describe, but I'm not
sure I see much advantage to that; you have to make K as long as
min(desired key length, passphrase length, internal state size) in
order not to waste entropy, and in any of these cases the second
hashing pass doesn't seem to do you much good; it just loses you half
a bit of entropy to collisions.

I've been trying to think about how you might use a primitive like
Panama in combination with real entropy sources to provide a
/dev/random type thing, but I've hit a problem in how to think about
it.  For some appropriate value of N based on the computational
resources of your attacker, you have to take in at least N bits of
entropy before generating a single bit of output, or fall foul of an
iterative guessing attack.  The problem I have is that once you've got
N bits of entropy, you really don't need any more!  You could merrily
ignore all the rest of the entropy at your disposal, and (if your
components are secure) your attacker will never be any better off than
they were when you first started producing output.

Given this, what theory can you use to determine if you're using those
subsequent bits of entropy appropriately?
-- 
  __
\/ o\ [EMAIL PROTECTED]   *NOTE NEW EMAIL ADDRESS* \ /
/\__/ Paul Crowley   http://www.cluefactory.org.uk/paul/ /~\




Re: Critics blast Windows 2000's quiet use of DES instead of 3DES

2000-05-19 Thread Paul Crowley

"L. Sassaman" [EMAIL PROTECTED] writes:
   Frankly, I can't understand why the IPsec protocol still allows DES.
  
  We are waiting for AES.
 
 So am I correct in assuming you are saying that DES will be disallowed as
 part of the IPsec protocol when AES is finalized?
 
 This would be good. I still think that DES should be dropped immediately,
 however.

I'm guessing that they have to have a MUST cipher, and they don't want
to change twice, so it makes sense to wait until September and then
make AES (or AES primary) the only MUST cipher.  
-- 
  __
\/ o\ [EMAIL PROTECTED]   *NOTE NEW EMAIL ADDRESS* \ /
/\__/ Paul Crowley   http://www.cluefactory.org.uk/paul/ /~\




Re: legal status of RC4

2000-01-27 Thread Paul Crowley

Vin McLellan [EMAIL PROTECTED] writes:
 I suspect that RSA did send out more than a few nastygrams to OEMs
 or other mass marketeers about "illicit use" of RC4, but -- at least in
 recent years -- its complaints probably went to commercial enterprises which
 both (a) sought to resell  the algorithm in the US, and (b) blatently used
 the RC4 label in a way that is likely to confuse many people as to the
 source of the RC4 implementation code.

Not so.  I know of a firm that paid hundreds of thousands of dollars
to RSADSI in order to use their own entirely original implementation
of RC4, under direct threat of a bogus copyright lawsuit.  They knew,
I think, that if RSADSI sued they'd lose, but they didn't fancy being
dragged into court.

This wasn't a crypto product, just an implementation of a standard
whose encryption option mandated RC4.  I doubt any mention of RC4
would have been made in either the advertising or the documentation.
-- 
  __
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley  http://www.hedonism.demon.co.uk/paul/ /~\



Re: Blue Spike and Digital Watermarking with Giovanni

2000-01-17 Thread Paul Crowley

Eugene Leitl [EMAIL PROTECTED] writes:

 Well, the deformations must be smooth, so this just describes an
 attack against a certain type of watermarks.

Yes.  They found that there was one watermarking product on the market 
that was not defeated by their standard mechanism, and developed a new 
mechanism that defeated that one too.

Of course, the state of the art in watermarking may have moved on
since that paper was written, but if anyone knows of a watermarking
product for images that has not already been defeated I'd be
interested to know.
-- 
  __
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley  http://www.hedonism.demon.co.uk/paul/ /~\



Re: Blue Spike and Digital Watermarking with Giovanni

2000-01-16 Thread Paul Crowley

As far as I know, all fielded watermarking schemes can be defeated
with simple, invisible distortions of the image - see

http://www.cl.cam.ac.uk/~fapp2/steganography/

for work done by Fabien Petitcolas and Ross Anderson.  You don't even
have to have more than one copy of the picture or know very much about
the scheme in use.
-- 
  __
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley  http://www.hedonism.demon.co.uk/paul/ /~\



Re: linux-ipsec: Intel IPSEC accelerator gives 3DES protected 100Mbit Ethernet

1999-09-16 Thread Paul Crowley

"William H. Geiger III" [EMAIL PROTECTED] writes:
 IMHO hardware based crypto is dangerous especially from a company like
 Intel that will not allow it's designs to be peer reviewed. Their entire
 attitude is "trust us we are Intel". Well  sorry I don't. Intel's RNG and
 now it's IPSEC accelerator are to ripe of a target for TLA's to trust
 without complete, open, peer review. Until this happens, IMHO, it is as
 trustworthy as CAPI.
 
 [MODERATOR's NOTE: I'm sorry, but I find this totally wrongheaded. A
 3DES ethernet card need not be "trusted" -- if the thing interoperates
 with other IPSec implementations, its correct, pure and
 simple. Indeed, the slightest flaw and it would not
 interoperate. Perhaps they could rig it to leak too much in the RF
 spectrum, but they could do that with the rest of the chipset, too,
 and you are using *that*.

If the thing has an RNG on board for any reason, that might not be
trusted, but I guess in practice it'll only use keys provided from
outside the card.  I suppose you could rig it to return the secret key 
in response to some secret "backdoor packet", but you'd be utterly
destroyed if you were caught, and you might well be caught.  It's not
as easy as introducing an "accidental" flaw in an RNG.

But if PCK has looked at their RNGs and thinks they're good then I
suspect they are.  I agree this is most likely a non-issue, I'm just
wondering what the theoretical possibilities are.
-- 
  __
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley  http://www.hedonism.demon.co.uk/paul/ /~\