Cryptography-Digest Digest #716
Cryptography-Digest Digest #716, Volume #9 Mon, 14 Jun 99 07:13:03 EDT
Contents:
Re: Slide Attack on Scott19u.zip (SCOTT19U.ZIP_GUY)
SLIDE ATTACK FAILS (SCOTT19U.ZIP_GUY)
Re: OTP is it really ugly to use or not? (fungus)
Re: Maximum key size in block ciphers (David Ross)
Re: Shared secret protocol (David P Jablon)
Re: Generating Random Numbers ("Douglas A. Gwyn")
Re: Cracking DES (wtshaw)
Re: huffman code length ("Mr. X")
Has this cipher been broken yet ? (Anonymous)
Re: Is there a short digest for short messages? (Francois Grieu)
Re: Export restrictions question (fungus)
Re: Random numbers on a sphere (Anders Holtsberg)
Re: Another free email? (Fred)
Scramdisk newsgroup (was Re: SCRAMDISK QUESTION) ("Andy Jeffries")
encrypt using ASCII 33 to 126 only? ("Kenneth N Macpherson")
Re: question about original RSA research (Nick Barron)
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Slide Attack on Scott19u.zip
Date: Mon, 14 Jun 1999 05:20:18 GMT
In article 7k1o54$cea$[EMAIL PROTECTED],
[EMAIL PROTECTED] (David Wagner) wrote:
I don't have time to dig through pages and pages of hard-to-read code.
I followed the information that I found on the web page (which didn't
describe the special first and last rounds). Even that was hard to read.
Yeah I see you couldn't even copy a one line equation correctly
In general, if you wrote a concise, descriptive article describing the
algorithm, it would greatly increase your chances of having good people
look at it seriously. Right now the barrier is much too high.
However that barrier does not seem to high for you and a few other
crypto gods to declare that the cipher was dead. I sure the germans
did not give the engish (polish) something at least as well as I am
giving you. Rember I give code that would compile and run. Also I
offered to enter the AES contest but was turned down since ps
format was required. If they ever run a open honest contest allowing
ascii or something like HTML I might enter.
I frankly find it amussing that you think the crypto experts are worth
being catered to. The barrier is only high if you to dam lazy to look at
it. It was declared dead by you by your slide attack and that was
wrong. I hope to be a pain in the ass to false crypto gods for years
to come. My daughter went to your school she changed majors and
still got out in three years. Berkeley is vastly overated. The dorms
are full of pot and the graduates have an ego that doesn't quit.
The brightest one seem drop out maybe they feel cheated after
seeing what berkeley is really like.
Remember, the experts will not even consider spending time on cryptanalysis
ciphers posted on the net, no matter whether they are well described.
For fun, I sometimes look at net-ciphers, but I'm no expert.
I can see you are no expert. Since you know the S-table is the only thing
that counts after it is built one needs to only look at the last 4 routines in
scott19u to get an idea of how the code works. Again it is not pages and
pages in that section. The macros are self explanatory. But I don't expect
you to read it like I said I am not a Crypto God. Maybe next time you can
come up with an attack on some toy cipher as good as Paul Onions.
And the so called experts are only the phony ones in your crypto club
I write code so the common user can encrypt his files so ivory tower
types like you and the NSA can not break it. Short of a gun at your
throat or a nsa virus on your machine or camera in your house this
is not the kind of toy code you guys bless for the ignorant masses to
use. This is much better than that. I could give a shit if the boasting
sounds like snake oil. At least it is not a false modesty that people
like you use. Yes it is easy to say its broken and then when you fail
blame it on the fact you can't read it.
Face the facts your highly praised slide attack does work on real
world stuff that an ametur can come up with. Yes I guess you did
find some toy ones to break. I am sure you have tried to break mine
at least via the grape vine I hear so called fasle crypto gods have
looked and they can't break it yet. Yes I am a pain in the ass
aren't I.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
--
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: SLIDE ATTACK FAILS
Date: Mon, 14 Jun 1999 05:37:58 GMT
To sum it up the great crypto gods where wrong.
Which should be of no great surprise. SCOTT19U
is still alive and well. The great "SLIDE ATTACK"
went down the sewer. But don't blame the crypto
gods to much. They have such a narrow view of
mathematics and can't read C code. They have
a club where they break toy ciphers
Cryptography-Digest Digest #718
Cryptography-Digest Digest #718, Volume #9 Mon, 14 Jun 99 15:13:03 EDT
Contents:
Re: Has this cipher been broken yet ? ([EMAIL PROTECTED])
Re: Is there a short digest for short messages? ([EMAIL PROTECTED])
Re: Maximum key size in block ciphers (fungus)
Generating Large Primes for ElGamal ([EMAIL PROTECTED])
Re: Spec (SCOTT19U.ZIP_GUY)
Re: Slide Attack on Scott19u.zip ([EMAIL PROTECTED])
Re: encrypt using ASCII 33 to 126 only? ("Kenneth N Macpherson")
Spec ("Kenneth N Macpherson")
Re: encrypt using ASCII 33 to 126 only? (Christopher)
Re: encrypt using ASCII 33 to 126 only? ("Kenneth N Macpherson")
Re: I challenge thee :) (Patrick Juola)
Re: Has this cipher been broken yet ? (Anonymous)
Re: encrypt using ASCII 33 to 126 only? - SPEC ("Kenneth N Macpherson")
Re: IDEA in "aplied cryptography" BRUCE SCHNEIER (James Pate Williams, Jr.)
Re: Spec ("Kenneth N Macpherson")
Re: IDEA in "aplied cryptography" BRUCE SCHNEIER ([EMAIL PROTECTED])
Re: encrypt using ASCII 33 to 126 only? (Terje Mathisen)
Re: Followup: OTP is it really ugly to use or not? (Greg Bartels)
Is there a short digest for short messages? Continued... ("Joe")
Re: SLIDE ATTACK FAILS (Greg Bartels)
From: [EMAIL PROTECTED]
Subject: Re: Has this cipher been broken yet ?
Date: Mon, 14 Jun 1999 11:53:33 GMT
In article [EMAIL PROTECTED],
Anonymous [EMAIL PROTECTED] wrote:
Can anyone tell me if the ATBASH2 cipher has been broken yet ?.
This cipher is perfect for my requirements (Morse code).
Any information / advice appreciated.
Thanks.
Do you have the details? Maybe I could comment on it.
Tom
--
PGP key is at:
'http://http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
--
From: [EMAIL PROTECTED]
Subject: Re: Is there a short digest for short messages?
Date: Mon, 14 Jun 1999 11:50:11 GMT
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
Whatever the algorithm, if the possible values of your "digest"
are in the range (0 - 10^6), you will most probably have a
collision after digesting ~10^3 messages (birthday paradox).
- Collision means that two messages have the same digest value -
After ~10^3 *RANDOM* messages. It will still take on average (10^7)/2
or about 500,000 messages before you find a real message and a RANDOM
message that collide.
Tom
--
PGP key is at:
'http://http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
--
From: fungus [EMAIL PROTECTED]
Subject: Re: Maximum key size in block ciphers
Date: Mon, 14 Jun 1999 15:55:10 +0200
David Ross wrote:
507 decimal digits, with commonly 70 per line Boggling. How many
atoms in the universe?
Heh.
Anybody remember the scene in "The Forbidden Planet" where the doctor
is explaining the generators. Row after row of little meters, each
measuring ten times more energy then the meter before...
--
\___/
/ O O \
\_/ FTB.
--
From: [EMAIL PROTECTED]
Subject: Generating Large Primes for ElGamal
Date: Mon, 14 Jun 1999 14:14:15 GMT
HI,
I'm interested in implementing ElGamal public key encryption. Is there
any public source available ( C++ would be great ) for generating large
primes used in public key encryption?
Thanks,
Ron
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
--
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Spec
Date: Mon, 14 Jun 1999 17:02:00 GMT
In article [EMAIL PROTECTED], "Kenneth N
Macpherson" [EMAIL PROTECTED] wrote:
I have been told to give some details of what security is required for my
app.
The encryption does not need to be strong. It will never be required to do
more than stop someone who barely knows where regedit it is and who wants to
screw with licensing settings.
So almost any type of crypt will do. It MUST produce an encrypted form
consisting of chars that are typeable from the keyb and I would like it to
be the same length as the input string.
Apart from that VB is the language and code would be nice (especially a
single function solution).
What you do is just make a list of the typeable characters that you wish
to use. Then form another list of the same characters but reorder it any way
you want to. Then to encrypt go down the first list to find the character your
typing then go to opposite list to get the typeable character you want out.
On decryption you do the oppose find the encrypted characters position on
the second list then go to first list in the same position and you have the
desired character.
This method is very basic and could eaily be done in VB such that the
strings are all typeable and the input striings match the output strings
in length.
If you want a little
Cryptography-Digest Digest #719
Cryptography-Digest Digest #719, Volume #9 Mon, 14 Jun 99 16:13:04 EDT
Contents:
Critique of Street Performer Protocol paper (Anonymous)
Re: SLIDE ATTACK FAILS ([EMAIL PROTECTED])
TEA vs Blowfish (Dave Hazelwood)
Re: SLIDE ATTACK FAILS (Johnny Bravo)
Re: Followup: OTP is it really ugly to use or not? (STL137)
Re: RSA example with small numbers (STL137)
Key Schedule Question ("Timothy Kordas")
Subset alphabet encryption (Kevin Driscoll)
NDSS 2000 SUBMISSION DEADLINE EXTENDED TO JUNE 23RD ("David M. Balenson")
Re: Spec ("Kenneth N Macpherson")
From: Anonymous [EMAIL PROTECTED]
Subject: Critique of Street Performer Protocol paper
Date: Mon, 14 Jun 1999 21:04:06 +0200 (CEST)
Comments on http://www.counterpane.com/street_performer.pdf:
Regarding secure perimeter schemes:
There is also an economic problem. The customer does not see much economic
value in purchasing a secure perimeter. Selling a tamper-resistant device
useful only to play copyrighted content (e.g., a sealed box with speakers
and a video screen) seems dicult.
This is not necessarily true. In fact there is some evidence that Intel's
move towards embedding serial numbers and cryptographic functionality
into their chip set is primarily for this purpose. A customer will
want to buy a box that can play secured data if that data is much less
expensive than non-secured. If you have a choice between buying a
Microsoft product for $495 on a regular PC or $29.95 on a secured PC,
there will surely be a market for secured PCs. (Of course if you're
just going to pirate the software you won't be in that market.)
With tools like anonymous remailers and the Eternity service, material
that's ever posted simply cannot be erased, short of destroying the
whole service. This means that one posting of a copyrighted piece of
music, video, or text makes it available for free (or at least very
cheaply) via the Internet. Indeed, even without the Eternity service,
information that is ever posted or made available on the net is very
hard to erase, though legal threats can probably get it taken offe major
search engines.
The Scientology documents are a good case study here. In fact the church
has been reasonably effective in severely limiting their distribution.
MP3s are a forthcoming example. Will they still be widely available three
years from now? Chances are that any site which becomes known as offering
MP3s will have lawbots hounding it within minutes. The underworld of ftp
sites and hotline servers offering MP3s will have difficulty surviving
under that kind of pressure and scrutiny.
Regarding traitor tracing schemes:
Even worse, a record company or publishing house has relatively little
direct incentive to worry about getting the right person. To deter future
infringement, they need to make a highly visible example of someone. If
it's the right person, so much the better. However, most of the people
being deterred by his example will have no idea whether he's guilty or
innocent, so the deterrent ect is essentially the same. The record company
or publishing house will presumably try to get the right person, but their
only financial incentive for doing so is to eliminate one more copyright
violator, and to avoid costly lawsuits from the falsely accused person.
The risk of lawsuits is far from insignificant. If it becomes known that
a publisher has callously prosecuted an honest customer with disregard
for the truth, the publisher will not only face severe punitive damages,
but also a loss of reputation as other customers fear that they may face
the same risks. Publishers would actually have strong incentives to use
the system responsibly and reliably, given the kind of legal climate we
have today.
In a world in which copyrighted material, once posted, drops a great
deal in value, it's probably not possible to hold the copyright violator
responsible for most of the loss. He will generally just not have the
money. Furthermore, very few personal computers or homes are defended
well enough to justify having information inside which, if posted
anonymously to the Internet, will cost their owner even a few thousand
dollars, let alone millions of dollars. (For comparison, the reader
may consider whether he would be willing to keep a briefcase with even
$10,000 belonging to his boss in his house, with no additional security
or insurance.)
It would probably be necessary to have much higher security in the
computers which guard the copyrighted material than we generally have
today. The question is whether technologies exist which can provide
this kind of security. If computers become cheap so that copyrighted
material is provided on a special computer (a video/music/game box) then
it need not be a version of Windows but can be a special high security OS.
A number of vendors claim to have technology (capabilities, etc.)
Cryptography-Digest Digest #720
Cryptography-Digest Digest #720, Volume #9 Mon, 14 Jun 99 19:13:08 EDT
Contents:
Followup: OTP is it really ugly to use or not? (Cyba Nonymous)
Re: Cracking DES ([EMAIL PROTECTED])
Re: IDEA in "aplied cryptography" BRUCE SCHNEIER (John Savard)
Re: Generating Large Primes for ElGamal (Wei Dai)
Re: IDEA in "aplied cryptography" BRUCE SCHNEIER (James Pate Williams, Jr.)
Re: TEA vs Blowfish (Peter Gunn)
Re: huffman code length (Andras Erdei)
Book Usefulness Question (consalus)
Re: sbox design (Medical Electronics Lab)
Re: TEA vs Blowfish (David Wagner)
Re: OTP is it really ugly to use or not? ([EMAIL PROTECTED])
Re: IDEA in "aplied cryptography" BRUCE SCHNEIER (John Savard)
Re: OTP is it really ugly to use or not? ([EMAIL PROTECTED])
Re: Book Usefulness Question ("Steven Alexander")
Re: Followup: OTP is it really ugly to use or not? (Jim Gillogly)
Re: Is there a short digest for short messages? (Jerry Coffin)
Re: DES and BPANN (James Pate Williams, Jr.)
Re: Cracking DES ([EMAIL PROTECTED])
Re: Generating Large Primes for ElGamal ([EMAIL PROTECTED])
Date: 14 Jun 1999 16:38:48 -
From: Cyba Nonymous [EMAIL PROTECTED]
Subject: Followup: OTP is it really ugly to use or not?
Jim,
Thanks for taking the time to give me the benefit
of your knowledge.
I understand most of what you said but still can't
see how re-using bits in a random pad provided they
have been re-scrambled into another random pad
compromises the security of an OTP. In other words,
does the method I proposed really reuse "the pad"
or not?
That is the question. I don't think so. At least not
in the sense or in a way in which it can be used to
compromise the OTP. I maintain that all the derived
pads are different even though they are derived from
the same CD of random numbers.
No?
Let's say I have a CD with the following random
numbers:
E7 05 87 12 A1 63 BC 29 9A 32 ...
I want to encode the following message #1:
HELLO (48 45 4C 4C 4F)
I use codeword "A" to select bytes from the pad
using a formula based program and it gives me
offsets:
05 02 07 06 09
which yields a pad of:
(that for purposes of discussion is also random)
A1 05 BC 63 9A
I use this pad to encrypt "HELLO" using xor to:
E9 40 F0 2F D5
Now I want to encode a second message #2 which is:
GOODBYE (47 4F 4F 44 42 59 45)
I use codeword "B" to select bytes from the CD
with the program and it gives offsets:
06 01 08 0A 03 05 01
which yields a pad of:
63 E7 29 32 87 A1 E7
I use this pad to encrypt "GOODBYE" using xor to:
24 A8 66 76 E5 F8 A2
Ok now let's assume that the "source" instead of
being 10 numbers like in this example is a CD
full or better yet a DVD full, 8/16 GIG's worth,
and the selection program grabs a calculated mixed
subset of these bytes for the new pad that is
guaranteed to be randomly different for every
unique codeword.
I fail to see then how the security of either message
is compromised simply because I reused bytes from
the CD/DVD? It is not as if I reused the pad or even
a sequence from the pad but in essence what I did
was to generate another unique pad from an existing
pool of random numbers on the CD/DVD right?
Are these messages not secure as long as the codeword
is secure? I will even give you tha pad and the
formula and I bet you can't break it without the
codeword. Or, I'll give you the codeword but you
still can't break it without the pad and the formula.
Is it not true that the encrypted message
24 A8 66 76 E5 F8 A2
can be xor'd back to every possible 7 letter
phrase with some pad? It is obvious to me that
this is so. I can derive a pad to turn those
7 bytes into any message I want so how can anyone
ever know they have got the right answer? Just
because they get a plausible message does not mean
it is the correct message and I don't see how they
can learn anything unless a significant sequence
from the original pad is reused and that can be
prevented by the selection program.
Even granting the "theoretical" it must be's to
be an "absolute" unbreakable OTP in the math sense
which this method may not satisfy isn't this method
still extremely strong? I can't see how it can be
broken. It can't be brute forced, it can't be
factored and even if somehow a part of a message or
even an entire message became known it does not
compromise any other message. I think that is pretty
good.
Or, am I all wet? Come to think of it can't the
selection program be seen as a rng in its own right?
But one that produces numbers that can never be
reproduced by anyone not having the original CD?
Is that another way of looking at this perhaps?
If so then this can be quite useful in that from
say a 16 GIG DVD used as a source you can get perhaps
a lifetime of unique pads and only ever have to deliver
the "source" pad once.
I hope I am not being to simple or stupid and that
I make some sense here in asking these questions.
I appreciate
Cryptography-Digest Digest #721
Cryptography-Digest Digest #721, Volume #9 Mon, 14 Jun 99 22:13:05 EDT Contents: Re: Scramdisk newsgroup (was Re: SCRAMDISK QUESTION) (Wes) Re: IDEA in "aplied cryptography" BRUCE SCHNEIER ([EMAIL PROTECTED]) Re: Generating Large Primes for ElGamal (Withheld) Re: OTP is it really ugly to use or not? (Mickey McInnis) Wired magazine: What does it do? (Anonymous) Re: Is there a short digest for short messages? ([EMAIL PROTECTED]) Re: Export restrictions question (Paul Koning) Re: Cracking DES ([EMAIL PROTECTED]) Re: cant have your cake and eat it too ([EMAIL PROTECTED]) Re: Wired magazine: What does it do? (Jim Gillogly) Re: Generating Large Primes for ElGamal ([EMAIL PROTECTED]) Re: Cracking DES (David Wagner) Re: Wired magazine: What does it do? (Anonymous) From: [EMAIL PROTECTED] (Wes) Crossposted-To: alt.security.pgp,comp.security.pgp.discuss Subject: Re: Scramdisk newsgroup (was Re: SCRAMDISK QUESTION) Date: 14 Jun 1999 16:16:05 -0500 Andy, Great!! Thanks so much for your efforts. On Mon, 14 Jun 1999 10:50:42 +0100, "Andy Jeffries" [EMAIL PROTECTED] wrote: Sorry for the cross-posting, but this is relevant to all three groups. P.S. If any one knows of a NG which is dedicated to ScramDisk please let me know. I am in the process of creating alt.security.scramdisk. The proposal is currently in alt.config and I should be creating the NG this coming weekend. For your newsgroups file: alt.security.scramdisk Free hard drive encryption for Windows 95/98 Comments: I would like to start a discussion group for Scramdisk. This program is free with Visual C++ source code and enables you to make encrypted container files on your hard drive (much like PGPDisk). The utility is currently discussed in alt.security.pgp and comp.security.pgp.discuss (and at times sci.crypt). The web page is at http://www.scramdisk.clara.net/ CHARTER: alt.security.scramdisk With the exception of cryptographic signatures (eg. PGP), all encoded binaries (eg pictures, HTML, word processor files, .zip files, "business cards", html) or similar non-plaintext postings are forbidden. URL links to binaries on ftp servers or web sites are encouraged. The posting of spam is forbidden, adverts must be confined to the signatures of on-topic posts. Justification of Readership: A search of Deja between the dates of mar 10 1999 to june 10 1999, for the terms Scramdisk !(simpson |jeffries) gave exactly 633 messages. This removes posts from Sam Simpson and myself, as we mention scramdisk in our signatures. This group was proposed in alt.config on 11/06/99 in message bn783.4315$[EMAIL PROTECTED]. -- Andy Jeffries Delphi Programmer Kwik-Rite Development -- See http://www.kwikrite.clara.net for TkrScramDisk (Delphi component) and Kwik-Crypt (Self-restoring encrypted archive utility). -- From: [EMAIL PROTECTED] Subject: Re: IDEA in "aplied cryptography" BRUCE SCHNEIER Date: Mon, 14 Jun 1999 21:13:37 GMT On Mon, 14 Jun 1999 20:44:06 GMT, [EMAIL PROTECTED] (John Savard) wrote: Not to keep criticizing you for being helpful, but I doubt the United States has annexed Germany any time lately... You never know -- From: Withheld [EMAIL PROTECTED] Subject: Re: Generating Large Primes for ElGamal Date: Mon, 14 Jun 1999 22:02:07 +0100 Reply-To: Withheld [EMAIL PROTECTED] In article [EMAIL PROTECTED], "James Pate Williams, Jr." [EMAIL PROTECTED] writes On Mon, 14 Jun 1999 14:14:15 GMT, [EMAIL PROTECTED] wrote: I'm interested in implementing ElGamal public key encryption. Is there any public source available ( C++ would be great ) for generating large primes used in public key encryption? I have implemented ElGamal public-key encryption using Arjen K. Lenstra's FreeLIP (Free Large Integer Package). See my home page for a hyperlink to FreeLIP. If you are a citizen of the U. S. currently residing in the U. S. and you would like to have a copy of a C implementation using FreeLIP of 8.18 Algorithm ElGamal public-key encryption from _Handbook of Applied Cryptography_ by Alfred J. Menezes et al. page 295 then send me an email at the address shown below requesting elgamal.c. ==Pate Williams== [EMAIL PROTECTED] http://www.mindspring.com/~pate Even if you're not a US resident I have a long integer calculator available. It's not fully debugged yet but can cope with numbers up to about 500 digits will total resolution. Larger numbers are under construction. It works as an ActiveX object so is only suitable for Windoze users. If anyone wants to see it, drop me a note at the address in the signature... I can either email it or put it on the web, depending on the level of interest. -- Return address removed for anti-spam purposes. Email replies to news at maelstrom dot demon dot co dot uk Email replies to this address may be copied to relevant newsgroups
