Cryptography-Digest Digest #163, Volume #13 Wed, 15 Nov 00 16:13:01 EST
Contents:
Re: ECC help please (Bob Silverman)
Q: fast block ciphers (Lauri Pesonen)
Re: Why remote electronic voting is a bad idea (was voting through pgp)
([EMAIL PROTECTED])
Re: XORred zipfile chunks = random? (David Schwartz)
Re: Q: fast block ciphers (David Schwartz)
Re: Q: fast block ciphers (Paul Crowley)
Re: New record SNFS factorization (Bill Unruh)
Re: Q: fast block ciphers (Doug Kuhlman)
Re: so many fuss about impossibility to backtrace from MD to original text.
([EMAIL PROTECTED])
Re: Thoughts on the sci.crypt cipher contest ([EMAIL PROTECTED])
Re: Q: fast block ciphers (Stefan Lucks)
Re: New record SNFS factorization (John Myre)
Re: On an idea of John Savard (Mok-Kong Shen)
Re: On an idea of John Savard (Mok-Kong Shen)
Re: XORred zipfile chunks = random? ([EMAIL PROTECTED])
Re: New record SNFS factorization (Bob Silverman)
Re: stream ciphers based on LFSR (Simon Johnson)
Re: Thoughts on the sci.crypt cipher contest ("Paul Pires")
----------------------------------------------------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: ECC help please
Date: Wed, 15 Nov 2000 18:56:46 GMT
In article <[EMAIL PROTECTED]>,
> I know that Certicom has an implementation of ECC that you can
license, and
> that at least some part of its implementation is patented.
>
> I also know that RSA Security offers ECC as part of its BSAFE toolkit.
>
> My question is this: are these two ECC implementations
interoperable?
Somewhat. It depends on whether the Certicom implementation is
using point compression. If it does, then they are NOT inter-operable,
since we do NOT use point compression.
Why?
Because Certicom claims to have a patent on the technique.
> Also, could you grow your own ECC and have it be interoperable with
> Certicoms? Maybe it would run slower or something, but it would
still
> interoperate?
Same problem. Your code could not do point compression without
a license from Certicom.
--
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: Lauri Pesonen <[EMAIL PROTECTED]>
Subject: Q: fast block ciphers
Date: 15 Nov 2000 21:20:18 +0200
Hi,
I'm trying to figure out, which block cipher would fit my needs the
best. I'm in need of a very fast block cipher that could be used to encrypt
multiple (as many as possible) simultanious network streams. The system
would also use Matt Blaze's RKEP Protocol [1] (which requires a block
cipher instead of a stream cipher). The main point is that multiple streams
should be encrypted with as small a CPU load as possible. Decryption is not
all that performance sensitive (of course it's not a minus if decryption is
fast as well). The cipher should be strong in the present day as well as for,
let's say, the next five years.
I seem to remeber hearing from someone that blowfish is relatively
fast. Any faster block ciphers out there?
Thanks for all your help.
[1] Blaze, M., "High-Bandwith Encryption with Low-Bandwith Smartcards",
December 3, 1995.
--
Lauri
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto
Subject: Re: Why remote electronic voting is a bad idea (was voting through pgp)
Date: Wed, 15 Nov 2000 19:18:44 GMT
In article <[EMAIL PROTECTED]>,
Tommy the Terrorist <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]> Tim May,
> [EMAIL PROTECTED] writes:
> >> You've already heard of the so-called "electronic signatures",
right?
>
> >Voting protocols are about MUCH more than "digital signatures."
> >If this is not obvious to you, no point in further discussion.
> What I referred to as an "electronic signature" is the legally
> enforceable "electronic signature"
[snip things that are in no way addressed by the DigSig act]
Now that "Tommy" has expressed very clearly that he is confused on the
point, I will attempt to clarify.
First a protocol goes beyond just a signature. In this case the
protocol needs to contact a central server, negotiate secrecy with the
server, authenticate the server, transfer the vote in some commonly
agreed upon form, and assert that the person being claimed to vote
really did want that vote. That is the bare minimum, to meet the
requirements set forth by constitutional law there are a great many
more requirements. This goes so far beyond a digital signature, or
an "electronic signature" that one can barely see it's influence.
This conversation has dealt with many things that if you didn't even
understand the difference between digital signature and vote protocol,
you probably missed. There was a very large discussion about the
confliction of the requirements of anonymity and authenticity. There
was a great deal of discussion about attempts to meet both, and how
they have rather entirely failed to deliver one or both. There has been
the discussion about authenticity of the vote counter (almost certainly
the weak link) and attempting to determine if there is a solution. Etc,
etc. At no point would anybody with even the slightest clue about
security allow a signature that was so easily fraudulent as the
electronic signature law be used in voting, it would be equivalent to
maintaining the public polls but loosening the requirement that all you
needed to vote was to create a name that hadn't been entered in the log
yet.
Now as to what the electronic signature law actually does. It does not
present any requirement for a 3rd party, it does not require any
authentication, it is clearly written so that you can agree to
something you never see (let alone read) by clicking on an insecure,
fraudulently made webpage on a server you didn't even know you were
connected to, run by someone who doesn't even exist, and it's legally
enforcable. It is left to the court to sort out the problems. It is
certainly not suitable for much of anything until it's real power has
been determined by the courts, and a vote is NOT the way to do it.
Joe
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: XORred zipfile chunks = random?
Date: Wed, 15 Nov 2000 11:23:55 -0800
d wrote:
> > The only way to prove that a
> > source is good is to prove the source good*, a post mortem examination
> > can only tell you if it's bad.
> >
>
> *Isn't this a tautology?
No, it's really not. There are genuine cases where you can prove that
the output is random (or unpredictable to the extent required) because
you can prove that its source is random (or, more precisely,
unpredictable). Consider, for example, a device that measures the
radioactive decay of a source and outputs a '1' if a particle is
detected in less than the expected time and a '0' if one is detected in
more than the expected time.
Now this may not be perfectly unbiased. That depends upon the accuracy
of the computation of the expected time. However, because we know that
no attacker (who doesn't have direct access to the same source) can
predict its precise rate of decay, we know precisely what the limits are
on how predictable it is.
Is it perfect? No. But do we know that it has at least a certain
particular level of unpredictability? Yes. And as we all know, as long
as you have enough entropy in the input, you can easily massage it
(deterministically) to get output that has the exact qualities you need
(for example, unbiased to any desired level of accuracy).
The ideal situation is to have an unbroken chain of operations whose
parameters are well known and understood. That way you can present the
strongest possible argument that the output has the characteristics you
desire EVEN WITHOUT MEASURING THE OUTPUT. You should still test the
output, of course, but the test simply demonstrates that you've not made
an error. The test of output quality alone is NOT the validation.
One PRNG I wrote needed independent certification because it was going
to be used in some very sensitive applications. The certification
process consisted of three distinct steps:
1) Validation that the algorithms chosen can meet the requirements.
(Theoretical)
2) Validation that the algorithms chosen were correctly implemented.
(Code review)
3) Validation that the output passed tests for randomness to the
requires level. (Testing)
You can't skip the first step.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Q: fast block ciphers
Date: Wed, 15 Nov 2000 11:26:48 -0800
Lauri Pesonen wrote:
> I seem to remeber hearing from someone that blowfish is relatively
> fast. Any faster block ciphers out there?
The last time I compared speeds of encryption algorithms (on Pentium
hardware) RC4 was the fastest. I don't recally exactly which ciphers I
compared, but I know blowfish, DES, and RC2 were in there.
DS
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Q: fast block ciphers
Date: Wed, 15 Nov 2000 19:42:56 GMT
Lauri Pesonen wrote:
> I'm trying to figure out, which block cipher would fit my needs the
> best. I'm in need of a very fast block cipher that could be used to encrypt
> multiple (as many as possible) simultanious network streams.
I'm not sure how this second requirement affects the requirements; I
suppose it helps to have either a small key after expansion, or high key
agility. I'm starting to come across as the Rijndael fan club here, but
why not just use the AES, Rijndael, which is fast both on memory-rich
32-bit and memory-limited 8-bit processors?
I think it's fair to argue that the whole point of having an AES is that
every application whose needs AES meets should use it. It sounds like
yours is one such.
http://www.rijndael.com/
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: sci.math
Subject: Re: New record SNFS factorization
Date: 15 Nov 2000 19:58:23 GMT
In <[EMAIL PROTECTED]> "Herman J.J. te Riele" <[EMAIL PROTECTED]> writes:
]----------------------------
]233-digit SNFS factorization
]----------------------------
]``The Cabal'' announces the completion, on November 14, 2000,
]of the factorization with the Special Number Field Sieve (SNFS)
]of the 233-digit Cunningham number 2,773+ = 2^773 + 1 into the product
]of 3, 533371 and three primes of 55, 71, and 102 digits, respectively.
]This establishes a new record for the Special Number Field Sieve SNFS.
Well, I would not call this factoring a 233 digit number, maybe a 227
digit number. Those factors of 3 and 533371 are trivial. Otherwise I
could say that I just factored a 10^12 digit number, namely 10^(10^12).
(Not that factoring a 227 digit number is not in itself very
impressive-- it is just that overplaying an accomplishment is not good
tactics).
------------------------------
From: Doug Kuhlman <[EMAIL PROTECTED]>
Subject: Re: Q: fast block ciphers
Date: Wed, 15 Nov 2000 13:42:02 -0600
It's hard to beat Rijndael, the new AES. Low memory load and fast.
Probably your best bet...at least as a starting point.
Doug
P.S. For real advice, I'd consult something (someone) a bit higher
profile than a newsgroup. You'll find some good advice but some
snake-oil, too.
Lauri Pesonen wrote:
>
> Hi,
>
> I'm trying to figure out, which block cipher would fit my needs the
> best. I'm in need of a very fast block cipher that could be used to encrypt
> multiple (as many as possible) simultanious network streams. The system
> would also use Matt Blaze's RKEP Protocol [1] (which requires a block
> cipher instead of a stream cipher). The main point is that multiple streams
> should be encrypted with as small a CPU load as possible. Decryption is not
> all that performance sensitive (of course it's not a minus if decryption is
> fast as well). The cipher should be strong in the present day as well as for,
> let's say, the next five years.
>
> I seem to remeber hearing from someone that blowfish is relatively
> fast. Any faster block ciphers out there?
>
> Thanks for all your help.
>
> [1] Blaze, M., "High-Bandwith Encryption with Low-Bandwith Smartcards",
> December 3, 1995.
>
> --
> Lauri
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: so many fuss about impossibility to backtrace from MD to original text.
Date: Wed, 15 Nov 2000 19:50:41 GMT
In article <[EMAIL PROTECTED]>,
Ariel Burbaickij <[EMAIL PROTECTED]> wrote:
> Have we indeed to do with infinite many original messages to do
that maps
> to one and the same digest ?At least in theory.If so why?
Actually there are implicit assumptions made in the hash function about
the maximum length, whcih in turn dictates the maximum number of
messages to a finite number. For example SHA-256 effectively limits the
size of the input to 2^64 bits, this means that there are at most
2^2^64 messages that can be hashed using sha-256. So there won't be
infinite collision.
> why the fuss about the length of message digest.
Because of the work requirements to create a false hash. Because of the
Birthday Paradox (if you bring random people into a room, you can only
have 20 of them on average before 2 of them have the same birthday) the
security is the square root of the output space. When dealing with
binary this is an exceedingly easy value to calculate, SHA-256 has 256-
bits in the hash, divide it by 2, it offers 128-bits worth of strength.
This value is very important, because it determines the average amount
of work an attacker will be forced to perform in order to generate a
collision of the hash.
The other important value is the work after cryptanalysis. This is
vitally important, because it determines the actual work needed to
generate a collision in the hash, MD4 is a very good example in this
regard, it generates a 128-bit hash, which should offer 64-bits worth
of security, that is except that an attack has been found against it
whcih reduces the work significantly, making it a much weaker hash.
I suppose it's also worth briefly explaining why we chose the work
values as a community that we have chosen. It's a combination of
demonstrated power, estimates of cost, murphy's law, and a mess of
other factors. Taking this extremely rough estimate we add to it a
safety factor for protection over the next N years (N is typically 20).
We have a demonstration that 56-bits is weak (RSA DES Challenge, 22
hours), and that 64-bits is fairly strong but vulnerable (Another RSA
challenge, but with RC5). We have evidence that the NSA wants us to use
80-bit security (SKIPJACK). We trust the NSA to tell us that they can
break something by telling us to use it. Basically we use this to
estimate the power of a very well funded agency (like the NSA) to break
crypto, we have placed our guess that they can debatably break 80-bits,
so exceeding that we are safe. Now we add in the safety factors, the
factor of the attacks that we haven't found yet, the we don't know how
good they are factor, each of these adds a few bits, and we come to
roughly 95-100 bits, the next convenient stop is 128-bits. Depending on
who you expect to attack you may require much smaller amounts, or you
may trust 3DES (112 bits or 168 bits) more, so there's a lot of
guessing room.
Joe
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Thoughts on the sci.crypt cipher contest
Date: Wed, 15 Nov 2000 20:14:35 GMT
===== Original Message =====
From: "Paul Pires" <[EMAIL PROTECTED]>
Newsgroups: sci.crypt
Sent: Wednesday, November 15, 2000 11:01 AM
Subject: Re: Thoughts on the sci.crypt cipher contest
[snip the entire post]
Of course I'd publish test vectors, and it will be either self-evident
how to perform the decryption (Fiestel cipher is a good example) or I
would providedecryption pseudo-code. And my test vectors typically
include exact listings for each variable after each step, and would be
for both encryption and decryption. So there's no worries there, my
problem is the source code/executable, not with the algorithm. I'd
still like to see this thing happen, the last one was overly restricted
INO, mainly because it didn't present options to build something truly
secure, or useful because of it's fresh novelty. IIRC wasn't nearly
every cipher a plain Feistel?
Joe
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Stefan Lucks <[EMAIL PROTECTED]>
Subject: Re: Q: fast block ciphers
Date: Wed, 15 Nov 2000 21:16:04 +0100
On 15 Nov 2000, Lauri Pesonen wrote:
> I'm trying to figure out, which block cipher would fit my needs the
> best. I'm in need of a very fast block cipher that could be used to encrypt
> multiple (as many as possible) simultanious network streams. The system
> would also use Matt Blaze's RKEP Protocol [1] (which requires a block
> cipher instead of a stream cipher). The main point is that multiple streams
> should be encrypted with as small a CPU load as possible. Decryption is not
> all that performance sensitive (of course it's not a minus if decryption is
> fast as well). The cipher should be strong in the present day as well as for,
> let's say, the next five years.
>
> I seem to remeber hearing from someone that blowfish is relatively
> fast. Any faster block ciphers out there?
Blowfish, while quite fast by itself, suffers from a very slow key
schedule, generating some 4 KBytes of key dependent S-Boxes. It is fast if
you can use the same key to encrypt a long stream of data, but is is
*extremely* *slow* at switching between different streams of data. (Except
you can afford to store more than 4 KBytes of context for each data
stream.)
Perhaps you should use Rijndael, the "Advanced Encryption Standard" (AES)
for that purpose.
Oh, the RKEP from Blaze has some serious security problems, see [3]. Don't
use the RKEP. See [2-4] for better choices. [3,4] can be found at my web
site, and [2] can probably be found at one of the authors' web sites.
> [1] Blaze, M., "High-Bandwidth Encryption with Low-Bandwidth Smartcards",
> December 3, 1995.
Fast Software Encryption 1996, Springer LNCS 1039, 33--40.
[2] M. Blaze, J. Feigenbaum, M. Naor, "A Formal Treatment of Remotely
Keyed Encryption", Eurocrypt '98, Springer LNCS.
[3] S. Lucks, "On the Security of Remotely Keyed Encryption",
Fast Software Encryption 1997, Springer LNCS 1267, 219--229.
[4] S. Lucks, "Accelerated Remotely Keyed Encryption",
Fast Software Encryption 1999, Springer LNCS.
--
Stefan Lucks Th. Informatik, Univ. Mannheim, 68131 Mannheim, Germany
e-mail: [EMAIL PROTECTED]
home: http://th.informatik.uni-mannheim.de/people/lucks/
====== I love the smell of Cryptanalysis in the morning! ======
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: New record SNFS factorization
Date: Wed, 15 Nov 2000 13:27:25 -0700
Bill Unruh wrote:
<snip>
> ]``The Cabal'' announces the completion, on November 14, 2000,
> ]of the factorization with the Special Number Field Sieve (SNFS)
> ]of the 233-digit Cunningham number 2,773+ = 2^773 + 1 into the product
> ]of 3, 533371 and three primes of 55, 71, and 102 digits, respectively.
> ]This establishes a new record for the Special Number Field Sieve SNFS.
>
> Well, I would not call this factoring a 233 digit number, maybe a 227
> digit number. Those factors of 3 and 533371 are trivial. Otherwise I
> could say that I just factored a 10^12 digit number, namely 10^(10^12).
> (Not that factoring a 227 digit number is not in itself very
> impressive-- it is just that overplaying an accomplishment is not good
> tactics).
I think it's a little low to truncate a single sentence claim
in order to complain about the truncation "overplaying an
accomplishment." The quoted announcement isn't exaggerated
or misleading at all. I'll grant you that some idiots will
stop reading half way through, but that's their fault.
JM
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On an idea of John Savard
Date: Wed, 15 Nov 2000 21:37:52 +0100
David Schwartz wrote:
>
> Mok-Kong Shen wrote:
>
> > > No, I'm saying that if you create a cipher where the number of rounds
> > > is negotiable, you need a secure negotiation protocol. If you're
> > > creating a cipher where the number of rounds must be chosen in advance,
> > > then you might as well just choose a number.
>
> > Well, you could say that it needs a protocol. I view it
> > in a more simple perspective. One could use a longer key
> > (which one needs anyway) with the additional part to
> > determine the rounds (or eventual other parameters for
> > variability of the encryption scheme).
>
> I'm still not sure that's enough to ensure that you don't create new
> vulnerabilities. However, it is enough in a situation where you use a
> secure method to exchange the key, say by the use of MITM-proof (signed)
> asymmetric encryption. Otherwise, you have a situation where you are
> guaranteed that there are weak keys, and you have to do a lot of work to
> prove that this can't be exploited.
There is certainly the possibility of existence of weak
keys for the (new) combined cipher. A study or a proof
of the issue would understandably be more difficult than
for the individual ciphers alone. I admit that, without
that, one unavoidably steps into a domain of subjectivity.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On an idea of John Savard
Date: Wed, 15 Nov 2000 21:38:00 +0100
Tom St Denis wrote:
>
> I mean complete as in "complete". It's an actual term when defining
> data flow networks. Perhaps you should look it up.
My knowledge of CS is unfortunately not good enough to
research into that issue with ease. The one concept of
'completeness' I happen to know is about graph theory
which has to do with networks, as far as I am aware. But
I don't think that notion could be applied to the case
of DES in any sense. May I ask you for some help here?
It would broaden my knowledge horizon a bit. Thanks
in advance.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: XORred zipfile chunks = random?
Date: Wed, 15 Nov 2000 20:35:59 GMT
d said:
> Kitchen sink or not, XORing zipfiles seems to work. Prove me wrong :-)
That's easy. What is the source of entropy? Random noise from a
soundcard. I point to Ritter's page on Random Number sources
(http://www.io.com/~ritter/NOISE/NOISRC.HTM) as evidence that noise
sampled by a sound card is not purely random. Additionally I claim that
due to the fact that the sampling done by the sound card varies based
on the exact frequency of the input, any randomness that is in the
incoming noise is decreased, resulting in even more surely a stream
that is not purely random. I claim that the compression offered by
PKZIP does not perfectly distill the entropy of a semi-random noise
source (as evidenced by the fact that those same samples can be
expressed smaller by more optimal compression schemes). Based on these
claims, there is no possible way that the output of the system can
offer perfect entropy. Without being perfectly entropic there is no
possible way to have a stream that is purely random.
If you would care to debate these claims please feel free.
Joe
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: New record SNFS factorization
Date: Wed, 15 Nov 2000 20:40:14 GMT
In article <8uupsv$ju3$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Bill Unruh) wrote:
> ]``The Cabal'' announces the completion, on November 14, 2000,
> ]of the factorization with the Special Number Field Sieve (SNFS)
> ]of the 233-digit Cunningham number 2,773+ = 2^773 + 1 into the
product
> ]of 3, 533371 and three primes of 55, 71, and 102 digits,
respectively.
> ]This establishes a new record for the Special Number Field Sieve
SNFS.
>
> Well, I would not call this factoring a 233 digit number, maybe a 227
> digit number.
Fortunately, what *you* would call it is irrelevant.
> Those factors of 3 and 533371 are trivial. Otherwise I
> could say that I just factored a 10^12 digit number, namely 10^
(10^12).
They factored the number 2^773 + 1. This has 233 digits. It does
not matter to the algorithm they used that 2^773 + 1 has two
small factors. The algorithm they used (SNFS) makes no use of this
fact whatsoever. It factors the full number 2^773+1 and not the
composite cofactor one obtains by dividing out the small factors.
> (Not that factoring a 227 digit number is not in itself very
> impressive-- it is just that overplaying an accomplishment is not good
> tactics).
Criticizing someone else's work without knowing what you are talking
about is also not good tactics. They did not overplay the result.
--
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: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: stream ciphers based on LFSR
Date: Wed, 15 Nov 2000 20:49:19 GMT
In article <8uujck$hr9$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <3a12be3e$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > Hi
> >
> > I'm new here
> >
> > Could you tell me where can I find more detail, online information
> about
> > stream ciphers based on The LFSR's
>
> "on The LFSR's" perhaps you meant "based on LFSR's"... either case
> there are quite a bit. Check out the Handbook of Applied Crypto.
>
> The most secure so far is the shrinking generator when a dense
feedback
> scheme is used.
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Well which shrinking generator? I would presume this is the self-
shrinking version..... but there also exists the 'shrinking generator'
which uses two LFSRs, instead of just the one.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Thoughts on the sci.crypt cipher contest
Date: Wed, 15 Nov 2000 13:04:45 -0800
<[EMAIL PROTECTED]> wrote in message news:8uuqr3$op8$[EMAIL PROTECTED]...
>
>
> ----- Original Message -----
> From: "Paul Pires" <[EMAIL PROTECTED]>
> Newsgroups: sci.crypt
> Sent: Wednesday, November 15, 2000 11:01 AM
> Subject: Re: Thoughts on the sci.crypt cipher contest
> [snip the entire post]
>
> Of course I'd publish test vectors, and it will be either self-evident
> how to perform the decryption (Fiestel cipher is a good example) or I
> would providedecryption pseudo-code. And my test vectors typically
> include exact listings for each variable after each step, and would be
> for both encryption and decryption. So there's no worries there, my
> problem is the source code/executable, not with the algorithm. I'd
> still like to see this thing happen, the last one was overly restricted
> INO, mainly because it didn't present options to build something truly
> secure, or useful because of it's fresh novelty. IIRC wasn't nearly
> every cipher a plain Feistel?
> Joe
Nearly :-)
Yours truly scored a clean miss with Chutzpah.
Live and learn.
Overly restrictive? It seemed to have clear and simple
requirements to me. I thought that setting up some
different comment criteria that have an on-going measure
might have helped to maintain interest. Just leaving it
alone if no-one publishes a break is hard to root for.
Maybe a comment field of hints or suspicions that newbies
can work on to prove or disprove. Limiting
response to a clean break cuts down too much on the
traffic. I Personally liked Borris recounting of why he
wrote Mmbooze. What made a person set off in a
particular direction can be interesting regardless of
where they ended up.
Those not challenged were more likely to be difficult to
grasp than "good". Feeding this back for clarification and
revision might have helped. Seems that the pot needs to
be churned regularly or it scorches on the bottom and
scums over at the top.
Paul
------------------------------
** 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
******************************
