Cryptography-Digest Digest #922, Volume #11 Fri, 2 Jun 00 16:13:00 EDT
Contents:
Re: Question about Re: RSA/PK Question ("Trevor L. Jackson, III")
Re: TC3 Update (David A. Wagner)
Re: Solovay-Strassen primality test (Bob Silverman)
Re: Can we say addicted? (Mike Rosing)
Re: Retail distributors of DES chips? (Terry Ritter)
Re: Retail distributors of DES chips? (Terry Ritter)
Re: Good ways to test. ("Adam Durana")
Re: Contest rule proposal (David A. Wagner)
Cost of SPACE -- going down! ("Trevor L. Jackson, III")
Re: Good ways to test. (Terry Ritter)
Re: TC3 Update (tomstd)
Home Office climbdown on Reuters RIP Bill story ("B Labour")
Re: Question about Re: RSA/PK Question (tomstd)
Re: Good ways to test. (tomstd)
Re: TC3 Update (zapzing)
Re: Contest rule proposal ("Trevor L. Jackson, III")
Re: Self Shrinking LFSR (Terry Ritter)
Re: TC3 Update (David A. Wagner)
----------------------------------------------------------------------------
Date: Fri, 02 Jun 2000 15:09:20 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Question about Re: RSA/PK Question
tomstd wrote:
> In article <[EMAIL PROTECTED]>, "Trevor L. Jackson,
> III" <[EMAIL PROTECTED]> wrote:
> >tomstd wrote:
> >
> >> In article <KkvZ4.15$[EMAIL PROTECTED]>, "DD"
> >> <[EMAIL PROTECTED]> wrote:
> >> >tomstd <[EMAIL PROTECTED]> wrote in message
> >> >news:[EMAIL PROTECTED]...
> >> >> In article <O04uc$3y$GA.187@cpmsnbbsa09>, "Joseph Ashwood"
> >> >> <[EMAIL PROTECTED]> wrote:
> >> >> >You and I both know that many of us (including myself)
> have
> >> >> >corrected you on this time and time again. If you are so
> >> >> >focused on only protecting against the right here right
> now,
> >> >> >why don't you use a 57 bit key? 56 bit's is the largest
> >> >> >that's been publically done, 64-bits has been going on
> for a
> >> >> >long time now, so 57 bits is good enough for now. Instead
> we
> >> >> >have as a community gone with AES at 128 bits minimum. You
> >> >> >seem to be very much the exception here, instead of the
> rule
> >> >> >you think you are.
> >> >> > Joe
> >> >>
> >> >> Although I should be doing my Bio I felt like reading the
> >> >> group. You are a pragmatic jerk, you know that right?
> >> >>
> >> >> I never said to use 57-bit symmetric keys. In fact I said
> to
> >> >> use 80-bits as the minimum for right now. I also said to
> use
> >> >> 768~1024 bit RSA keys because they can't be solved right
> now.
> >> >>
> >> >> I also don't agree with using 128+ bit symmetric keys
> because
> >> it
> >> >> provides a false sense of security. "Oh it's secure
> because I
> >> >> use a 256-bit symmetric key", big deal.
> >> >
> >> >I don't understand what you mean, can you or anyone else
> please
> >> >explain? Are you saying that it is not secure or that
> whether
> >> the
> >> >key is 128bits or say 256 bits makes little difference in
> >> practice
> >> >because both are thought to be secure today?
> >>
> >> I mean what I said, since you can't possibly search either a
> 128
> >> or 256 bit key space
> >
> >now
> >
> >> they are equally secure
> >
> >now.
>
> I seriously doubt 256-bit keyspaces will be exuasted any time
> soon. Even if QC becomes a reality (which it will) then you are
> looking at 2^128 time which is still big. As it stands no
> digital computer (or combination thereof) can exhaust even a 80-
> bit keyspace now, so I would strongly suggest 128-bit being non-
> searchable. Sure 100 years from now 80-bit keys may be trivial
> (same for 128) but now. And most secrets are only secrets for
> at most 5 years anyways...Who cares what your secret recipe for
> crispy chicken is 10 years from now?'
You should. I think the Coca-cola recipe is over 100 years old.
>
>
> >>
> >> When you compare 40 and 56 bit keys, well obviously 56 bit
> keys
> >> are more secure, since you can search both, just the latter
> >> takes more time.
> >>
> >> You can't search either 128/256 bit keyspaces
> >
> >now
>
> Or for a very long time.
>
> >
> >> , so technically
> >> there is no advantage to using 256 bit keys.
> >
> >... if the lifetime of the information you need to protect is
> small in comparison
> >to the time it takes to produce a breakthrough in in crypto
> technology. As a
> >thumb rule I'd use 1-10 years as the frame work for deciding
> between currently
> >effective key sizes (128 bits today) and "long term" keys sizes
> that must be
> >larger. Information that becomes useless in less than a year
> is probably safe
> >with keys sizes that are safe today, but info lifetimes above
> 10 years certainly
> >mandate a more generous margin of paranoia.
> >
> >In the 1-10 year gray area one has to evaluate the cost-benefit
> tradeoff of more
> >than minimal security because finding quality implementations
> of more than
> >minimal security is difficult. Thus it sometimes becomes
> difficult to justify
> >the additional cost/effort/hassle of using larger keys.
> >
> >While we may be able to create scalable security techniques
> such a cipher
> >stacks, and expandable cipher technologies, we don't seem to be
> able to produce
> >scalable cryptanalysis techniques. The fact that "the devil is
> in the details"
> >may indicate that scalable crypt analysis is probably a
> fantasy. Maybe there's
> >a niche for highly abstract AI products here?
>
> Suggesting people to use 256-bit keys as they are more secure
> now is irresponsible. Heck as I stated 80-bit keys are secure
> now.
>
> Let's say a 64-bit key would take a year with distribute.net
> (now). If moores law continues for 10 years, we will see a 6.5x
> fold in compute speed, still not enough to search a 80-bit key
> in reasonable time. It would take 10,082 (compared to 56 days
> with the 64-bit key) years to search. Let's say 50 years (33.3x
> speed) the same 64 bit key will take about 11 days to find, but
> a 80-bit key requires about 1,968 years still. Let's say moores
> law contiunes for 100 years, and the # of computers quadruples
> we will see a 266.6x speedup. A 64-bit key could be found in
> 1.36 days, and the same 80-bit key takes 245 years.
I think you are confused about Moore's observation. It's generally taken to be
2x every 18 months (I think the original observation was 18-24 months). That
means in 100 years you don't get a factor of 67, but 67 factors of two. Plug
this difference into your analysis and see where it leads.
> Now saying computers will grow 4x in numbers is not realistic.
> I think after 100 years we will see a 100x increase in
> computers, note this is a 6144x speedup. A 64-bit key would
> take about 0.059 days (1h 25m) to find, and a 80-bit key would
> take 10.6 years.
>
> So even if the # of computers increases by 1x each year and the
> computing speed doubles every 18 months, a 80-bit key will be
> secure 100 years from now for about 10 years. I think this is
> fairly resonable since I can't expect to see the number of
> usable computers go up exponentially each <specific time period>
Why not? AFAICT there is no polynomial that maps well to the growth of the
number of computers in existence. It's an exponential. Look for yourself.
>
>
> No I am not saying to go out of your way to use 80-bit keys over
> 128-bit keys, but don't let paranoia get in the way of good
> judgement.
>
> Food for thought,
Chew before you swallow! ;-)
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: TC3 Update
Date: 2 Jun 2000 11:54:49 -0700
In article <[EMAIL PROTECTED]>,
tomstd <[EMAIL PROTECTED]> wrote:
> (multiplicative inverse in the galois field 2^128 mod p)
Err, I can't see how to assign any meaning to that phrase.
Did you perhaps mean GF(2^128)? GF(p)? something else?
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Solovay-Strassen primality test
Date: Fri, 02 Jun 2000 18:54:45 GMT
In article <Pine.LNX.4.10.10006021709020.5614-
[EMAIL PROTECTED]>,
Marek Futrega <[EMAIL PROTECTED]> wrote:
>
> The basis of the Solovay-Strassen algorithm is the fact that for any
> given composite number "n", there are at most n/2 values of "a" less
than
> "n" for which "n" is an Euler pseudo-prime with base "a".
Hint: Think about Euler's criterion for quadratic reciprocity.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Can we say addicted?
Date: Fri, 02 Jun 2000 13:50:48 -0500
Joseph Ashwood wrote:
>
> > You too? O, well, it's better than drugs, I suppose.
> Then you need to get some better drugs. (Just for the record I have in my
> life used 2 drugs, adrenalin, and caffeine, so don't take me too seriously
> on the subject).
:-) I've tried a few more than that. But crypto is one of the better
ones.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Retail distributors of DES chips?
Date: Fri, 02 Jun 2000 19:01:06 GMT
On Wed, 31 May 2000 02:34:29 GMT, in <8h1tnk$bra$[EMAIL PROTECTED]>, in
sci.crypt zapzing <[EMAIL PROTECTED]> wrote:
>[...]
>In article <[EMAIL PROTECTED]>,
> ritter <[EMAIL PROTECTED]> wrote:
>[...]
>> What we really want is a cipher subsystem -- hardware
>> or software -- which demonstrably produces no more
>> data than we send to it. To assure this, we might
>> send in a buffer of data, and then use that same
>> buffer with the original length as the result. There
>> must be (at this level) no subsystem-selected or
>> produced random values.
>>
>
>And I'm glad you pointed that out because only
>hardware can assure us that no *more* data is
>being transmitted than we want. After all, a
>software system could do everything we wanted
>it to do, and then sneak through some other
>information in the FAT table, for instance.
>Such as the key, for example.
But unless you advocate having *all* *hardware*, front to back, your
chip will eventually communicate to software, where you pick up the
same problem. Why should an opponent worry about subverting a cipher
when they can simply send the latest key over the net?
The advantage of the software is the possibility of certifying the
source code to the object code (compile it, or check the result with a
cryptographic hash), and then reviewing the source to assure that it
does not have bad things. We cannot hope to review hardware designs
that way.
>[...]
>The way I see it the problem with a scaleable cipher
>as a defense against a malicious attacker (hardware
>*or* software), is that the attacker might make it
>so that the cipher performed as expected in a small
>system but then reverted to a significantly weaker
>algorithm when it was scaled up a certain amount.
It certainly is necessary to check the source. Some ciphers will have
no internal state-machine or special cases, so security dangers will
stand out.
I think that probably the larger issue is to have some guarantee that
the object code we certify is that which is actually running. I
suspect that a suitably-modified OS could pretend to be running our
code and actually run something else. But when we cannot depend upon
the OS (and we can't), hardware isn't going to help. First, we can't
certify commercial hardware, and second, an insecure OS runs that
hardware, or claims to.
>Finally I would just like to say that this thread
>has indeed brought in many issues that were not
>in the original post, and these have made it
>possible for me to include more defenses in my
>plan than it had originally. This is, of course,
>a good thing. But it can be confusing if you have
>"missed a few episodes". So perhaps it is best
>not to "shoot from the hip" (even if you think
>you have just been shot at!).
I think we all do what we can. It is in the nature of Usenet that
some messages may not get all places; if those particular messages are
critical, the conversation becomes hard to follow. My ISP makes
things more interesting by first getting and then erasing messages at
random. But in a normal conversation, losing one or more comments is
not usually a significant problem.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Retail distributors of DES chips?
Date: Fri, 02 Jun 2000 19:01:26 GMT
On 30 May 2000 21:08:24 GMT, in <[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] (Mark Wooding) wrote:
>ritter <[EMAIL PROTECTED]> wrote:
>
>> Or maybe your idea of "trustworthy" is the real hobby-horse ride being
>> so rudely interrupted.
>
>I think we're off at a tangent here still...
>
>I intended `trustworthy' to mean that, in the considered opinion of the
>security officer using the component, it is worthy of the trust placed
>in it. That's a decision for the user to make, based on whatever
>criteria he or she wants to use.
Will we now have users deciding upon the "trustworthy"-ness of a
cipher? Which users are those?
I have a real problem with this use of "trust." Scientifically
speaking, absent a mathematical proof which applies in practice, we
cannot "trust" *any* cipher. Even if we try a more casual definition,
users simply do not have the information which we normally associate
with "trust": not *knowing* a cipher is broken is not grounds for
"trust," yet that is the best one can realistically expect.
>> That said, I think we can test a cipher chip to a software
>> implementation, using the property that we have a particular 1:1
>> transformation, and that no more information comes out than goes in.
>
>Except that, as mentioned upthread, the chip may have been programmed to
>yield the key (or some simple function of it) only when a particular
>plaintext or sequence of plaintexts is submitted for encryption, or some
>other unlikely event occurs. As you quite rightly point out, testing
>doesn't help, but this isn't the fault of the cipher this time -- the
>cipher could be completely secure and it wouldn't fix the problem -- but
>the fact that we can't look inside the implementation means we can't
>tell whether it's actually doing what it said on the box.
Nevertheless, this inability to certify something at real size is
directly addressed by scalable ciphers. I don't know if we can do
that in hardware. But in software, we can have ciphers which use the
exact same code and which are parameterized to produce small blocks.
Then we *can* hope to provide an exhaustive test of the reduced code,
which also is the expanded code. If we can certify that the object
code corresponds to the source code, and we have that source, some
ciphers will expose security-risk internal state-machines and special
cases better than other ciphers. This is a cipher issue.
All of which means that we absolutely cannot certify a commercial
hardware implementation of real size. But the direction of the
discussion, as far as one can tell, is that hardware is better.
>> But that means the chip cannot pick any "random" system-level values
>> (no message keys, no IV's).
>
>Except it might `sometimes', depending on external stimuli.
Let me say that differently: We cannot hope to certify a chip which
picks its own "random" values unless we get into the guts and know how
those values are produced, and can show that no other values get
substituted for them. In a commercial chip, we can't.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Good ways to test.
Date: Fri, 2 Jun 2000 14:56:52 -0400
http://www.wizard.net/~echo/crypto-contest.html
That might help you get an idea of how insecure your cipher is.
"John" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Are there any resources, preferrably on the Net, that can help
> test the strength of an encryption system?
>
> http://www.aasp.net/~speechfb
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network
*
> The fastest and easiest way to search and participate in Usenet - Free!
>
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Contest rule proposal
Date: 2 Jun 2000 12:01:22 -0700
In article <ArTZ4.44287$[EMAIL PROTECTED]>,
Paul Pires <[EMAIL PROTECTED]> wrote:
> Mike Rosing <[EMAIL PROTECTED]> wrote:
> > I would think that any use for purposes of the contest should be easy
> > to grant. It does not interfere with the *use* of the patent in any
> > application, for which the patent holder wants to get paid.
>
> You don't need a grant.
Not true, actually. As Mark Wooding has pointed out, you can't test
attacks (e.g., implement them) without implementing the cipher, and by
law, you're not allowed to implement a patented cipher without a grant.
You probably can't even implement parts of it, so forget your calculations
of the difference table for the S-boxes, for instance.
Since the whole *point* of the cipher contest is to practice analysis,
I can't see any reason to accept ciphers where analysis is prohibited.
------------------------------
Date: Fri, 02 Jun 2000 15:20:44 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Cost of SPACE -- going down!
Joseph Ashwood wrote:
> In the reality that I live in, we continually develop better algorithms,
> ones which take less time and less space than the ones before. We also
> continually develop better computers to run these algorithms.
Case in point: today I learned about a report at a recent meeting of the
American Chemical Society in reference to information storage. Previously the
record for persistent information density was 3 gigabits/sq in. established by
IBM last year using cobalt magnetic media.
G. Christou of Indiana Univ. reported that using manganese allows for storage on
individual molecules with a density of 30 terabits/sq in.
Four orders of magnitude. About a year of elapsed time. Put that in your
crystal ball and gaze upon it.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Good ways to test.
Date: Fri, 02 Jun 2000 19:10:48 GMT
On Fri, 02 Jun 2000 11:25:32 -0700, in
<[EMAIL PROTECTED]>, in sci.crypt tomstd
<[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry
>Ritter) wrote:
>>[...]
>>Unfortunately, cryptanalysts can't know the strength of a system
>>unless they can break it. If they can't break it, the system
>may be
>>weak anyway.
>
>Conversely just because they can break it, doesn't mean it's
>insecure.
No, it means that they then know a true upper bound on the strength,
and so can make their decision in the presence of data -- as opposed,
say, to superstition.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
Subject: Re: TC3 Update
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 02 Jun 2000 12:09:53 -0700
In article <8h8vtp$p6m$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David A. Wagner) wrote:
>In article <[EMAIL PROTECTED]>,
>tomstd <[EMAIL PROTECTED]> wrote:
>> (multiplicative inverse in the galois field 2^128 mod p)
>
>Err, I can't see how to assign any meaning to that phrase.
>Did you perhaps mean GF(2^128)? GF(p)? something else?
>
Sorry... I am calculating the inverse of the input in GF(p)
where p is a degree-128 polynomial (with coefficients taken mod
2).
How should I have said that?
Basically it's
S(x) = x^-1 mod p
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: "B Labour" <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.politics.uk,alt.security.scramdisk,uk.telecom
Subject: Home Office climbdown on Reuters RIP Bill story
Date: Fri, 2 Jun 2000 20:14:32 +0100
from http://www.fipr.org/rip
News Release - Thursday 1st June 2000
FOR IMMEDIATE USE
See RIP Information centre at www.fipr.org/rip
...for references and live links
and Parliamentary coverage http://www.fipr.org/rip/parliament.html
CLIMBDOWN by Home Office Press Office
=======================================================================
RETRACTS quote that RIP requires proof that key "deliberately withheld"
=======================================================================
In a humiliating climb down, the Press Office of the Home Office has been
obliged formally to retract a quote given to a Reuters reporter covering the
UK's intensely controversial Regulation of Investigatory Powers (RIP) Bill.
The Reuters story
http://news.excite.com/news/r/000526/08/net-internet-crime
also syndicated to
http://www.wired.com/news/politics/0%2C1283%2C36614%2C00.html
...had quoted an unidentified Home Office spokesman as saying that the "the
police have to prove the encryption key was deliberately withheld".
This simple sentence encapsulates the crucial issue - the government has
insisted repeatedly that the burden is on the DEFENCE to show "on the
balance of probabilities" (http://www.fipr.org/rip/burdenproof.html) that a
key has been lost or forgotten to avoid conviction. A reasonable doubt will
not acquit
- if the court believes you are lying 51%, you go to jail for two
years. The Government has twice rejected Opposition amendments which *would*
have required the prosecution to show "mens rea" - a guilty mind - i.e. that
a key HAD been DELIBERATELY withheld
(http://www.fipr.org/rip/ReverseCrux.htm)
The Home Office's statement was therefore the most egregious
misrepresentation imaginable of the actual policy.
FIPR queried the report with Reuters the following day, and the journalist
confirmed that he still had a note of the quotation as a verbatim statement,
and offered to put these objections to the Home Office spokesperson on
FIPR's behalf. The journalist subsequently told FIPR that the spokesman
stood by his statement and wished to alter nothing.
FIPR made other enquiries and confirmed the identity of the spokesman as Tim
Watkinson, the press officer who has dealt with the RIP Bill since it was
published in January. In a telephone conversation on Wednesday 31st,
Mr.Watkinson confirmed to FIPR that he understood the reverse-burden issue
of the RIP Bill perfectly well, but had made no mistake. He could not
recollect whether he had used the words "deliberately withheld" but promised
FIPR he would not be using those words in future. He claimed that the last
conversation with the Reuters journalist had only been to confirm the story
"in general terms".
FIPR checked again with Reuters, who again put the issue to Mr.Watkinson on
Thursday 1st June - this time Mr.Watkinson retracted the "deliberately
withheld" quote, but admitted only to a "slight mis-brief" and "paraphrasing
in order to clarify the issues".
Reuters has agreed to re-write the story.
The Home Office Press Office can be contacted on +44 (020) 7273 4610
Caspar Bowden, director of Internet policy think-tank FIPR commented, "The
Home Office were given ample opportunity to discreetly withdraw an untenable
statement - their refusal smacks of desperation. What confidence can
journalists have in information provided by a Press Office that will peddle
a brazen falsehood, and issues only a grudging retraction after humiliating
exposure?"
------------------------------
Subject: Re: Question about Re: RSA/PK Question
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 02 Jun 2000 12:12:40 -0700
Essentially my last message about Moores Law was all fudged up.
Sorry for the nonce.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: Good ways to test.
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 02 Jun 2000 12:16:39 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry
Ritter) wrote:
>
>On Fri, 02 Jun 2000 11:25:32 -0700, in
><[EMAIL PROTECTED]>, in sci.crypt
tomstd
><[EMAIL PROTECTED]> wrote:
>
>>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry
>>Ritter) wrote:
>
>>>[...]
>>>Unfortunately, cryptanalysts can't know the strength of a
system
>>>unless they can break it. If they can't break it, the system
>>may be
>>>weak anyway.
>>
>>Conversely just because they can break it, doesn't mean it's
>>insecure.
>
>No, it means that they then know a true upper bound on the
strength,
>and so can make their decision in the presence of data -- as
opposed,
>say, to superstition.
What about provably secure block ciphers that use components
with well understood structures, say CAST sboxes?
Although I agree new attacks come out each yet (and I doubt this
argument will ever end), you have to draw a line and say "good
enough" I will use it. Otherwise crypto wouldn't be used
anywhere.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: TC3 Update
Date: Fri, 02 Jun 2000 19:07:42 GMT
In article <[EMAIL PROTECTED]>,
tomstd <[EMAIL PROTECTED]> wrote:
> I changed TC3 to use 128x128 sboxes (multiplicative inverse in
> the galois field 2^128 mod p) instead of the hybrid F function.
>
> With 4 rounds my cipher is provably secure against diff and
> linear attacks since the LP/DP max for both is 2^-126.
>
> I have a more complete "key schedule" to avoid weak keys.
>
> The cipher is slow, but conceptually simple and provably secure.
>
> It's at http://www.tomstdenis.com/tc3.c
>
> I am betting there is something I overlooked, so cutos to the
> first person to break it.
>
> Tom
>
Thank you. I'm glas to see that people are beginning
to consider other things in cryptography besides
just chosen plaintext attacks. Conceptual simplicity
*is* important and I'm glad you used it as a design
criterion.
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 02 Jun 2000 15:31:50 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Contest rule proposal
Mark Wooding wrote:
> On the subject of free lunches, though, isn't there something of the
> same sort in presenting your cipher, which you plan to cash from, for
> review and analysis from people in their spare time?
No. Given fair warning of the encumbrances a potential analyst can exercise
choice (FYI this is often called freedom) as to whether he devotes time to an
encumbered entry or not. Passing a rule against encumbered entries doesn't
hurt the potential entrant. It hurts (eliminates choice) the potential
analyst.
LOTS of rule making has this flavor. The fact that vendors can't sell beer
cold in Illinois doesn't hurt Coors Brewing Company, they simply sell their
wares in the other 49 states. The rule hurts the citizens of Illinois by
restricting their choices.
Laissez Faire means "Stop trying to help me!"
If *you* don't want to analyze encumbered ciphers, don't. Why would you want
to stop *me* from analyzing encumbered ciphers?
===================================
On second reading this post is a bit of a rant. My excuse is that I live in
NH because I like the license plates.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Self Shrinking LFSR
Date: Fri, 02 Jun 2000 19:23:08 GMT
On Fri, 02 Jun 2000 13:48:17 -0500, in
<[EMAIL PROTECTED]>, in sci.crypt Mike Rosing
<[EMAIL PROTECTED]> wrote:
>Scott Nelson wrote:
>[...]
>> It may take a /bit/ longer than a couple of weeks to brute
>> force the dense 32 bit ML sequences.
>
>It's not that hard. You can easily find if a polynomial is irreducible.
>To test if it's primitive, you need to see if x^(factors of p^n-1) = 1
>mod P. If so, it's not primitive. For p == 2, you only need 9 billion
>checks for brute force, so I'd think the whole thing can be done in
>a day on a reasonable PC.
Surely, any factoring of a deg-32 must include a factor of deg-16 or
less. We can generate a table of irreds up to deg-16 then scan
through the table doing poly divs. We don't need to check "even"
polys, of course, and might throw out polys with even numbers of
terms. That said, even recording the results is going to take some
real store. But if we could access 2^31 bits (268MB?), we could do a
sieve. I don't know how long any of this would take.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: TC3 Update
Date: 2 Jun 2000 12:19:56 -0700
In article <[EMAIL PROTECTED]>,
tomstd <[EMAIL PROTECTED]> wrote:
> Sorry... I am calculating the inverse of the input in GF(p)
> where p is a degree-128 polynomial (with coefficients taken mod
> 2).
Sorry, that still doesn't make any sense. You mean you are
calculating the inverse in GF(2^128) [*]. You might want to
read up on finite fields a bit more...
[*] It just so happens that one way to construct a finite field
(isomorphic to) GF(2^128) is by taking the ring of polynomials
with coefficients in GF(2) and quotienting it with the ideal
generated by some irreducible polynomial p of degree 128.
------------------------------
** 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
******************************
