Cryptography-Digest Digest #538, Volume #9 Thu, 13 May 99 00:13:04 EDT
Contents:
Re: An apology to Tom St. Denis; also, Terry Ritter is not very bright (SilverRaven)
Re: RSA Chips (Paul Koning)
Re: Hello I am paper, please read me. (Gustaf Dellkrantz)
Re: An apology to Tom St. Denis; also, Terry Ritter is not very bright (Terry Ritter)
Re: Digital encryption (Paul Koning)
Re: An apology to Tom St. Denis; also, Terry Ritter is not very bright
([EMAIL PROTECTED])
Re: Hello I am paper, please read me. ([EMAIL PROTECTED])
Re: Hello I am paper, please read me. ([EMAIL PROTECTED])
Re: AES (Nicol So)
Re: Oh! Before I get some sleep is DES international yet? (Bill Unruh)
Re: An apology to Tom St. Denis; also, Terry Ritter is not very bright
(SCOTT19U.ZIP_GUY)
Re: AES (Nicol So)
Re: Lemming and Lemur: New Block and Stream Cipher (Jim Gillogly)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SilverRaven)
Subject: Re: An apology to Tom St. Denis; also, Terry Ritter is not very bright
Date: Wed, 12 May 1999 21:16:46 GMT
[groups cut]
[EMAIL PROTECTED] wrote:
>To Tom St. Denis:
<snip>
>Terry Ritter:
<snip>
Please don't reply to this troll, he is trying to start a flame war
between groups.
Thank you,
SilverRaven
from alt.games.diablo
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: RSA Chips
Date: Wed, 12 May 1999 14:07:55 -0400
Oliver Hauck wrote:
>
> Hi all,
>
> I would like to learn about the present state of the art in dedicated
> single-chip VLSI implementations of RSA, specifically: throughput,
> latency, and energy requirements.
>
> Has RSA been implemented on a wireless (inductance powered) crypto
> chipcard yet?
Don't know about chipcards. Do you really need it for that application?
Seems a software solution would be ok. But anyway, there do exist
some chips that can do RSA. Both Hi/fn and IRE have them; there may
well be others. Rivest built one about 15 years ago, though that
was a lab thing, not a product.
paul
--
!-----------------------------------------------------------------------
! Paul Koning, NI1D, D-20853
! Xedia Corporation, 119 Russell Street, Littleton, MA 01460, USA
! phone: +1 978 952 6000 ext 115, fax: +1 978 952 6090
! email: [EMAIL PROTECTED]
! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "The only purpose for which power can be rightfully exercised over
! any member of a civilized community, against his will, is to prevent
! harm to others. His own good, either physical or moral, is not
! a sufficient warrant." -- John Stuart Mill, "On Liberty" 1859
------------------------------
From: Gustaf Dellkrantz <[EMAIL PROTECTED]>
Subject: Re: Hello I am paper, please read me.
Date: Wed, 12 May 1999 21:40:12 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Your algorithm is vulnerable to a fairly trivial attack unfortunately.
>
> Given Deck A and Deck B this is exactly equivalent to a completely
> ordered
> deck A' , and B' being the result of taking card B(A(1)) and so on.
>
> So then the algorithm evolves as follows given a key set (A,B)
> Encode message M= N 0's.
> M will encrypt to give you an exact list of the makeup of B'.
> Once this is known all messages from this key are compromised.
>
> Given a cyphertext --.the first N digits decrypt exactly by X or with
> B',
> next N digits may be either brute forced by trying all N possible
> shuffles
> -- this should yield recognizable plaintext only with a very few
> tries(and
> thus R), or by guessing the next likely character and identifying
> which
> element of B' must have been used to generate it( thus allowing the
> trivial
> determination of R).
>
> Similarly the revealing that characters k*n+1 to (k+1)*n decrypt to M
> will
> allow the whole string from start to finish to be decrypted with
> little
> effort.
>
> Reshuffling B as well will improve security, but will also fall to a
> similar but more time consuming attack. Reshuffling after R<N turns
> will
> help, but will still compromise the algorithm's first R characters.(
> at
> best) and probably allow an analyst to maker progress against the
> code.
>
There is yet another weakness that might improve your attack. The
problem is in the shuffle function and allows us to recover the shuffle
value used when shuffling deck_A after a round of encryption.
Of N possible shuffle values N-2 move all cards of the deck except one.
One shuffle value move all cards except two (r=0) and the remaining
(r=N/2) moves all cards. This allows us to determine the shuffle value
used by comparing two consecutive outputs from the algorithm
(known/chosen plaintext). If the output was completely different, r=N/2
was used. If the first and last values stayed the same r=0 was used. And
the remaining N-2 cases can be determined by using a precomputed
lookup-table (Actually the pattern is quite obvious, but I generated it
with a computer). For example r=1 makes the third card stay and so on.
This might allow us to break the PRNG used to generate shuffle
values for shuffling deck_A.
/Gustaf
--
Gustaf Dellkrantz ([EMAIL PROTECTED])
My opinions only and so on...
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: An apology to Tom St. Denis; also, Terry Ritter is not very bright
Date: Wed, 12 May 1999 21:54:43 GMT
On Wed, 12 May 1999 21:16:46 GMT, in <377af0c4.91476150@news>, in
sci.crypt [EMAIL PROTECTED] (SilverRaven) wrote:
>[groups cut]
>
>[EMAIL PROTECTED] wrote:
>
>>To Tom St. Denis:
><snip>
>>Terry Ritter:
><snip>
>
>Please don't reply to this troll, he is trying to start a flame war
>between groups.
>
>Thank you,
>SilverRaven
>from alt.games.diablo
Interesting. Thanks for the heads-up.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Digital encryption
Date: Wed, 12 May 1999 14:10:41 -0400
[EMAIL PROTECTED] wrote:
> I wish to encrypt this bit stream, but have had little success so far
> amongst the local electronic distributors in locating a chip manufacturer
> that has a ready made encryption chip.
>
> Do they exist, or am I to got the PAL/GAL or custom design route?
There are plenty at least for DES/3DES; RC4 I've seen too, anything
else seems uncommon.
Some names, by no means exhaustive: Hi/fn, IRE, VLSI Design. There may
be more, perhaps an Altivista search would help.
paul
--
!-----------------------------------------------------------------------
! Paul Koning, NI1D, D-20853
! Xedia Corporation, 119 Russell Street, Littleton, MA 01460, USA
! phone: +1 978 952 6000 ext 115, fax: +1 978 952 6090
! email: [EMAIL PROTECTED]
! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "The only purpose for which power can be rightfully exercised over
! any member of a civilized community, against his will, is to prevent
! harm to others. His own good, either physical or moral, is not
! a sufficient warrant." -- John Stuart Mill, "On Liberty" 1859
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.aol,alt.games.diablo,rec.toys.cars
Subject: Re: An apology to Tom St. Denis; also, Terry Ritter is not very bright
Date: Wed, 12 May 1999 22:34:12 GMT
> To Tom St. Denis:
<snip>
Well that's ok. In a way you are right, I should document my ideas
better, and provide reasoning for the algorithms. I re-started the
TwoDeck, by including references to other ciphers (notably RC4) and how
mine is better (?), I also will be including better analysis and
attacks (that I find).
I hope all is well, and when I have a better paper out, you can read it
as objectively as possible.
> Terry Ritter:
<snip>
However true, you shouldn't say things like that. It's true that his
site is vague, but his glossary is well document and complete. His
claims are a little vague, and perhaps he could document them as a
respone to this?
I noticed he has some of his ideas patented, so disclosure is not an
issue.
What do you think Terry?
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: Hello I am paper, please read me.
Date: Wed, 12 May 1999 22:52:37 GMT
> Your algorithm is vulnerable to a fairly trivial attack unfortunately.
>
> Given Deck A and Deck B this is exactly equivalent to a completely
ordered
> deck A' , and B' being the result of taking card B(A(1)) and so on.
The idea is you don't know deck A, so you don't know where the values
came from in deck B.
Am I missing something? Yes is deck A or deck B is known the security
is pretty low, but the idea is you don't know either. There are N!
valid solutions too, so how do you isolate one?
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: Hello I am paper, please read me.
Date: Wed, 12 May 1999 23:43:22 GMT
> There is yet another weakness that might improve your attack. The
> problem is in the shuffle function and allows us to recover the
shuffle
> value used when shuffling deck_A after a round of encryption.
>
That's saying you can isolate the deck_A from it's possible solutions.
> Of N possible shuffle values N-2 move all cards of the deck except
one.
Um, no. All N values will create at one new deck from the old one.
Where do you find this? Maybe it's true, I just don't understand.
> This might allow us to break the PRNG used to generate shuffle
> values for shuffling deck_A.
If you know the deck_A. Your attack requires isolating deck_A
from 'N! / 2' valid solutions. Otherwise you will not know which value
was used to shuffle the deck. That is where I think the security lies.
Is there a weakness in the shuffle? Maybe the algorithm as a whole can
be improved with a better (perhaps faster) shuffle...?
Thanks for the reply,
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: Nicol So <[EMAIL PROTECTED]>
Subject: Re: AES
Date: Wed, 12 May 1999 21:04:23 -0400
Douglas A. Gwyn wrote:
>
> Bruce Schneier wrote:
> > Multiple encryption is generally a good idea. The only reason you
> > don't see it widely used in practice is that using N ciphers cuts
> > the performance by a factor of N (more or less).
>
> Without necessarily gaining proportionally in security.
> If you have a good algorithm, it would seem to be better
> to put the extra cycles into using that algorithm with a
> longer key (for example).
I think most people are aware of that (the lack of guaranteed
proportional gain in security). I'd like to view Bruce's suggestion as
a conservative design heuristic. Most (secret-key) block ciphers that
I've come across are iterated ciphers, in which the same construct is
composed with itself multiple times. You could, if you wish, consider
such a cipher multiple encryption with the same cipher using
non-independent keys. What multiple encryption (with dislike ciphers)
buys you, in my opinion, is some irregularity and, hopefully, less
susceptibility to undiscovered flaws in any single component constructs.
Generally speaking, I think it is more difficult to generalize
observations about single constructs to an iterated composition of them,
when dislike structures break up the regularity that would be present in
iterated composition of a single construct. If this view is close to
being accurate, the same benefit should also be obtainable by
interleaving dislike round structures, not necessarily dislike
"ciphers".
I guess I basically agree with you (Doug), except that I don't think I
can reliably tell whether I've got a good algorithm. In the absence of
a convincing argument to the contrary, I would be tempted to resort to
what I consider conservative design practices to insure against my own
ignorance and oversight.
Nicol
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Oh! Before I get some sleep is DES international yet?
Date: 13 May 1999 01:13:12 GMT
In <7h7q53$6c1$[EMAIL PROTECTED]> "WarlockD" <[EMAIL PROTECTED]> writes:
>I just got a hold of WindowsCE toolkit and making a simple crypt program
>that uses a MD4 hash and DES to encrypt, want to post it on a web site, but
>don't want to be arrested for treason:P
>Anyone happen to know if DES is international algorithm? (I know MD4 isn't,
>or if its copyrighted:P) If not, anyone know where or how you can "weaken"
>encryption algorithms so they are exportable? I am not too concerned with
>the security end as much as the legal end:P
Talk to a lawyer for legal advice, not anewsgroup.
However, some comments.
a) It does not matter if the algorithm is "international". ALL crypto, no matter where
it
comes from, must have a license to be exported.
b) Some crypto has an easier time getting a license. (There are no rules on this-- it
is up to the discression of the Dept of Commerce, but loosely stated, 56 bit or less
effective strength gets an easier time of it.)
c) The recent 9th district court ruling MAY invalidate the law in the 9th district.
Check with a lawyer.
d) MD4 is an authentication hash. Thre are no export restrictions on it itself.
However if you
incorporate it into a program to make a cryptosystem
eg a program which does
O(n)=I(n)^MD4(key+O(n-1))
where O(n) is the nth output block and I(n) is the nth input block, then
it is illegal, sccording to the regulations, to post it without a license.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: alt.aol,alt.games.diablo,rec.toys.cars
Subject: Re: An apology to Tom St. Denis; also, Terry Ritter is not very bright
Date: Thu, 13 May 1999 03:04:36 GMT
In article <7hcq0u$pdm$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>To Tom St. Denis:
>I would sincerely like to apologize for sending numerous flames to the
>sci.crypt newsgroup. I recognize that everyone has to start somewhere,
>and that making at least an effort to learn more about a subject is a
>trait to be greatly admired. Not only was my comment ill-considered,
>but repugnantly rude and counterproductive. Thank you for your time.
>
>Terry Ritter:
>Just becuase you aren't as famous as Bruce Scheiner is, and nobody uses
>your crappy propietary algorithms that you charge licensing fees for,
>doesn't mean that everyone elses algorithm is weak. Quite frankly, your
>products are little more than glorified snake-oil: admitedly better
>than more, but still snake-oil none the less. I see at least one
>substantial conflict of interest in your constant peddling of a wide
>variety of algorithms regardless of their analysis: you yourself
>"happen" to be in the business of making such "security products" (and
>I use this phrase in the broadest and most charitable sense.) While no
>general proof of the security of a block cipher exists, much in fact
>can be gained from analysing an algorithm without result. The fact that
>the best minds in the academic field are unable to come close to
>breaking an algorithm strongly suggests that the algorithm does possess
>some strength, something that cannot be said for your's. I view your
>type of snake-oil peddler as even worse than David A. Scott, because at
>least his product is free, he releases the source code, and he is
>willing to defend his claim that his algorithm possesses adventagous
>traits over existing algorithms (instead of a broad, meaningless
>assertion that having many, unanalysed algorithms is stronger than one,
>well-analysed algorithm).
I feel Terry is less of a snake-oil peddler than Mr. BS who safely attacks
and makes wise cracks from a distance. I don't feel Terry is in bed with
the NSA either. Terry to me seems a very hard worker and is willing to look
at out side algorithms. He is on much less of an ego trip than some of your
other Crypto Gods.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: AES
Date: Wed, 12 May 1999 23:11:30 -0400
Douglas A. Gwyn wrote:
>
> Bruce Schneier wrote:
> > Multiple encryption is generally a good idea. The only reason you
> > don't see it widely used in practice is that using N ciphers cuts
> > the performance by a factor of N (more or less).
>
> Without necessarily gaining proportionally in security.
> If you have a good algorithm, it would seem to be better
> to put the extra cycles into using that algorithm with a
> longer key (for example).
I think most people are aware of that (there is no guarantee of
proportional gain in security). I like to view Bruce's suggestion as
a conservative design heuristic. Most (secret-key) block ciphers that
I've come across are iterated ciphers, in which the same construct is
composed with itself multiple times. You could, if you wish, consider
such a cipher multiple encryption with the same cipher using
non-independent keys. What multiple encryption (with unlike ciphers)
buys you, in my opinion, is some irregularity and, hopefully, less
susceptibility to undiscovered flaws in any single component construct.
Generally speaking, I think it is more difficult to generalize
observations about individual constructs to an iterated composition of
them, when dissimilar structures break up the regularity that would be
present in iterated composition of a single construct. If this view is
close to being correct, it should be possible to obtain the same
benefit by interleaving dissimilar round structures, not necessarily
dissimilar "ciphers".
I basically agree with you, but I don't think I can reliably tell
whether I've got a good algorithm. In the absence of a convincing
argument to the contrary, it is tempting to resort to what one
consider as conservative design heuristics to insure against what one
might have overlooked.
Nicol
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Lemming and Lemur: New Block and Stream Cipher
Date: Wed, 12 May 1999 20:55:20 -0700
[EMAIL PROTECTED] wrote:
> In other words, XORing block[0] with the key is equivalent to applying
> perm to block[0]. That's why the key is constructed as it is.
Cool. Could you post a test vector? Something pretty repetitive
in the key would be fine, to avoid a huge pile of bits.
--
Jim Gillogly
22 Thrimidge S.R. 1999, 03:53
12.19.6.3.7, 10 Manik 15 Uo, Fourth Lord of Night
------------------------------
** 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
******************************
