Cryptography-Digest Digest #318, Volume #12 Mon, 31 Jul 00 03:13:01 EDT
Contents:
Walter Mathau a cryptographer?? ([EMAIL PROTECTED])
Pegwit - "Weak" ECC with GF(2^m), m composite? ("Ed Suominen")
Re: Reference to a public key technique in NYTimes (Johnny Bravo)
Re: Encrypt string to produce a unique number (SCOTT19U.ZIP_GUY)
Re: encrypting folders in Windoze (Frank M. Siegert)
Re: Pegwit - "Weak" ECC with GF(2^m), m composite? (lordcow77)
Re: Pegwit - "Weak" ECC with GF(2^m), m composite? (Jerry Coffin)
Re: BUGS v3.3.0 - CONTEST (Mack)
Re: Enigma (Jim Gillogly)
Re: Enigma (Jim Gillogly)
Re: Small block ciphers (Mack)
Password Protected Documents (Arfy Woof)
Re: Small block ciphers (Mack)
Psuedo-random number generation ("RecilS")
Kovlitz curves questions ("Sergio Arrojo")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Walter Mathau a cryptographer??
Date: Mon, 31 Jul 2000 03:52:27 GMT
Back when Walter Mathau passed away, I was half listening to an obit
while driving home from work. As usually happens, out of the "corner of
my ear" I could have sworn I heard them say that Mathau was a
cryptographer duing WWII and won an medal or commendation or something.
I never heard anything else about it in any other obit and haven't found
any info concerning this on the web.
Was I crazy or something?? Does anyone else know anything about this??
Any info appreciated!
--
"Wife who put husband in doghouse, soon find him in cathouse."
-- Wisdom of the Tao
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Ed Suominen" <[EMAIL PROTECTED]>
Subject: Pegwit - "Weak" ECC with GF(2^m), m composite?
Date: Sun, 30 Jul 2000 18:04:17 -0700
As I dig ever deeper into my evaluation of Pegwit 8.7 (and I'm starting to
get in a bit over my head), I wonder if its use of an elliptic curve with
the following characteristics is a problem: "The field is represented as
polynomials of degree 17 with coefficients which are elements of GF(2^15)."
I don't really understand all the math yet (but I'm studying hard - learning
technology fast is part of my business!). However, I do have some
observations on the "composite m" warning in Paulo S. L. M. Barreto's web
page at http://www.nw.com.br/users/pbarreto/crypto_page.html. In email
correspondence, Paulo has warned me away from Pegwit because of the
"composite m" problem he says is in its code. (He should know - he wrote
it.)
Here's his warning:
"I used to offer here a public domain implementation of elliptic curve
arithmetic over GF(2^m) for composite m. However, Nigel Smart has recently
discovered a new and powerful attack against most curves of this form.
Details will be made available here. Briefly, if m = kd then the elliptic
discrete logarithm problem can be solved in time O( 2^(k*(2 + epsilon) ))
instead of O( 2^(kd/2) ), where epsilon is a small number (presumably
epsilon < 1). Therefore, any curve used in the library (assuming Smart's
attack applies to them) could be broken in about O(2^32) steps."
OK, so if m is 15 (k=3,d=5) then the EDLP can be solved in (at worst) time
O( 2^6 ) instead of time O ( 2^7.5). Why is this such a big deal? The ratio
between 2^6 and 2^7.5 is only about 2.8:1, just a couple of bits off the
equivalent symmetric keylength. (I am assuming that O(x) is a linear
function of x.)
Further adding to my confusion is the fact that George Barwood writes that
Pegwit uses "an elliptic curve over GF(2^255)." Well, 255 is prime so that
shouldn't be a problem?
Help!!!!!!
--
Ed Suominen
Registered Patent Agent
Web Site: http://eepatents.com
PGP Public Key: http://eepatents.com/key
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: Reference to a public key technique in NYTimes
Date: Mon, 31 Jul 2000 00:21:54 -0400
On Sun, 30 Jul 2000 20:45:29 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>
>
>Johnny Bravo wrote:
>
>> Play music, record music as it gets sent to speakers. The software
>> needed for this is already around, I've used it to record a broadcast
>> channel playing through WinAmp.
>>
>> "Impractical" and "Impossible" merely becomes inconvenient as the
>> music pirates now have to actually play the song before converting to
>> MP3 format.
>
>Copying can't absolutely be prevented.
That was my point, the claim in the original article was that it was
impractical or impossible to defeat the protection on the data or
music.
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Encrypt string to produce a unique number
Date: 31 Jul 2000 04:23:39 GMT
[EMAIL PROTECTED] (yankee) wrote in
<8m1qbd$5q0$[EMAIL PROTECTED]>:
>So where can I find the adaptive huffman compression with a condition
>file ? Thanks
>
Go to my website the compression portion. I have variouos
adaptive huffman compression programs with source code and
executables.
>
>
>SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> [EMAIL PROTECTED] (yankee) wrote in
>> <8m1mpc$2hh$[EMAIL PROTECTED]>:
>>
>> >Is there any algorithm to produce a unqiue number based on a string .
>> >The string is except to have a maximum length of 30(the string is
>> >alphanumeric only) After "encryption" . It should result in a number
>> >length of not more than unsigned long which is about 10 .
>> >
>> >
>> >
>> >
>>
>> You can use my adaptive huffman compression with a condition file
>> that consists of the characters allowed in the sting. This will
>> compress a short string quite well and maybe what you are looking
>> for.
>>
>>
>> David A. Scott
>> --
>> SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
>> http://www.jim.com/jamesd/Kong/scott19u.zip
>> Scott famous encryption website NOT FOR WIMPS **no JavaScript
>> allowed** http://members.xoom.com/ecil/index.htm
>> Scott rejected paper for the ACM
>> http://members.xoom.com/ecil/dspaper.htm
>> Scott famous Compression Page WIMPS allowed ** JavaScript OK**
>> http://members.xoom.com/ecil/compress.htm
>> **NOTE EMAIL address is for SPAMERS***
>> I leave you with this final thought from President Bill Clinton:
>> "The road to tyranny, we must never forget, begins with the
>> destruction
>> of the truth."
>
>
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS **no JavaScript allowed**
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed ** JavaScript OK**
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction
of the truth."
------------------------------
From: [EMAIL PROTECTED] (Frank M. Siegert)
Subject: Re: encrypting folders in Windoze
Date: Mon, 31 Jul 2000 04:36:39 GMT
On Sun, 30 Jul 2000 19:04:54 GMT, [EMAIL PROTECTED] wrote:
>Can anyone share how they encrypt folders in Windoze? Winzip? I
>basically just want to be able to lock folders and their contents
>from snooping eyes.
>
>Thanks, and my apologies if this is too basic.
Not exacly for folders, however... I suggest you point your browser to
http://www.scramdisk.clara.net/
http://www.e4m.net/
Both create protected virtual disk drives and should provide adequate
security for most purposes.
------------------------------
Subject: Re: Pegwit - "Weak" ECC with GF(2^m), m composite?
From: lordcow77 <[EMAIL PROTECTED]>
Date: Sun, 30 Jul 2000 21:51:37 -0700
255=15*17
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Pegwit - "Weak" ECC with GF(2^m), m composite?
Date: Sun, 30 Jul 2000 22:58:34 -0600
In article <aS6h5.154$[EMAIL PROTECTED]>, ed-
[EMAIL PROTECTED] says...
[ ... ]
> Further adding to my confusion is the fact that George Barwood writes that
> Pegwit uses "an elliptic curve over GF(2^255)." Well, 255 is prime so that
> shouldn't be a problem?
I haven't looked at the code to Pegwit to comment on the order of
curve that it uses, but at the very least it's clear that 255 is not
prime...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: BUGS v3.3.0 - CONTEST
Date: 31 Jul 2000 05:29:22 GMT
>
>
>Hi,
>
>I have created a cryptography algorithm. I am not good at cryptography,
>but I am really interested in this subject.
>I am not sure that this algorithm, called BUGS, is really good or even
>good at all. This is why I am posting an email in this newsgroup and
>also running a contest to crack it, the Prize (only) is 50 English
>Pounds.
>
>I know it is not a lot, but this algorithm is free and open source and
>I have only done it during my free time. And really this prize is just
>there to show that I am serious about it. Because I have never managed
>to crack it and I haven't got the knowledge to even do it, I have
>launched this contest.
>
>Even if you don't want to participate to the contest (and I am sure
>that professional cryptographer will never even try for so little money)
>I invite you to go to the Web site:
>http://www.bcrypt.com
The contest as it is is basically here is my algorithm and
a ciphertext. This really doesn't tell if your algorithm is secure.
To be secure, it must be secure against chosen-adaptive
plaintext attack. A cipher-text only attack isn't really
practical for most ciphers (even bad ones).
That said BUGS appears to be more of an application than
just a cipher. I haven't really looked at it just the nature of
the contest. The cipher may be useful. The contest is not.
>
>Where you can find the Unix applications, the source code, a
>documentation about how the algorithm works and information about the
>contest.
>
>BUGS is a private key algorithm.
>
>Once again I am not posting a message to say I've done a brilliant
>algorithm, but just that I have done one and if anybody could tell me
>where are the possible weak points it would be really useful.
>This is an open source, GNU/GPL package. If you've got any ideas about
>how to improve it please let me know on:
>[EMAIL PROTECTED]
>
>Thanks for your time.
>Sylvain.
>
>PS: I am french, therefore english is not my mother tongue please
>excuse me if I make mistake or if I "invent words" ;o)
>
>---
>Unix security administrator
>BUGS crypto project: http://www.bcrypt.com
>http://www.encryptsolutions.com
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
>
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Enigma
Date: Mon, 31 Jul 2000 05:33:04 +0000
John Savard wrote:
>
> On Fri, 28 Jul 2000 19:17:06 GMT, [EMAIL PROTECTED] (James Pate
> Williams, Jr.) wrote, in part:
>
> >Mr. or Dr. Gillogly did you develop a chess playing program back in
> >the 1970s that was described in a refereed journal article?
>
> It's quite possible, as I believe he is the same Jim Gillogly that
> first ported Adventure to C.
Yes, I'm also that Jim Gillogly. I lead a full life. I've also been
spotted at Renaissance Faire singing period drinking songs in peasant
costume while juggling, and I've sung in Carnegie Hall. :)
--
Jim Gillogly
Trewesday, 8 Wedmath S.R. 2000, 05:31
12.19.7.7.12, 13 Eb 15 Xul, Eighth Lord of Night
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Enigma
Date: Mon, 31 Jul 2000 05:40:49 +0000
"James Pate Williams, Jr." wrote:
> Chinook, the world champion checkers program, and Deep Blue, the world
> champion chess program are both described in the literature as brute
> force game playing programs. How large an opening book and closing
The year after my program took 2nd place in a Computer Chess Championship
in 1972, the other major programs had switched to a brute force based
strategy. Chess is simply too tactically tricky to allow half-clever
forward pruning, and nobody's yet managed completely clever forward
pruning. That's why I think (unlike other chess programmers) that
there's still mileage to be gained from deeper tactical searches.
Some others, including strong chess players, think a 20-ply program
won't be much better against strong humans than a 13-ply program.
> book did the Technology Chess Program possess? What sort of an
Small -- a few hundred opening positions, and no end-game positions.
> evaluation function did it use? Sorry for not looking up the journal
Primarily material, but the top level was sorted based on simple
strategic goals so that they would serve as the tie-breaker if the
material was even. More granular evaluation functions allow better
pruning because of the cutoffs for ties, so unless you're sure your
more detailed eval fn is better than material alone, it's worse than
useless.
More modern viewpoints on chess programming may be found in
rec.games.chess.computer, where this thread should probably
migrate. My views are a couple of decades old by now and
perhaps obsolete.
--
Jim Gillogly
Trewesday, 8 Wedmath S.R. 2000, 05:33
12.19.7.7.12, 13 Eb 15 Xul, Eighth Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Small block ciphers
Date: 31 Jul 2000 06:22:34 GMT
>
>Mack wrote:
>
>> Has the field of building small block ciphers
>> been neglected? Skipjack used a 16 bit four
>> round cipher as an S-box. This is reported to
>> be part of a family of ciphers used in Type 1
>> crypto hardware.
>
>I don't know for sure but I conjecture that due to the advancements
>of hardware technology, it has become practical and economical
>to employ larger block sizes (for hardware implementations) which
>can be exploited in design to better (more efficiently) provide higher
>strength. Since the opponent is also profited by better technology,
>the natural tendency is having increasingly larger block sizes, see
>AES. On the other hand, given modules of a certain block size,
>one can use them in a way that provide higher strength, like the
>case of 3DES or using sort of recursion to apply the smaller
>block size algorithm (see the thread 'On higher order Feistel
>schemes' of 13 May), but this cannot compete in general with
>genuine designs with larger block sizes in computational efficiency
>for obvious reasons.
>
>M. K. Shen
>
>
Certainly using a block size of 32 or 48 is not very secure for
modern applications. Nor are such schemes terribly fast
for general usage.
My question was are we neglecting the study of such ciphers?
The analysis of Skipjack using impossible differentials certainly
seems to indicate that at least at the global level we should
be studying much smaller ciphers to find weaknesses that exist
in the expanded version.
It seems to me that we might be able to prove that for an 8 or 16 bit
cipher block there is no better method of attack than brute force or
dictionary attack. Then expand that concept to a larger cipher.
In the simplest case for example.
We can write out an 8 bit substitution as
a function of say 8 key bits and 8 input bits
giving 8 equations in 24 variables (output is a variable).
Since we have at least one plaintext/ciphertext pair this
reduces it to 8 equations in 8 variables. This may be solvable.
Since the equations are not linear we may have to expand them
with more pairs to get a solution. If each nonlinear term is a
'variable' then we now have 255 unknowns. This would require
at least 8 pairs.
But if we use a 12 bit key we now have 8 equations in
12 variables. This is obviously not soluble with only one
ciphertext. If each nonlinear term is a 'variable' we now have
4095 unknowns. This would require at least 512 pairs.
Since the maximum is 256 pairs it can't be solved under
this assumption.
Obviously there are better ways to solve nonlinear equations
in GF(2). This is not a proof that all 8 bit ciphers with 12 bit
keys are secure.
If we can prove that for a specific 8 bit cipher the set of
equations can't be solved then maybe we can prove that
the same cipher can be expanded to 128 bits and still have
a certain set of properties.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Arfy Woof)
Subject: Password Protected Documents
Date: Mon, 31 Jul 2000 06:24:26 GMT
I've written an editing program in c++ that generates documents ala
Word. I need to implement password protection capabilities on the
documents, but only write/edit protection. (I still want everyone with
the program to be able to open/view the file, but if a password is
set, then they should not be able to edit the file).
I've been using the SHA algorithm to encrypt the password, but how
would I store this within the document without being obvious? It
would seem fairly easy for someone to just "cut out" the encrypted
password, rewrite a new file and gain full editing capabilities. I
can't encrypt the entire file, because that wouldn't allow access for
people who just want to view the file. Any suggestions? I realize
nothing is 100% safe, I just want to make it as difficult as possible
for shlubs to hack into the documents.
Thanks for any help
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Small block ciphers
Date: 31 Jul 2000 06:29:02 GMT
>
>On 30 Jul 2000 07:49:42 GMT, in
><[EMAIL PROTECTED]>, in sci.crypt
>[EMAIL PROTECTED] (Mack) wrote:
>
>>Has the field of building small block ciphers
>>been neglected? Skipjack used a 16 bit four
>>round cipher as an S-box. This is reported to
>>be part of a family of ciphers used in Type 1
>>crypto hardware.
>
>Terminology seems to be part of the problem here (as it often is).
>Normally, we see a "block cipher" as a Simple Substitution which is so
>large that we cannot store or traverse it. So the idea of a "small
>block cipher" is almost contradictory, but we use things much like
>that all the time and just call them substitution tables.
>
Yes. Any block cipher can be represented as an s-box.
Doing it in practice is not always possible. Although
many attacks assume that much of the s-box can be
examined.
>
>>Presumably Skipjack was at the low end of
>>this family. Although it has a very low safety
>>margin it is still an interesting design.
>>
>>Has anyone experimented with similar designs?
>>Does anyone have any 'good' short block ciphers
>>laying around?
>
>Certainly, Substitution-Permutation (S-P) designs have been around for
>a long time, but are harder than they look. I have done a lot of work
>in the mixing of multiple substitution tables so as to produce effects
>statistically similar to that of a table which is far too large to
>store.
>
>---
>Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
>Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
>
>
Your work in this area is noteworthy. Although I don't always
agree with your ideas, many are unique and well thought out.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: "RecilS" <[EMAIL PROTECTED]>
Subject: Psuedo-random number generation
Date: Mon, 31 Jul 2000 02:39:10 -0400
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Well I'm looking for a bit of brief help. I'm working on a one-time
pad system and I'm trying at the moment to devise a method to get
identical sequences of completely random numbers to two different
people without the possibility of compromise. The only two methods
I've realized are particle entanglement (obviously a bit impossible
right now) and trading CDs. Well short of setting up a hardware,
random number generator in my house (which i plan on doing) I need to
fill a few CDs with random bits.
Right now, for testing, I'm willing to fall back upon
psuedo-randomness, but I'd rather be developing my software than a
program I will use very briefly and never again. So...
If anyone knows of a good program which generates numbers with a high
degree of randomness and can do so on the scale of 650megs within a
realistic ammount of time, PLEASE LET ME KNOW! Even if it takes a
few days or longer I'm interested as I'm still developing the
interface and have time to kill.
THANKS.
BTW - Please post a followup and do not email me at this time.
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBOYUfDBJETAFqh0RgEQISUACeIcFNv5t7oJ18Jq+h1WrlS6OmHtEAoKhx
z7XKEmlcDHR56c18UR+pGRGH
=M4Gy
=====END PGP SIGNATURE=====
------------------------------
From: "Sergio Arrojo" <[EMAIL PROTECTED]>
Subject: Kovlitz curves questions
Date: Mon, 31 Jul 2000 08:58:58 +0200
Reply-To: "Sergio Arrojo" <[EMAIL PROTECTED]>
Could somebody give me a definition (please rather clear than cryptic) of
"Koblitz Curves"?
Why are there appropiate to avoid the recently discovered attack to curves
char. 2 with m composite?
Do they have anything to do with anomalous curves (since I ve heard they are
called also "anomalous binary curves")?
Thanks
Sergio
------------------------------
** 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
******************************
