Cryptography-Digest Digest #397, Volume #10 Mon, 11 Oct 99 22:13:02 EDT
Contents:
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Mok-Kong
Shen)
Re: Block encryption with variable keys (Mok-Kong Shen)
Re: classifying algorithms ("Joseph Ashwood")
Job Openings - Counterpane Systems - Network security (not cryptography) (Bruce
Schneier)
Re: Simple hash function? ([EMAIL PROTECTED])
where to put the trust (Tom St Denis)
Re: RSA-512: Weizmann Institute: London Times (ca314159)
Re: Public Key crack without factorising (Kayo Limner)
Re: Layperson Q: how long to crack 32-bit RSA? ("Steven Alexander")
Re: DES and RSA lifes ("Steven Alexander")
Re: Is 128 bits safe in the (far) future? (DigitAl56K)
Re: Simple hash function? (Tom)
Re: There could be *some* truth to it (Dan Day)
Re: Simple hash function? (Scott Nelson)
Re: Simple hash function? (Dan Day)
Re: Layperson Q: how long to crack 32-bit RSA? (Steve Roberts)
Re: Simple hash function? (Scott Nelson)
Re: where to put the trust ("Adam Durana")
Re: Simple hash function? (Bruce Schneier)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 11 Oct 1999 22:19:41 +0200
Sundial Services wrote:
>
> Mok-Kong Shen wrote:
> >
> > I want to highlight a tiny point which is certainly implicitly also
> > contained in your paper: Even for a fixed set of n algorithms
> > there are n! ways of combination to build a compound cipher. This
> > combinatorial explosion alone is an effective defense against
> > analysis.
> >
>
> The essential point that Bruce mentions is that, if you build an
> immensely strong bank-vault door to your home, but beside it is an open
> window ... then your home is -worse- than insecure. It's wide open but
> you THINK it's safe -- you ASSUME it's safe.
>
> When I look at the crypto algorithms that come out today, it seems to me
> that for all practical civilian purposes all of them are quite strong
> enough, and have been for some time. True, someone -might- come against
> them with all the arsenal that Wile E. Coyote sometimes arrayed against
> the Roadrunner (a few good Dr. Seuss comics also come to mind) ... but
> everyone else is going to look for some way to go -around- that
> impregnable doorway, not through it.
>
> The key, or the key-scheduling algorithm, is an obvious choice. While
> algorithms cannot be broken using brute-force, perhaps the key can...
> there is usually a "phrase you can easily remember" and so on. The list
> of ingenious methods people can use is just as big as the list of
> ingenious methods other people use to try to protect things.
>
> Strategies like choosing from among 'n' different cipher algorithms,
> mixing them up in various ways or applying several of them in various
> ways ... will layer more sheets of bulletproof iron on top of the door
> we already have. It will not eliminate that open window if it exists.
>
> I've found that, the more clever you think you are in creating the
> protection scheme you put in place -- the more easily you can overlook
> "another, obvious-now-that-I-see-it" possibility for going completely
> around it.
What do you have against e.g. multiple encrpytion with the top three
algorithms of the final round of AES instead of with the winner
of AES alone?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Block encryption with variable keys
Date: Mon, 11 Oct 1999 22:20:21 +0200
Bruce Schneier wrote:
>
> On Wed, 06 Oct 1999 23:51:10 +0200, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
>
> >I have on many occasions in the past advocated what I term the
> >principle of variability in cryptology and have employed it in
> >the design of a couple of humble encryption algorithms of my own.
> >As also mentioned in a recent discussion thread on Terry Ritter's
> >paper, multiple encryption with changing ciphers and parametrized
> >ciphers can all be subsumed by this very general principle.
> >
> >With that viewpoint I like to put up a couple of (maybe unintelligent)
> >questions:
> >
> >Why does DES (and similar block ciphers) keep the key constant
> >and not varying from block to block? Would sophisticated attacks
> >like differential analysis still function when the key is
> >non-constant?
>
> NIST wanted a block cipher, and this is one of the characteristics of
> a block cipher. The kind of thing you describe is more like a stream
> cipher (you can think of RC4 as a 8-bit block cipher with a key that
> changes with ever block; you can think of WAKE similarly).
>
> I can't really tell you why NIST wanted a block cipher over a stream
> cipher. I believe it was because DES is a block cipher, and they
> didn't want the new standard to be too different. I argued that we
> would be better served with a stream cipher.
>
> I also believe that it is possible to get better performance with a
> stream cipher than with a block cipher.
There are a couple of counter-arguments: (a) It is of not much
practical value to impose sharp terminogical difference between
stream and block cipher, there is no reason from the outset why
a mixture couldn't function better. (b) What I proposed in my post
isn't changing DES in any way, but a new mode of operation similar
to CBC, the difference only being that this mode is not included in
the official document and happens to deal with differential
analysis and the like well.
>
> >I can see at least two straightforward means of modifying the
> >key. One is modification similar in principle to CBC and other
> >chainings. The other is letting a PRNG supply the key for each
> >block (the PRNG thus drives the block encryption). Certainly
> >there is much scope of variations or introducing additiional
> >complexities.
>
> There are many ways to modify the internal state of a block cipher to
> vary the key with every block. We looked at some of these for
> Twofish, although we have nothing developed enough to release. We
> should probably get back to work on a steam-cipher variant for
> Twofish, if for no other reason than to use the name "Fresh Water
> Twofish."
As already said, my proposal of a new mode of operation doesn't
change the DES proper as such, hence it doesn't raise the question
of whether the modification leads to weakness of the DES proper
which has reputedly stood up well against all kinds of scrutiny by
the best of the profession. That's a big practical (though perhaps
not theoretical) advantage. I mentioned also that the winner of
AES can similarly also be operated in that mode.
M. K. Shen
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: classifying algorithms
Date: Mon, 11 Oct 1999 14:09:19 -0700
My own (potentially) pitiful attempt.
About Stream vs Block Ciphers.
I have always found that the most conventiant way of thinking of the
difference is that a block cipher is expressed as:
f(k,d), where k is a key, and d the current block of data to be enciphered.
where a stream cipher is a function as:
f(k,d,p), where k and d are as before, but p is the prior data that has been
through the cipher
I've only seen one potential reason to think otherwise, and that's the
observation that if the "stream" cipher simply ignores p it is effectively a
block cipher. Now whether this is the case or that there should be an
additional restraint that the stream function can not ignore the prior input
is open for debate.
Joe
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Job Openings - Counterpane Systems - Network security (not cryptography)
Date: Mon, 11 Oct 1999 22:01:57 GMT
Counterpane Internet Security is looking for software developers to
create a system that manages Internet security services for people and
businesses. Founded by cryptography expert Bruce Schneier, we are a
pre-IPO startup, and all employees will participate in the equity
plan. We need people with a number of skills, including:
UI Architects and developers: The UI team will build software to
manage and display network security status. An ideal candidate is
skilled with C, C++, and Java under Win32. Experience with setting up
and extending customer relations systems (Apropos, Aspect, Remedy,
Clarify, etc.) is a plus. Skill with MFC and creating OCX and ActiveX
controls is needed.
Communications engineers: An ideal candidate will have knowledge of
TCP/IP, PPP and modems, IPsec, TLS/SSL, SSH, design and construction
of communications protocols and APIs on Windows32 and Unix.
Remote sensing engineers: The remote sensing team will analyze network
and security information from a variety of sources for anomalous
behavior. An ideal candidate has experience with one or more IDS
(ISS, Centrax, NFR, Tripwire, etc.) and/or firewall products
(Checkpoint, Cisco, Gauntlet, etc.) as well as system administration
and network administration experience. It is a plus to have knowledge
of SNMP, and updates and distribution of virus packages. Programming
will be on Windows32 and Unix.
Repository engineers: An ideal candidate has experience with
configuring, maintaining, and using database systems, Oracle, SQL,
ODBC, JDBC, report generation, and web programming.
All positions are in Counterpane's San Jose, California office, near
Winchester Avenue and I280.
Please send resumes and inquiries to <[EMAIL PROTECTED]>.
Thanks,
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Simple hash function?
Date: 11 Oct 1999 22:47:57 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tom)
wrote:
> I'm looking for a simple one way hash function, to
> use as a non-error-correcting checksum for binary
> data, and possibly to convert an ASCII passphrase
> into a binary key. (Something much simpler than
> MD5, SHA, etc.)
>
> I guess this could be called a "mostly one way"
> function.
WAKE has a fast hash function mode. See:
ftp://ftp.cl.cam.ac.uk/users/djw3/wake.ps
or:
http://www.cix.co.uk/~klockstone/wake.pdf
This and its plaintext avalanche mode seem to have been missed by most
commentators...
Keith
http://www.cix.co.uk/~klockstone
------------------------
'Unwise a grave for Arthur'
-- The Black Book of Carmarthen
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: where to put the trust
Date: Mon, 11 Oct 1999 23:01:32 GMT
I have been getting alot of flak about 'how do you KNOW that 'place cipher
here' is actually this strong'. I admit there is no honest PROOF to it. No
cipher is unconditionally strong, none, zippo, zilch. If you use an OTP
wrong it can become weak. (Yes even the infamous Scottu19 has not been
proven to be strong).
So what do we do?
Well we trust experts.
Let's take a survey... If you do any of the follwing post a short reply...
drive a car, goto the doctors, eat fast-food, use a computer, drive on
bridges, live in an apartment, work in an office, gone to school ...
You have probably relied on an experience expert. Do we trust them? Hell
yes. Do they do good jobs? 99.99% of the time yes.
So does this apply to cryptography? Yes I think so.
So although (for example) Twofish has not been proven to be strong, it has
been designed by people in the know, and I would trust it, just like I trust
my doctor to give a good evaluation of my health.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: ca314159 <[EMAIL PROTECTED]>
Subject: Re: RSA-512: Weizmann Institute: London Times
Date: Mon, 11 Oct 1999 23:19:01 GMT
Tim Tyler wrote:
> A 512-bit modulus would take 6 to 7 times as long for the sieving and
> 2 to 3 times the size of the factor bases as RSA-140. The size of the
> matrix to be solved grows correspondingly, and the time to solve it
> grows by a factor of about 8. Thus, 15 to 20 devices could do the
> sieving in about 5-6 weeks. Doubling the number will cut sieving time
> in half. The matrix would take another 4 weeks and about 2 Gbytes of
> memory to solve. The total time would be 9-10 weeks.''
The London times article J. Savard mentions:
http://www.sunday-times.co.uk/news/pages/tim/99/09/29/timintint02001.html?1341861
referred to a device which we didn't immediately identify with Twinkle.
There was some question as to whether the device mentioned there was a
newer variant.
Later it became evident that the article was completely misleading.
Conspiracy, or just very very bad journalism ? The motive of EIQC
seems commerical.
Buyer beware, information is becoming money.
--
http://www.bestweb.net/~ca314159/
------------------------------
From: [EMAIL PROTECTED] (Kayo Limner)
Crossposted-To: alt.anonymous,alt.privacy
Subject: Re: Public Key crack without factorising
Date: Mon, 11 Oct 1999 23:03:04 GMT
On alt.privacy and alt.anonymous, "mj" <[EMAIL PROTECTED]> wrote:
>Seeing the description of how Public key based ciphers may be
>cracked without having to resort to finding factors of large
>primes (http://viawg.freeshell.org - not that I fully understand
>what is being described - but reads to me that Public Key based
>methods are easily hacked without using factorising) am I only attracting
>attention to myself in using the likes of PGP?
Do you folks on sci.crypt know anything about this?
--
"Kayo Limner" better known as [EMAIL PROTECTED]
0123 456789 <- Use this key to decode my email address.
Fun & Free - http://www.5X5poker.com/
------------------------------
From: "Steven Alexander" <[EMAIL PROTECTED]>
Subject: Re: Layperson Q: how long to crack 32-bit RSA?
Date: Mon, 11 Oct 1999 16:08:40 -0700
With only 32-bit RSA, no special factoring algorithms would be needed.
Simple trial division could quickly return the factors of the number. Also,
no special libraries would be needed to accomodate large integers as is used
in other implementations of RSA.
-steven
------------------------------
From: "Steven Alexander" <[EMAIL PROTECTED]>
Subject: Re: DES and RSA lifes
Date: Mon, 11 Oct 1999 16:25:03 -0700
How long a key is valid depends on who you need protection from.
If you're planning to smuggle nuclear weapons from Kazakhstan into the US
and use DES to protect your communication, the NSA could probably read your
messages in close to real time(negligible decryption time).
If however, you're trying to prevent people from reading credit card numbers
transmitted for online purchases, the keys will have a fair lifespan before
it is economical to put together the resources to break the key. EFF put
together a capable machine for about $200k, using their plans someone else
could probably do it for half that price. Even so, $100k is far beyond
worthwhile to recover credit card numbers and a distributed attack would be
hard to launch without detection.
The difficult of breaking 56-bit DES is to my knowledge not *much* different
than 512-bit RSA. Both have been done using distributed attacks in just a
few months. Take note that a legal distributed attack(contests put on by
RSA) are more feasible than illegal attacks(finding CC numbers) because not
many people will knowingly participate(because it's illegal). A more
efficient distributed attack could be launched using worms/viruses but they
would have to contact a host computer(the attacker's) and could foil their
plans were the virus detected before the key was broken.
-steven
Sebastien LUCAS <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> How long is a RSA key valid?
> How lon is a DES key valid?
>
>
> LucasArt
>
------------------------------
From: [EMAIL PROTECTED] (DigitAl56K)
Crossposted-To: comp.security.pgp.discuss,alt.security.pgp
Subject: Re: Is 128 bits safe in the (far) future?
Date: Mon, 11 Oct 1999 23:35:53 GMT
Why can't someone make a variable bit-size version of CAST using a
32-bit unsigned int?
Also variable length keys allowing any key length desired. Then anyone
scepitcal about the security of their encryption could have keys as
big as they liked. Sure as current limits go it would be pointless but
why should the algorithms be restricted?
-==-==-==-==-==-==-==-==-==-==-==-==-==-==-
Visit the DigitAl56K Website
http://www.digital56k.free-online.co.uk
Get AVDisk v3 for F-Prot (Software section)
-==-==-==-==-==-==-==-==-==-==-==-==-==-==-
------------------------------
From: [EMAIL PROTECTED] (Tom)
Subject: Re: Simple hash function?
Date: Tue, 12 Oct 1999 02:53:45 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 11 Oct 1999 22:08:30 GMT,
[EMAIL PROTECTED] (Bruce Schneier) wrote:
>On Tue, 12 Oct 1999 00:49:56 GMT, [EMAIL PROTECTED] (Tom) wrote:
>
>>I'm looking for a simple one way hash function, to
>>use as a non-error-correcting checksum for binary
>>data, and possibly to convert an ASCII passphrase
>>into a binary key. (Something much simpler than
>>MD5, SHA, etc.)
>>
>>I guess this could be called a "mostly one way"
>>function.
>
>X^3 mod n.
>
>Is that simple enough?
Absolutely perfect! Thanks
>**********************************************************************
>Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
>101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
> Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: There could be *some* truth to it
Date: Mon, 11 Oct 1999 23:52:03 GMT
On Sun, 10 Oct 1999 17:23:21 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>AFAICS, /one/ problem with your original post is that it said that QCs
>would be able to factor keys of _unlimited_ size.
>
>It seems likely that QCs will be limited by decoherence effects to
>computations withing a certain "spatio-temporal cube".
>
>They will not be able to handle an unlimited number of bits nor
>compute an arbitrarily long sequence of operations.
Well, sure -- that's why I pointed out that there's probably going
to be a wide gap between theory and practice.
>These factors are /very/ likely to place limitations on their utility for
>breaking public key cryptography.
One can only hope...
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Simple hash function?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 12 Oct 1999 00:09:31 GMT
On Mon, 11 Oct 1999 22:08:30 GMT, [EMAIL PROTECTED] (Bruce
Schneier) wrote:
>On Tue, 12 Oct 1999 00:49:56 GMT, [EMAIL PROTECTED] (Tom) wrote:
>
>>I'm looking for a simple one way hash function, to
>>use as a non-error-correcting checksum for binary
>>data, and possibly to convert an ASCII passphrase
>>into a binary key. (Something much simpler than
>>MD5, SHA, etc.)
>>
>>I guess this could be called a "mostly one way"
>>function.
>
>X^3 mod n.
>
Isn't that a reversible function if you know
the factors of N?
Perhaps I missed something, did the original poster
want a hash function, not a one-way hash?
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: Simple hash function?
Date: Tue, 12 Oct 1999 00:02:54 GMT
On Tue, 12 Oct 1999 00:49:56 GMT, [EMAIL PROTECTED] (Tom) wrote:
>I'm looking for a simple one way hash function, to
>use as a non-error-correcting checksum for binary
>data, and possibly to convert an ASCII passphrase
>into a binary key. (Something much simpler than
>MD5, SHA, etc.)
>
>I guess this could be called a "mostly one way"
>function.
It hard to tell if you have any other constraints that
might make the following suggestion inapplicable, but
for just the properties you're describing, I'd probably
use a simple CRC-32 (assuming that 32 bits is big enough
for your post-hash binary key).
CRC-32 makes a nice "non-error-correcting checksum for
binary data" (in fact, this is its primary application),
and the code to implement it is simple and fast, and can
be applied to an arbitrarily large set of binary data
without difficulty.
If you need more than 32 bits for your "binary key", you
might be able to get away with hashing the odd bytes of
your data into one CRC-32, and the even bytes into another,
giving you a 64-bit result, or generalizing that technique
so that every Nth byte gets "CRC'ed" separately, leaving
you with an N*32-bit result.
Again, however, whether this would be appropriate depends
entirely upon what other requirements you may have for
the resulting data.
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: [EMAIL PROTECTED] (Steve Roberts)
Subject: Re: Layperson Q: how long to crack 32-bit RSA?
Date: Tue, 12 Oct 1999 00:36:57 GMT
"Steven Alexander" <[EMAIL PROTECTED]> wrote:
>With only 32-bit RSA, no special factoring algorithms would be needed.
>Simple trial division could quickly return the factors of the number. Also,
>no special libraries would be needed to accomodate large integers as is used
>in other implementations of RSA.
>
>-steven
>
>
He might have been thinking of 32-bit RC4 or some other algorithm that
is sold by the RSA *company*, not the N=PQ sort of RSA.
32-bit N=PQ you could almost solve in your head....
Steve Roberts <www.steveroberts.com.au>
Witham Pty Ltd
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Simple hash function?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 12 Oct 1999 00:21:19 GMT
On Tue, 12 Oct 1999 00:02:54 GMT, [EMAIL PROTECTED] (Dan Day) wrote:
[snip]
>
>CRC-32 makes a nice "non-error-correcting checksum for
>binary data" (in fact, this is its primary application),
>and the code to implement it is simple and fast, and can
>be applied to an arbitrarily large set of binary data
>without difficulty.
>
>If you need more than 32 bits for your "binary key", you
>might be able to get away with hashing the odd bytes of
>your data into one CRC-32, and the even bytes into another,
>giving you a 64-bit result, or generalizing that technique
>so that every Nth byte gets "CRC'ed" separately, leaving
>you with an N*32-bit result.
>
A Cyclic Redundancy Check can be made any size you want.
It isn't even necessary to find a primitive polynomial
for it. They are, however, quite reversible. If you
wanted to use the checksum to guard against malicious code
tampering, then CRC is definitely not the way to go.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: where to put the trust
Date: Mon, 11 Oct 1999 20:39:20 -0400
It is silly to blindly believe an expert. Comparing doctors to 'the
experts' is a bad comparison at best. Doctors provide you with proof and
explainations for thier diaginosis. People who publish algorithms provide
the details to them, and reasons they believe it to be secure. But there
are so many possiblities in this field. Also authors of algorithms are not
required to be truthful with you like Doctors are. Doctors provide you with
information which has been proven by the test of time in most cases. Many
algorithms use new ideas and methods which have been around for a while and
are considered secure. So its foolish to just believe someone because of
thier reputation.
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: Simple hash function?
Date: Tue, 12 Oct 1999 00:33:53 GMT
On Tue, 12 Oct 1999 02:53:45 GMT, [EMAIL PROTECTED] (Tom) wrote:
>On Mon, 11 Oct 1999 22:08:30 GMT,
>[EMAIL PROTECTED] (Bruce Schneier) wrote:
>
>>On Tue, 12 Oct 1999 00:49:56 GMT, [EMAIL PROTECTED] (Tom) wrote:
>>
>>>I'm looking for a simple one way hash function, to
>>>use as a non-error-correcting checksum for binary
>>>data, and possibly to convert an ASCII passphrase
>>>into a binary key. (Something much simpler than
>>>MD5, SHA, etc.)
>>>
>>>I guess this could be called a "mostly one way"
>>>function.
>>
>>X^3 mod n.
>>
>>Is that simple enough?
>
>Absolutely perfect! Thanks
Rememeber that n should be the product of two large secret primes,
like an RSA modulus.
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
