Cryptography-Digest Digest #691, Volume #9 Thu, 10 Jun 99 20:13:02 EDT
Contents:
cant have your cake and eat it too (Greg Bartels)
Re: Cracking DES (smoke_em)
Re: RSA patent question ("Roger Schlafly")
Re: Algorithms ("John E. Kuslich")
Re: ATTN: Bruce Schneier - Street Performer Protocol ("John E. Kuslich")
Re: being burnt by the NSA (kurt wismer)
Re: DES (kurt wismer)
Re: IDEA-128 (Casey Sybrandy)
Re: Does scott19u.zip make full use of it's large key size ? ([EMAIL PROTECTED])
Re: Shared secret protocol (David A Molnar)
----------------------------------------------------------------------------
From: Greg Bartels <[EMAIL PROTECTED]>
Subject: cant have your cake and eat it too
Date: Thu, 10 Jun 1999 17:14:15 -0400
hey, wait a minute, I was asking why not use a different
key for every stage of DES, and the response was
1) its only nominally better and
2) the size of the key is too big to generate from a pass phrase.
but, given a secure algorithm, the weakest link becomes
the size of the key. which says to me, current cracking
capabilities require keys bigger than you can generate
with a "human-memorizable-pass-phrase".
so you cant have small keys and secure data too.
it seems whats needed is a new approach to how keys
are entered into an encryption system.
rather than having a human type a phrase which
gets hashed into a key.
something like a cross between a
palm pilot, an iButton, and a USB port.
the iButton stores the big key.
it is accessable via the palm pilot,
which has a user enterable password,
which encrypts the data to/from ibutton,
and the USB port uploads it to the "real"
computer where the key is used in the applicatoin.
why is it that people carry keys to a car worth as
little as a thousand bucks, but we dont carry
a physical key (dongle) for encrypting computer/voice/etc
data, which can be worth much, much more?
Greg
------------------------------
From: smoke_em <[EMAIL PROTECTED]>
Subject: Re: Cracking DES
Date: Fri, 11 Jun 1999 00:33:14 +0200
fungus wrote:
> This has always been the case, this book has just put a definite
> price on the machine. That price is $250,000 for the entire research
> and development of a machine which cracked last years DES challenge
> in 56 hours.
I believe there are links to that on www.distributed.net and
www.eff.org. Don't remember when the next contest is, and since that
demonstation of search-rate, personally i do not want to participate in
the distributed.net efforts any longer.
They (eff) can have it solved a lot faster, partly because there is such
a long delay in getting the distributed effort around to bear down on
it, though the combined power (easily) whacks that machine.
The last contest (18th jan) was done in 22 hours in combined work of the
EFF (same machine as the july 17-98 crack) and distributed.net.
NO doubt some bodies in the world have more funding at their disposal
and/or more sophisticated hardware.
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: RSA patent question
Date: Thu, 10 Jun 1999 14:28:47 -0700
R. Joosten wrote in message
<[EMAIL PROTECTED]>...
>Over lunch someone mentioned the following case.
>
>Suppose you are in Europe, and you want to access a US-based database over
>the internet. The database owner supplies you with an RSA key, and sends
you
>database items that are RSA encrypted, and which you could then decrypt
>using the aforementioned key. You can then apparently be sued for patent
>(yes, patent) infringement. It was said that a case like this was brought
to
>court only very recently.
There is no RSA patent in Europe. You can use RSA all you want in Europe,
and you won't infringe any patent. The US-based database owner may or may
not be subject to patent restrictions, but if he lawfully sends you a key in
Europe,
you can do whatever you want with it.
I don't know what case you are referring to, but I suspect you left out some
details. The RSA patent holder sued Baltimore Technologies, a European
company, but it was only for operations in the US, and the suit was dropped
anyway.
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Algorithms
Date: Thu, 10 Jun 1999 15:25:10 -0700
I know but...Al - Gore - Rhythm... Can you dance to an Al - Gore -
Rhythm...
Sound of a rim shot (ka - shish! boom!)
JK
:--))
Doug Stell wrote:
> On Wed, 09 Jun 1999 15:43:15 -0700, "John E. Kuslich" <[EMAIL PROTECTED]>
> wrote:
>
> >Ok, What the heck does AL Gore have to do with crypto???
> >
> >Let's keep this group free from annoying posts about politics. Who the
> >heck cares about Al Gore isms any way
>
> Al Gore chairs the U.S. committee on export regulations and policy
> w.r.t. crypto. (I know people who represent industry on that
> committee.) Al Gore is also very much apart of the Wassenaar
> Agreement. Therefore, he has a lot to do with crypto, especially in
> setting the U.S. Administration's policy on crypto. Everyone in the
> U.S. and the commercial side of crypto cares a lot about export
> regulations.
>
> Now you know.
--
CRAK Software (Password Recovery Software)
Http://www.crak.com
[EMAIL PROTECTED]
602 863 9274 or 1 800 505 2725 In the USA
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: ATTN: Bruce Schneier - Street Performer Protocol
Date: Thu, 10 Jun 1999 15:34:59 -0700
Get a life man!!!
I thought the paper was EXTREMELY thought provoking and as a matter of fact I am
presently wrestling with
just such a real life issue.
Copyrights are essentially unenforcible these days. Something will have to be done or
authors will no
longer put forth the work required to publish. We will all suffer when that happens.
I have some very interesting information on Office 97 that I would just love to
publish but I feel that
there should be some reward for my effort other than just seeing my name in lights.
Bruce, you just write what you want and let the "Anonymous" bozo, who obviously
doesn't know who
impregnated his mother, babble in the wind...
JK
Anonymous wrote:
> Bruce,
> I cannot believe you would put your name to such an outlandish proposal! If you
>wanted to
> float a trial balloon you could have done so under a pseudonym. The proposal on the
>website
> I just saw is INCREDIBLY NAIVE on your part. The fact that *you* - a well-respected
>(cough)
> authority in the field of data protection - came out and publically uttered these
>ideas vis-a-vis
> copyright protections will only lend more ammunition to those that seek to somehow
>suppress
> the free flow of information over the Internet. I cannot *believe* you would do
>something so foolish!
>
> You mentioned specifically "Motion Picture Houses". Good God, man! I'm having
>trouble typing
> here; please bear with me. Your failure to even come *close* to what any studio
>would refer to
> itself as, nevermind the entire Motion Picture Industry or Hollywood Film Studios,
>as they are
> *commonly* referred to by even the most casual observer - you distance yourself from
>any
> base of opinion that would even be considered "reasonable". Motion Picture House.
>Sheesh.
>
> Your argument should have encompassed the *entire* range of intellectual property as
>we
> know it today. Go ahead, why limit yourself to the movies? Or TV?
>
> Are you aware of the battle going on over MP3s in the music business today? What
>about
> that? What about all those MP3s, Bruce? The whole music industry isn't about to
>lie down
> and play dead, you know? Compare their earnings to TV and film - how naive can you
>possibly
> be?
>
> Bruce, you've lost any credibility you had. You come right out in the piece and say
>you
> will address the technical and economic issues. Then you add in the "social" issues
>for
> good measure. OK, chief. This is why we techies get a bad name in business circles.
> If you believe *any* of your proposal for the "Street Performer Protocol" has a
>chance in
> hell - look at the numbers, Bruce, look at the money, I implore you.
>
> Eh, good luck. You're a great crypto guy, but you're not on my list anymore of
> influential people up-and-coming in the 21st Century.
>
> Best Regards,
> JB
--
CRAK Software (Password Recovery Software)
Http://www.crak.com
[EMAIL PROTECTED]
602 863 9274 or 1 800 505 2725 In the USA
------------------------------
From: kurt wismer <[EMAIL PROTECTED]>
Subject: Re: being burnt by the NSA
Date: Thu, 10 Jun 1999 23:45:04 GMT
[EMAIL PROTECTED] wrote:
>
> > You also neglected to mention SHA-1, which is an NSA product and is
> > widely respected and trusted in the open-literature community.
>
> This is true. I am sorry Mr. NSA. I live in Canada what have they
> done for *me* lately? :) (Well in canada we have our Ceciss or
> something like that. Basically they are the unknown secret agents in
> Canada. Woowee!).
actually it's CSIS... not very secret, they had a booth at a job fair i
attended last month... they're also listed in the phone book...
--
"sometimes i cannot take this place
sometimes it's my life i can't taste
sometimes i cannot feel my face
you'll never see me fall from grace"
------------------------------
From: kurt wismer <[EMAIL PROTECTED]>
Subject: Re: DES
Date: Thu, 10 Jun 1999 23:10:20 GMT
[EMAIL PROTECTED] wrote:
>
> > Key-dependent S-boxes _are_ stronger, in general.
>
> No they are not. Large random sboxes are strong, small ones are not.
> It has been proven that random sboxes in DES is no stronger (in fact I
> think Biham proved they are weaker) then the fixed ones.
i think you missed the part where he said "in general"... something can
be true "in general" and still have exceptions...
--
"sometimes i cannot take this place
sometimes it's my life i can't taste
sometimes i cannot feel my face
you'll never see me fall from grace"
------------------------------
From: Casey Sybrandy <[EMAIL PROTECTED]>
Subject: Re: IDEA-128
Date: Thu, 10 Jun 1999 19:16:45 -0400
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> Casey Sybrandy <[EMAIL PROTECTED]> wrote:
>
> > b0 = rotr(b0, r[j++])
> > b1 += k[i++]
> > b2 += k[i++]
> > b3 = rotr(b3, r[j++])
>
> Bad idea, only two blocks are permutated and the others are just
> manipulated. I.e there are only 2^5 or 32 possible modifications of b0
> and b3 in the input, but 2^32 possible modifications of b1 and b2.
>
> > temp1 = b0 XOR b2
> > temp2 = b1 XOR b3
> > // these lines added in an attempt to add more security
> > temp1 = rotl(temp1, r[j++])
> > temp2 = rotr(temp2, r[j++])
> > temp1 *= k[i++]
These multiplications are done modulo 32, for those who asked. They do not
have to be reversible at all.
>
> > temp2 += temp1
> > temp2 *= k[i++]
> > temp1 += temp2
>
> So temp1/temp2 form the F function? The rotation is a good idea but
> will have bad differential chars. The rotation is not dependant on the
> input data, so it's pretty much a fixed permutation.
>
Hmm, I thought that a keyed rotate would be enough here. Where do you think
I should get the rotate values from? Perhaps combine the rotate key with 5
bits of one of the input blocks?
>
> > b0 = b0 XOR temp2
> > b1 = b1 XOR temp1
> > b2 = b2 XOR temp2
> > b3 = b3 XOR temp1
>
> Not a good idea, this means that b0 xor b2 = temp2 and b1 xor b3 =
> temp1.
I copied this directly from the original IDEA and it is apparently secure
there. I tried to change it to additions, but it wouldn't decrypt then.
>
>
> > swap(b1, b2)
> > b0 = rotr(b0, r[j++])
> > b1 += k[i++]
> > b2 += k[i++]
> > b3 = rotr(b3, r[j++])
> > }
>
> Same as above, you could at least swap the permutations so b0/b3 are
> added and b1/b2 rotated.
>
Good idea, I'll change that.
>
> >
> > That's it. Decryption is done similarly to normal IDEA, you just have
> > to take into account the different operations. The reasoning behind
> > this is simple: the reversible multiplications of IDEA, where all
> > multiplication was done mod 2^16 + 1, had to be replaced with
> something
> > more reversible.
>
> But multiplication in GF(2^32) is not reversible!!! Unless you have the
> upper 64 bits. In IDEA the multiplication opertor itself is
> invertible.
>
Only the multiplications that have been replaced by the rotates need to be
reversible. The multiplications performed on temp1 and temp2 do not have to
be. I double, triple, .. checked this. I managed to make this work before
I posted it, so it will decrypt.
>
> > I selected the keyed rotate function because it has
> > been proven to work well with multiplications and it is simple.
>
> The only reason the rotation is required is because the high bits do
> not effect the multiplication much at all. I would however use a data
> dependant rotation (say of the upper 5 bits of the result). If you
> want a better multiplication/mixer function look at the quadratic of
> RC6.
>
O.K., I can improve those rotates. I just wanted to keep it simple. What
do you think of this (on the fly thinking): what if I use the upper 5 bits
of b0 to rotate b1, for example? This of course would be similarly applied
other rotates.
>
> > Since
> > it now takes only one clock cycle on newer CPU's, I added in two extra
> > rotates per round in an attempt to make it stronger.
>
> Rotates take more then one cycle. That code would compile to something
> like
>
> MOV CL,[ESI+n]
> ROL EAX,CL
>
> Which could pair with the other, however the ROL's work in the u-pipe
> only. So they do not pair. I.e 2 cycles per rotate.
>
Oh, I thought they were down to one clock cycle now. Sorry, bad info.
They're still cheaper than multiplies.
>
> > I have
> > successfully coded this up and it does encrypt and decrypt. I
> > personally recommend 8 rounds, since that is what IDEA used and it was
> > secure after 5 rounds, if I remember correctly. Since it is now
> faster
> > than normal IDEA, the number of rounds can probably be expanded
> somewhat
> > without making it slower than normal IDEA.
>
> Bad idea to assume yours=IDEA. I would work on proving the difficulty
> of solving it alone, and without reference to other ciphers as much.
>
Well, it was just a guess. This is why I posted it, I wasn't sure how much
the rotates would decrease security. I recommended the rounds on the basis
that IDEA was secure after 4, just found my AC book, I never said it was as
secure as IDEA. I was merely using it as a reference point.
>
> >
> > Anyway, this is just an idea, no pun intended, that I came up with
> after
> > reading a post about doing something like this. The post ended up
> > showing us a complicated solution. I personally opted for the simple
> > one. I didn't bother making a key schedule for it, though it should
> be
> > simple enough. I recommend a key schedule that does a good job of
> > propogating change, such as that of RC5/6. The key values for the
> > rotates should be mod 32 (each block is only 32-bits.) Let me know
> what
> > you think. Also, if anybody knows anything about the patent info on
> > IDEA, that would be great. I plan on incorporating this in another
> > project of mine, unless it is proven that this is as insecure as morse
> > code.
>
> Well sorry but it doesn't look that good. I pointed out some things,
> but here is more. The multiplication runs in one direction only, this
> means no matter how much rotating you perform there is some set of weak
> bits in each round. I don't know how to exploit this myself, but it
> probably could be done. The fact that b0/b3 are not permutated
> properly is bad as well. The keyed rotation could help linear
> analysis, however I think some chars can be found (such as with the
> parity bit and the lsb). This is because multiplication in the GF
> (2^32) (32bit result) is not bijective, which means not all outputs are
> possible (take for example the LSB which is 0 75% of the time).
>
> BTW do you know why IDEA uses multiplication? I think you should look
> at it a little more first. The cipher is not that bad, but needs some
> work arounds to become secure.
>
I do know that multiplication does have good properties, but I haven't seen
anything state why yet.
Anyway, thanks for the criticism.
>
> Tom
> --
> PGP public keys. SPARE key is for daily work, WORK key is for
> published work. The spare is at
> 'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
> 'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Does scott19u.zip make full use of it's large key size ?
Date: Thu, 10 Jun 1999 21:52:36 GMT
In article <7jp3f5$213m$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> Then don't use scott19u in samrtcards. But I plan
> on using it in my PC.
BTW have you ever stopped to think the large sbox kills the cache? It
will almost certainly run slower then anything else (Blowfish/Rc5 for
example) on pentium cpus.
> What are you talking about? Can you show any real examples
> of this occurring?
It is possible to have some condition which will cancel out. Which
means that Cn = ... will return to what it was suppose to. This means
the error will not propagate (cause it only uses Cn-1). If this is not
possible the cipher is not bijective!
> When a single bit changes in the input file you go to get
> a different slot in the S table That slot can point to anything
> but itself and the what the original vaule the S-box pointed to. So
in effect
> you start a change there and it propagates down that pass and
> then comes back to the top to change the following 24 passes.
No you most likely get a change, you will not always get a 'huge'
change in the block.
I will give you the glory and say 'I cannot break your cipher' however
I have found some weakness which someone else could probably exploit.
BTW your challenge is useless because I would have to mount a
chosen/known plaintext attack to guess the sbox contents. There are
some flaws in your cipher
1. memory usage
2. speed
3. It's static only
4. Hard to explain
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Shared secret protocol
Date: 10 Jun 1999 23:53:36 GMT
David P Jablon <[EMAIL PROTECTED]> wrote:
> In article <7jmhnq$[EMAIL PROTECTED]>, Logic <[EMAIL PROTECTED]> wrote:
>>
>>I am looking for a particular shared secret protocol which I have not seen
>>described in any literature I have. I would appreciate any comments,
>>pointers or discussion. I describe the basic setup and the requirements,
>>followed by a boring solution to serve as a reference.
> [... description snipped.]
> In general, since you're encouraging users to memorize
> the shared secrets, you'll want to consider the susceptibility of
> the system to brute-force attack on the database and
> on the network.
> Incorporating zero-knowledge password proofs will help.
> Papers at <www.IntegritySciences.com/links.html>
> -- dpj
Also of note may be Shai Halevi and Hugo Krawcryk's paper on
public-key password protocols. (in proceedings of the the 5th
ACM conference on security). This paper may be up at the above
link; haven't checked yet.
-David
------------------------------
** 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
******************************
