Cryptography-Digest Digest #687, Volume #9 Thu, 10 Jun 99 11:13:02 EDT
Contents:
Re: huffman code length (Mok-Kong Shen)
ATTN: Bruce Schneier - Street Performer Protocol (Anonymous)
Re: rc4 vs. rand() ([EMAIL PROTECTED])
Re: IDEA-128 ([EMAIL PROTECTED])
Re: Jaws Tech's L5 Data Encryption Algorithm ([EMAIL PROTECTED])
Re: being burnt by the NSA ([EMAIL PROTECTED])
Re: Looking for a password encryption algorithm ([EMAIL PROTECTED])
Re: One Time Pad ([EMAIL PROTECTED])
Re: ATTN: Bruce Schneier - Street Performer Protocol (Mok-Kong Shen)
Re: Does scott19u.zip make full use of it's large key size ? ([EMAIL PROTECTED])
Re: ATTN: Bruce Schneier - Street Performer Protocol ([EMAIL PROTECTED])
Anonymous comments on Street Performer Protocol (was: ATTN: Bruce...) (Larry
Kilgallen)
Re: ATTN: Bruce Schneier - Street Performer Protocol (Mok-Kong Shen)
Re: Looking for a password encryption algorithm (Robert G. Durnal)
Re: High precision integer arithmetic (Robert G. Durnal)
Re: being burnt by the NSA (Gordon Grieder)
Re: ATTN: Bruce Schneier - Street Performer Protocol (Bruce Schneier)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.compression,alt.comp.compression,sci.math
Subject: Re: huffman code length
Date: Thu, 10 Jun 1999 13:21:44 +0200
Alex Vinokur wrote:
>
> For more details about worst-case code see
> the message titled "Huffman codes and Fibonacci numbers"
> in comp.compression
>
> http://www.deja.com/getdoc.xp?AN=471802979&fmt=text
>
Recently I posed a question elsewhere concerning Huffman encoding.
Since I don't yet have any appropriate answer, I like to take this
opportunity to repost it here:
The Huffman encoding is such that a uniform frequency distribution
gives a balanced tree while extremely non-uniform distribution
gives a tree very remote from being balanced. For a balanced tree
of 4 symbols, for example, a frequency distribution of 0.20, 0.20,
0.21, 0.39 is possible but much more extreme distributions are not
possible.
Question: Given an arbitrary Huffman tree, how can we say something
useful in quantitative terms concerning the possilbe frequency
distributions that correspond to it?
M. K. Shen
------------------------------
Date: Thu, 10 Jun 1999 13:42:45 +0200 (CEST)
From: Anonymous <[EMAIL PROTECTED]>
Subject: ATTN: Bruce Schneier - Street Performer Protocol
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
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: rc4 vs. rand()
Date: Thu, 10 Jun 1999 11:03:13 GMT
In article <7jng8o$lgv$[EMAIL PROTECTED]>,
Michael J. Fromberger <[EMAIL PROTECTED]> wrote:
> A function is a relation which maps each element of the domain to at
> most one element of the range. A function is one-to-one, or
> "injective", if no two elements of the domain are mapped to the same
> element of the range. A function is onto, or "surjective", if every
> element of the range is the image of at least one element of the
> domain.
So the RC4 sbox is injective because all inputs have an unique output.
It's surjective because the opposite is true (range onto domain). It's
bijective because both are true.
So would the IDEA sboxes be bijective? They are surjective because the
input->output is 1:1, it's surjective because the inverse is true as
well...
Thanks for the info,
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: IDEA-128
Date: Thu, 10 Jun 1999 11:18:16 GMT
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++]
> 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.
> 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.
> 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.
>
> 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.
> 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.
> 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.
> 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.
>
> 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.
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: Jaws Tech's L5 Data Encryption Algorithm
Date: Thu, 10 Jun 1999 11:20:45 GMT
In article <7jmp0k$527$[EMAIL PROTECTED]>,
"Chris" <[EMAIL PROTECTED]> wrote:
> Has anyone heard of a sucessful attack on Jaws Tech's L5 Data
Encryption
> Algorithm? Information on the Company and products can be found at
> www.jawstech.com
Last time I checked they never actually describe their 'super-duper'
algorithm. I would not trust it. (I don't think I am alone here)
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: being burnt by the NSA
Date: Thu, 10 Jun 1999 11:35:25 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> You're thinking of CSIS, which has no U.S.A. counterpart. Previously,
> internal security matters were handled by the RCMP in Canada, just as
> they are handled by the FBI in the United States, but now we have a
> secret agency oriented domestically - a very dangerous thing.
Well I know about the RCMP (they are the ones at disney land...). I
see there show every year (chaning of the guards).
>
> The Canadian counterpart of the NSA is little known, although it
> *does* have a web site: the CSE, or Communications Security
> Establishment.
>
Yeah well you can't put that on t.v no one would believe Canada (or
any other known country) might have a spy agency.
The RCMP is the closest thing to the 'intelligence' world. Like when
they worked with Norad to do the drug busts... etc...
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: Looking for a password encryption algorithm
Date: Thu, 10 Jun 1999 10:59:23 GMT
> I am looking for a simple password encryption algorithm
> similar to unix crypt(). I want to implement in my own
> simple authentication project.
>
> I dont know where I can get resources / papers ?
Look up FIPS-180 SHS the Secure Hash Standard (or just SHA-1). It
will 'encrypt' (note: there is no decryption) any password (or anything
under 2^64 bits...). There is a really long paper on it.
If you are just doing something simple try MD5 which is still
relatively good. If you are adventurous lookup TIGER (by Eli Biham and
Ross Anderson I believe...) it is another good hash.
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: One Time Pad
Date: Thu, 10 Jun 1999 10:56:53 GMT
<snip>
No attacks work (well in the math world) against a OTP. However if the
key is not truly random (i.e derived from an algorithm of some sort)
then that could be a point of attack.
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: ATTN: Bruce Schneier - Street Performer Protocol
Date: Thu, 10 Jun 1999 15:03:26 +0200
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)
You launched a bunch of very severe attacks agains Mr. Schneier,
however without giving any reference to his writing. I just looked
at the web page of counterpane without finding anything remotely
related to the target of your attack. This is non-scientific way of
argumentation and is not appropriate for this group. Please redo
your work, give pointer to references and say precisely what you think
is wrong and give concise reasons for that. That you write anonymously
is perfectly o.k.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Does scott19u.zip make full use of it's large key size ?
Date: Thu, 10 Jun 1999 11:29:21 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Tim Redburn) wrote:
> From what I can make out about scott19u.zip (which
> granted is not very much), it appears that
> one of it's main security features is the
> use of an incredibly large S-Box for subtitutions.
As an example I wrote a simple cipher using large s-boxes. You can
take a look at
http://people.goplay.com/tomstdenis/simple.c
It's much easier to use/read then scottu19, and it is much faster. I
wouldn't really brag about security as I don't know of any attacks,
partially because I just wrote this three days ago...
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: ATTN: Bruce Schneier - Street Performer Protocol
Date: Thu, 10 Jun 1999 12:48:47 GMT
<snip>
Hey mr. 'Anonymous' if that is your real name, shut up. Although his
paper is vague and not well read I would not jump up and down on him.
He has done stuff that you (and I) cannot even comprehend at this stage.
He is known for breaking half a dozen or so algorithms and has designed
two very good encryption algorithms.
I think the paper was a flop, but who am I to say so. BTW I think the
only big solution for the music piracy would be to encrypt each cd alone
then pass decryption codes in the music insides...
This would be slow but curve the piracy. If you had to register the
music you buy (good god!) then piracy can be curbed. Unless of course
you can remove id information from the cd.
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Larry Kilgallen)
Subject: Anonymous comments on Street Performer Protocol (was: ATTN: Bruce...)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 10 Jun 1999 12:48:04 GMT
In article <[EMAIL PROTECTED]>, Anonymous <[EMAIL PROTECTED]>
writes:
> 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.
If this was private mail to Bruce, you typed the wrong command.
If this was intended as a public comment, you should indicate
the web site to which you refer. I found nothing relevant to
your comments on the page http://www.counterpane.com/ .
Larry Kilgallen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: ATTN: Bruce Schneier - Street Performer Protocol
Date: Thu, 10 Jun 1999 16:00:09 +0200
Bruce Schneier wrote:
>
> On Thu, 10 Jun 1999 15:03:26 +0200, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
>
> >This is non-scientific way of
> >argumentation and is not appropriate for this group.
>
> This newsgroup has never been particularly scientific.
That doesn't mean that we should not take collective action to cut
non-scientific argumentations and attempt to get even improvements.
There is one internet mailing list I know of that has deteliorated
to almost a list of a mess of rubishes. All that are interested to be
benefited from communications carried on in our group should
therefore take efforts to prevent such deteliorations from taking
place.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Robert G. Durnal)
Subject: Re: Looking for a password encryption algorithm
Date: 10 Jun 1999 14:08:39 GMT
In <7jo0aj$di6$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
: I am looking for a simple password encryption algorithm
: similar to unix crypt(). I want to implement in my own
: simple authentication project.
: I dont know where I can get resources / papers ?
: Thanks,
: SANTUG
I have coded SHA1 to hash a passphrase of up to 64 bytes. Check out
www.afn.org/~afn21533/sha1pass.zip.
==========
My home page URL=http://members.tripod.com/~afn21533/ Robert G. Durnal
Hosting HIDE4PGP, HIDESEEK v5.0, PGE, TinyIdea (link) [EMAIL PROTECTED]
and BLOWFISH in both Windows and mini-DOS versions. [EMAIL PROTECTED]
EAR may apply, so look for instructions.
------------------------------
From: [EMAIL PROTECTED] (Robert G. Durnal)
Subject: Re: High precision integer arithmetic
Date: 10 Jun 1999 14:09:24 GMT
In <[EMAIL PROTECTED]>, Withheld <[EMAIL PROTECTED]>
wrote:
: Some time ago someone asked about high precision integer arithmetic, ie
: wanting to perform calculations with large numbers without losing any
: resolution.
: If anyone is interested I've been tinkering with a long calculator that
: does that sort of thing. Presently it works for numbers up to about 500
: digits. I'm looking at getting decent error trapping and bigger numbers
: to work but if anyone wants to take a look at it on an "as is" basis,
: drop me an email (address in signature) and I'll mail it out. The file
: is an ActiveX DLL so is only really useful on a Windoze platform.
: If enough people want it I'll put it on a website somewhere.
: --
: Return address removed for anti-spam purposes.
: Email replies to news at maelstrom dot demon dot co dot uk
: Email replies to this address may be copied to relevant newsgroups
===========
Yes, put it up. I have done some work along these lines, and have a
small assembly language library at www.afn.org/~afn21533/mpi.zip. This is
presently assembled for 128-bit integers, but I see no reason why it would
not work with 1024 if so assembled.
===========
My home page URL=http://members.tripod.com/~afn21533/ Robert G. Durnal
Hosting HIDE4PGP, HIDESEEK v5.0, PGE, TinyIdea (link) [EMAIL PROTECTED]
and BLOWFISH in both Windows and mini-DOS versions. [EMAIL PROTECTED]
EAR may apply, so look for instructions.
------------------------------
From: Gordon Grieder <[EMAIL PROTECTED]>
Subject: Re: being burnt by the NSA
Date: Thu, 10 Jun 1999 09:14:34 -0500
John Savard wrote:
>
> Gordon Grieder <[EMAIL PROTECTED]> wrote, in part:
>
> >I suggest reading Spyworld by Mike Frost, an ex-CSIS employee.
>
> Ex-CSE.
Whoops. ;)
--
Gordon Grieder
[EMAIL PROTECTED]
http://www.grub.net "Purveyors of Fine Crud."
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: ATTN: Bruce Schneier - Street Performer Protocol
Date: Thu, 10 Jun 1999 13:22:07 GMT
On Thu, 10 Jun 1999 15:03:26 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>This is non-scientific way of
>argumentation and is not appropriate for this group.
This newsgroup has never been particularly scientific.
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
******************************
