Cryptography-Digest Digest #162, Volume #13 Wed, 15 Nov 00 14:13:01 EST
Contents:
Re: hardware RNG's (Guy Macon)
Re: Algorithm with minimum RAM usage? (Runu Knips)
Re: On an idea of John Savard (Tom St Denis)
Re: Learning Differential and Linear Cryptanalysis? (Tom St Denis)
Re: sci.crypt archive ([EMAIL PROTECTED])
Re: The SHAs (John Myre)
Re: The SHAs (Bob Deblier)
Re: vote buying... ("Frog2000")
Re: The SHAs ("kihdip")
New record SNFS factorization ("Herman J.J. te Riele")
Re: DES advice ([EMAIL PROTECTED])
stream ciphers based on LFSR (Konrad Hoszowski)
Re: New record SNFS factorization (Tom St Denis)
Re: hardware RNG's (Terry Ritter)
ECC help please ("James Russell")
Re: stream ciphers based on LFSR (Tom St Denis)
Re: On an idea of John Savard (David Schwartz)
Re: stream ciphers based on LFSR (Mike Rosing)
Re: XORred zipfile chunks = random? (d)
Re: hardware RNG's (David Schwartz)
Re: ECC help please (Mike Rosing)
Re: Thoughts on the sci.crypt cipher contest ("Paul Pires")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: hardware RNG's
Date: 15 Nov 2000 11:14:24 GMT
David Schwartz wrote:
>
>Terry Ritter wrote:
>
>> It is better to say that an "unpredictable" bit can be predicted
>> correctly only 50 percent of the time. Any value other than this
>> involves some amount of useful prediction. Useful cryptographic
>> weakness does not require 100 percent predictability.
>
>Probably no system imaginable can ensure meet the 50% level of perfect
>unpredictability. So while this might be a useful definition
>theoretically, it's useful in practice. Heck, by this definition, RC5's
>PRNG isn't unpredictable. Accepting this definition would be as
>senseless is accepting a definition of 'secure' for which only an OTP
>could qualify.
That's because this discussion is conflating infinity with very
large and zero with very small, and language is being used that
fails to accurately specify whether perfect or relative definitions
of security/predictability/randomness are being used.
No one has proven perfect unpredictability or perfect security.
I advise using relative terms like "very difficult to predict"
and "highly secure" instead of absolute terms (or worse, terms
which some folks interpret as absolute and others as relative)
and most of the disagreements you two express will evaporate.
( You *can* achieve zero security and perfect predictability... <grin> )
------------------------------
Date: Wed, 15 Nov 2000 13:01:49 +0100
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Algorithm with minimum RAM usage?
Paul Rubin wrote:
> [EMAIL PROTECTED] (Guy Macon) writes:
> > >Skipjack has 64 bit blocks and a (very low) 80 bit key size.
> > >
> > >Too, Skipjack is from the NSA. In fact, it is the first algorithm ever
> > >published by the NSA. In fact, it was never intended to get published.
> >
> > Ah. I see. Looks like Rijndael is the best choice if I want strong
> > encryption in minimum RAM.
>
> I wouldn't call 80 bits a very low key size.
Maybe you would call it different but you mean the same thing as I. It
is the lowest keysize one can currently trust.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: On an idea of John Savard
Date: Wed, 15 Nov 2000 12:15:41 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> Tom St Denis wrote:
> >
> [snip]
> > Note that in DES two rounds are not "complete".
>
> Sorry, I don't understand what you meant. DES repeats
> its cycles (two rounds) eight times. Do you mean
> 'complete' by 'having sufficient strength' or 'as
> specified in the standard' or something else?
I mean complete as in "complete". It's an actual term when defining
data flow networks. Perhaps you should look it up.
--- the answer ---
At anyrate it refers to the affect of every bit affecting every other
bit. DES needs at least five rounds before it is complete, therefore
two rounds although they form a cycle are not complete.
--- the answer ---
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Learning Differential and Linear Cryptanalysis?
Date: Wed, 15 Nov 2000 12:17:55 GMT
In article <8ut146$1jo$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
> Simon Johnson wrote:
> >Where can i find refrence material, books etc. with a clear and
consise
> >explanation of these two attacks?
>
> You could start with Bruce Schneier's description in Dr. Dobb's
Journal
> (check www.counterpane.com). Then, read _Differential Cryptanalysis
of
> the Data Encryption Standard_ (Biham and Shamir), if you can find it.
Dr Biham's website has most of his "interesting" papers. They're not
particularly hard to find.
BTW is my previous reply in this thread accurate? (my generic
explanations). I want to know if *I* understand the basics as well! :-)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: sci.crypt archive
Date: Wed, 15 Nov 2000 13:33:51 GMT
Please follow the url : <http://www.exit109.com/~jeremy/news/deja.html>
You will see there is already a petition to deja.com with over 2000 sigs
In article <8utfo0$kdk$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> "Thomas J. Boschloo" <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] wrote:
> > >
> > > Does anyone know where I can find an archive of sci.crypt postings
> from
> > > 1998-1999? The ftp sites listed in the FAQ only go up to 1997 as
> far as
> > > I can see, and deja.com only gives access to posts from sometime
in
> 1999
> > > onwards.
> >
> > I thought this at first too, but deja has older articles online. You
> > just have to include a date at the bottom of your form. If your
search
> > turns up nothing, you are given the option to search in an older
> > database
> As far as I can see, the archive of messages before May 1999 is not
> available from Deja, and hasn't been for some time. So there is a gap
> between sometime in 1997 and May 1999 which doesn't seem to be filled
> by any online archive :-(. Unless someone out there knows different
...
>
> Chris
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: The SHAs
Date: Wed, 15 Nov 2000 07:19:49 -0700
David Crick wrote:
>
> If it helps, the Sha-1 sum of the million-a file I'm using is:
>
> milliona.txt: 34AA 973C D4C4 DAA4 F61E EB2B DBAD 2731 6534 016F
>
> If someone can confirm this Sha-1 result then I know I've got a
> good file to be testing against!
Well, at least that agrees with the result in FIPS-180 (it's on
the very last page). I suppose you knew this already, but see
http://csrc.nist.gov/fips/fip180-1.pdf
or
http://csrc.nist.gov/fips/fip180-1.txt
JM
------------------------------
From: Bob Deblier <[EMAIL PROTECTED]>
Subject: Re: The SHAs
Date: Wed, 15 Nov 2000 15:41:53 +0100
kihdip wrote:
> Sorry for asking a (bit) different question in this thread, but reading it
> made me wonder:
>
> We're often discussing performance of cryptographic algorithms - but what
> about hash algorithms ??
>
> A hash algorithm is supposed to be fast (per definition), but how fast is
> for instance a SHA-1 ?? (f.ex. compared to a DES or 3xDES implementation on
> the same platform)
>
> Kim
I've written an SHA-1 implementation for the BeeCrypt cryptography library
(with assembler implementations for i586/i686), and I have extensive benchmark
results in the download (Note: version 1.1.3 of the library hasn't officially
been released yet). I'll post a snippet here, under the disclaimer that all
speeds are approximate and your mileage may vary slightly:
SHA-1:
BeeCrypt 1.1.3 | gcc-2.95.3 | Mandrake Linux 7.1 | Pentium III 800
| 4 GB: 39.00 MB/sec
BeeCrypt 1.1.3 | gcc-2.95.2 | FreeBSD 4.1 | Alpha EV6 667
| 2 GB: 25.00 MB/sec
BeeCrypt 1.1.3 | Visual C 6.0 | Windows 2000 | Pentium III 450 |
128 MB: 19.73 MB/sec
BeeCrypt 1.1.3 | Forte C 6.0 | Solaris 8 | Pentium III 450 |
128 MB: 19.50 MB/sec
BeeCrypt 1.1.3 | gcc-2.95.2 | Yellow Dog Linux 1.2 | PowerPC 604 166
| 96 MB: 9.50 MB/sec
BeeCrypt 1.1.3 | Workshop C 4.2 | Solaris 2.7 | UltraSparc 143 |
128 MB: 5.35 MB/sec
I also have speeds for MD5 and SHA-256, though I don't have assembler
optimizations for those yet.
Sincerely
Bob Deblier
Virtual Unlimited
------------------------------
From: "Frog2000" <[EMAIL PROTECTED]>
Subject: Re: vote buying...
Date: Wed, 15 Nov 2000 10:18:56 -0500
"zapzing" <[EMAIL PROTECTED]> wrote in message
news:8usakb$ne9$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > Kristopher Johnson wrote:
> >
> > > "Your vote" is not something you own; it is a privilege granted to
> you by
> > > the government, and the government can enforce whatever restrictions
> they
> > > want upon it. The government wants people to vote based upon their
> > > consciences, and not based upon the highest bid they've received.
> >
> > For many people, there is no difference. How do you plan to enforce
> this. If
> > a candidate promises to give money to a large group of people for
> voting, how
> > is this to be stopped? (Social Security, Medicare, for example.) How
> are
> > candidates promises any different from vote buying. How have they ever
> been?
> >
>
> You can't stop it. That is why democracy
> will collapse, as all systems eventually
> must.
That is an opinion based on pesimism, and not backed up by fact.
>
> --
> Void where prohibited by law.
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: "kihdip" <[EMAIL PROTECTED]>
Subject: Re: The SHAs
Date: Wed, 15 Nov 2000 16:20:30 +0100
Thanks,
Although: Is it Mbytes or Mbits ?
Kim
------------------------------
From: "Herman J.J. te Riele" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: New record SNFS factorization
Date: Wed, 15 Nov 2000 15:25:17 GMT
============================
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.
The previous SNFS record was the 211-digit repunit number
10,211- = (10^211 - 1)/9, factored on April 8, 1999, also by the Cabal.
Details are available from: ftp://ftp.cwi.nl/pub/herman/SNFSrecords/SNFS-233.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DES advice
Date: Wed, 15 Nov 2000 15:53:28 GMT
I wrote a DES implementation using Excel. It shows ever bit value in a
DES encrypt for ever step of the algorithm and each round. You input
the key and the data and use the spreadsheet to verify each step. Send
me your e-mail address to [EMAIL PROTECTED] and I will send you
the file. All are welcome to respond.
In article <pNYP5.89215$[EMAIL PROTECTED]>,
"Bob Luking" <[EMAIL PROTECTED]> wrote:
> Hi, all. Confessions of a crypto novice:
>
> I've written a program to encrypt using DES. The first piece of code
was in
> Verilog for a
> hardware encryption engine. The second was in Visual Basic to
validate the
> hardware.
> The outputs match.
>
> Unfortunately, the ciphertext is incorrect (according to FIPS 81).
Somehow,
> my interpretation
> of the DES specification is lacking...
>
> So, if anyone has, at their fingertips, a DES engine written in some
> language with which they
> can (very easily) dump out the L,R intermediate rounds, it would go a
long
> way towards helping
> me debug this thing, and earn my eternal thanks.
>
> Meanwhile, I'm off to the store to buy a C compiler so that I can
grab some
> freeware off the web
> and maybe figure this out for myself. It'll be good practice...
>
> Thanks,
>
> Bob
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Konrad Hoszowski <[EMAIL PROTECTED]>
Subject: stream ciphers based on LFSR
Reply-To: [EMAIL PROTECTED]
Date: Wed, 15 Nov 2000 17:44:20 +0100
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
Thanks
============
Konrad Hoszowski
[EMAIL PROTECTED]
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: New record SNFS factorization
Date: Wed, 15 Nov 2000 16:55:47 GMT
In article <[EMAIL PROTECTED]>,
"Herman J.J. te Riele" <[EMAIL PROTECTED]> wrote:
> ----------------------------
> 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.
>
> The previous SNFS record was the 211-digit repunit number
> 10,211- = (10^211 - 1)/9, factored on April 8, 1999, also by the
Cabal.
>
> Details are available from:
ftp://ftp.cwi.nl/pub/herman/SNFSrecords/SNFS-233.
Congradulations for the team responsible :-)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: hardware RNG's
Date: Wed, 15 Nov 2000 17:35:27 GMT
On 15 Nov 2000 11:14:24 GMT, in <8utr6g$[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] (Guy Macon) wrote:
>[...]
>No one has proven perfect unpredictability or perfect security.
>I advise using relative terms like "very difficult to predict"
>and "highly secure" instead of absolute terms (or worse, terms
>which some folks interpret as absolute and others as relative)
>and most of the disagreements you two express will evaporate.
That is poor advice. The reason for having an absolute reference is
that it has a possibility of being measured.
Randomness can only be described in statistical terms. But if any
process consistently can predict bits with better than 50 percent
probability, a non-randomness -- a weakness -- has been found.
No practical process or test can find every kind of sequence
correlation. But if we somehow do make a process which predicts, we
can confirm that, and measure how close it comes. Then we can try
various other things and see *by* *how* *much* each improves the
prediction. That is quantitative science.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] ("James Russell")
Subject: ECC help please
Date: 15 Nov 2000 18:56:05 +0100
I have what I think is a very simple question, but I know next to nothing
about cryptography, so please forgive me if it's really stupid.
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?
Could someone who is using Certicom's version talk securely with someone
using RSA's version?
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?
Thanks for any help you can provide.
James
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
--
Posted from [206.156.202.110] by way of f96.law10.hotmail.com [64.4.15.96]
via Mailgate.ORG Server - http://www.Mailgate.ORG
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: stream ciphers based on LFSR
Date: Wed, 15 Nov 2000 18:07:23 GMT
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.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: On an idea of John Savard
Date: Wed, 15 Nov 2000 10:30:08 -0800
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.
DS
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: stream ciphers based on LFSR
Date: Wed, 15 Nov 2000 12:40:37 -0600
Konrad Hoszowski wrote:
>
> Could you tell me where can I find more detail, online information about
> stream ciphers based on The LFSR's
Go here http://www.io.com/~ritter/CRYPHTML.HTM
and do a search for "LFSR stream cipher", I got 2 pages worth from that
site alone.
Patience, persistence, truth,
Dr. mike
------------------------------
From: d <[EMAIL PROTECTED]>
Subject: Re: XORred zipfile chunks = random?
Date: Wed, 15 Nov 2000 18:33:41 GMT
In article <8us6rl$k06$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> Jim wrote:
> [snipped up one side and down the other]
> I'm just going to address your rather glaring errors here.
>
> 1st error: That 2 compressed XORd CDs are suitable as a OTP
> The truth is that a OTP requires _absolute_ randomness,
> there is no such measurement as "good enough" Even worse using PKZIP
is
> probably one of the worst possibilities, if you really want to use a
> method like that what you need to do is grab something that generates
> good random numbers, ARCFOUR, Yarrow, Octillo, CTR mode encryption
> pads, etc. Use those, the PKZIP encryption is rather easily broken.
>
Please define "_absolute_ randomness" - You assume that everyone agrees
that there is such a thing, and what it is. I would suggest that "good
enough" is the _only_ kind of randomness available: that which passes
all tests.
You miss the point entirely about PKZIP. It is merely used to achieve
approximate *uniformity* (one of the generally accepted criteria of
r'ness). No one is suggesting that the resulting randomness relies on
the (un)breakability of password-protected zipfiles - I don't even see
the neccessity to use passwords, plain old compression is enough.
Either zip format (with or without header and footer) will fail DIEHARD.
The important advantage of pkzip, winzip, gzip etc. is their ubiquity.
Rather, it is the _XORing_ of the files that achieves the
*unpredictabilty* (another randomness criterion) - I would do this more
than once though, due to the only approximate uniformity of bits in a
zipfile.
> 2nd error: the implication that scramdisk is superior to OTP
> The truth is that OTP is absolutely secure, Scramdisk only
> uses the best available, these are entirely different realms of
> strength. Basically if you want to hide something from God (or Allah
or
> the Goddes or the Universe, pick whatever you prefer) you use a OTP,
> because he/she/it/they can break anything else
>
Your above point is quite reasonable, _except_ that there was no such
implication made. I understand the original point to imply that it is
better to XOR two files that already pass DIEHARD (see my above point) -
though as long as the sources are *unrecreatable* (another randomness
criterion), what does it matter?
As pointed out elsewhere, the (obvious) weakness is that using audio CD
tracks can severely limit the search space of an attacker. Better to
use large throwaway files.
> 3rd error: DIEHARD is good enough to certify a pRNG
> The truth is that DIEHARD will only tell you if your xRNG
is
> bad, it can't tell you if it's good.
So true. But _no_ test can prove randomness - which tests are better
than DIEHARD?
> 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?
> Those are the 3 most glaring errors I saw.
> Joe
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
BTW, as pointed out elsewhere, the very act of sampling a 'true'
physical RNG introduces nonrandomness. Some post-processing will always
be necessary. The function of a 'true' RNG is therefore to extract the
entropy of its inputs, and a good one will do this efficiently.
Kitchen sink or not, XORing zipfiles seems to work. Prove me wrong :-)
--
Thanks for giving this your attention,
David West. <[EMAIL PROTECTED]>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Date: Wed, 15 Nov 2000 10:40:25 -0800
Terry Ritter wrote:
> No practical process or test can find every kind of sequence
> correlation. But if we somehow do make a process which predicts, we
> can confirm that, and measure how close it comes. Then we can try
> various other things and see *by* *how* *much* each improves the
> prediction. That is quantitative science.
Isn't it better just to prove that the entropy is there in the first
place and then not have to worry?
DS
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: ECC help please
Date: Wed, 15 Nov 2000 12:43:25 -0600
James Russell wrote:
>
> I have what I think is a very simple question, but I know next to nothing
> about cryptography, so please forgive me if it's really stupid.
>
> 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?
> Could someone who is using Certicom's version talk securely with someone
> using RSA's version?
Yes, they can be made to interoperate. Lots of details, but it can be done.
> 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?
Yup, you sure can! Lots of details to watch out for, but you can do it
without violating any patents.
Patience, persistence, truth,
Dr. mike
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Thoughts on the sci.crypt cipher contest
Date: Wed, 15 Nov 2000 11:01:39 -0800
<[EMAIL PROTECTED]> wrote in message news:8usn5b$2cs$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>,
> Paul Crowley <[EMAIL PROTECTED]> wrote:
> > We can't stop people deploying weak ciphers by keeping ours secret,
> > they'll just make up their own weak ciphers. The best we can do is
> make
> > with the big disclaimers that say "Use Rijndael if you want a cipher
> > that actually works!"
>
> But we can make it much easier for them to use Rijndael because all the
> necessary routines are implemented, that is my goal. Besides it helps
> make sure I don't get somehow listed as an author on some snake-oil.
>
>
> > The whole point of the contest is to make curiosity ciphers that are
> fun
> > to make and fun to break. If any really neat ideas come out of it,
> > maybe someone will use them to create a cipher good for practical use,
> > but that's not the primary goal.
>
> I certainly agree, I just make small efforts to make it as difficult as
> possible for the uninformed to wrongfully use a weak cipher. I would of
> course be willing to share the cipher design if anyone would like to
> look at it (e-mail me at [EMAIL PROTECTED], I haven't written any code,
> but I can fairly quickly have a human readable version). Barring that,
> if this cipher exploration gets underway, I will submit the cipher, I
> just won't do a decrypt function.
> Joe
If they are so clueless, any cipher you publish would be a step up for them.
Gosh, don't let the weirdness dictate your actions. At least step through
the decrypt process in pseudo code.
If you don't publish the decrypt
source function in code, at least give some test vector so that we who
are self concious can verify that we have it right before we comment.
I only open my mouth to exchange feet.
Seems like the only thing stopping this activity is a host. The Sci crypt
cipher contest happend because Adam did it. "If you build it they will
come".
Paul
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
------------------------------
** 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
******************************
