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 more securiry you can make up a few more tables
so that you alternate which set of lists you use as a function of position
in the string. Or you can rearange the list in variuos ways somewhat like
the germans did with enigma. But this should be very easy to impliment
in VB.
>Any other spec required let me know.
>
>Thanks for your continued help.
>
>Ken
>
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]
Subject: Re: Slide Attack on Scott19u.zip
Date: Mon, 14 Jun 1999 14:16:26 GMT
In article <7k3009$ons$[EMAIL PROTECTED]>,
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
> sorry tommy people already use it.
On purpose?
<snip>
Tell you what. No. I might be able to read your code and fix it. Or
I could sit and do something else. hmm. Your right though. Your code
is tough, tough to read that is. I mean just because people don't
understand your code doesn't make it superior. Blowfish is easy to
understand and provides a high level of security, or did you miss
that? By trying to make your code legible will help others read your
cipher. You love text files so much why not write it up? You claim
the algorithm is really simple, prove it.
Let me guess though, you are going to respond with nonce ramblings...I
will tell you this. If you don't clean up your act there are going to
be many people putting your email in a kill file. You will get no
attention and people will just stop caring.
BTW stop saying AES ciphers are weak, not all of them have been proven
weak. (yet). Neither has yours (yet). Can you break any AES cipher
with your superior knowledge?
Tom
--
PGP key is at:
'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: "Kenneth N Macpherson" <[EMAIL PROTECTED]>
Subject: Re: encrypt using ASCII 33 to 126 only?
Date: Mon, 14 Jun 1999 16:01:54 +0100
Christopher wrote in message ...
>How about mapping 13bits of ciphertext to 2 such chars, that way any
>byte-based cipher will work with the inclusion of the mapping function.
>
What?
Ken
------------------------------
From: "Kenneth N Macpherson" <[EMAIL PROTECTED]>
Subject: Spec
Date: Mon, 14 Jun 1999 16:11:48 +0100
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).
Any other spec required let me know.
Thanks for your continued help.
Ken
------------------------------
From: [EMAIL PROTECTED] (Christopher)
Subject: Re: encrypt using ASCII 33 to 126 only?
Date: Mon, 14 Jun 1999 10:31:37 -0400
How about mapping 13bits of ciphertext to 2 such chars, that way any
byte-based cipher will work with the inclusion of the mapping function.
In article <[EMAIL PROTECTED]>, "Kenneth
N Macpherson" <[EMAIL PROTECTED]> wrote:
_ Hello,
_
_ I am trying to find code (vb) that will take a string (all chars in range 33
_ to 126 ASCII) and encrypt it again using chars in range 33 to 126.
_
_ Reason for range is so users can type in the encrypted string from the
_ keyboard.
_
_ Although 127 is a keyboard char (deleteI think) it is not easily displayed!
_ ;-) .
_
_ Any help with code, urls, (or even an algo) would be fantastic.
_
_ Thanks in advance,
_
_ Ken
------------------------------
From: "Kenneth N Macpherson" <[EMAIL PROTECTED]>
Subject: Re: encrypt using ASCII 33 to 126 only?
Date: Mon, 14 Jun 1999 17:40:19 +0100
>
>> >Why not binhex/uuencode the encrypted 8 bit chars?
>
>Convert the binary output to hexadecimal. That way the only chars in
>are 0-9 and A-F but you can encode any byte.
So:
Encode using whatever method (non-printable chars ok) + key
Convert op to hex
Store as 0-9 and A-F (nice chars)
To go back:
Hex->bin
Bin->ASCII
Inverse encrypt using key
Magic (if that is right).
This means I can use any encryption algo (even some mad ones with
non-printables) and I can still store it with typeable chars!
If someone could confirm my meanderings or bring me down with a bang I would
be grateful!
Cheers,
Ken
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: I challenge thee :)
Date: 14 Jun 1999 09:28:07 -0400
In article <[EMAIL PROTECTED]>, smoke_em <[EMAIL PROTECTED]> wrote:
>Patrick Juola wrote:
>
>> You can't 'practically eliminate' frequency analysis unless your
>> codebook is so large that almost every message is a very few chunks
>> and codebook entries aren't repeated.
>
>Does this not apply to block ciphers as well or is it part of the
>definition of a (serious) block cipher that ECB lookup is not deemed
>practical?
It applies to block cyphers as well, which is one of the reasons that
ECB is regarded as less secure than the various feedback modes.
>> The problem is that I can calculate frequencies with almost arbitrary
>> precision *based on conditions that I know to obtain about you and your
>> messages.*
>
>Point taken, though i guess that applies to an attack on any cipher in
>varying degree - but can you also do it if i use CBC mode?
>The bit of frequency analysis (simple byte frequency of ciphertext) that
>i have done on a >600k ascii document shows that ECB mode does some
>work, but the sorted frequency curve still shares some characteristics
>with that of the plaintext. With CBC mode, the result was *a lot* closer
>to even distribution of frequency - with my newbie eyes no similarities
>came to mind.
Exactly.
-kitten
------------------------------
From: Anonymous <[EMAIL PROTECTED]>
Subject: Re: Has this cipher been broken yet ?
Date: Mon, 14 Jun 1999 17:25:50 +0200 (CEST)
Hello Tom,
Thanks for replying.
Atbash2
Developed by Michael Paul Johnson approx 1995
Use the Sapphire II stream cipher.
Dos file name ATBASH2.ZIP
Download from ftp.replay.com/pub/replay/pub/file
Once again thanks for your interest.
------------------------------
From: "Kenneth N Macpherson" <[EMAIL PROTECTED]>
Subject: Re: encrypt using ASCII 33 to 126 only? - SPEC
Date: Mon, 14 Jun 1999 16:23:59 +0100
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).
Any other spec required let me know.
Thanks for your continued help.
Ken
------------------------------
From: [EMAIL PROTECTED] (James Pate Williams, Jr.)
Subject: Re: IDEA in "aplied cryptography" BRUCE SCHNEIER
Date: Mon, 14 Jun 1999 15:33:05 GMT
On Mon, 14 Jun 1999 14:31:52 +0200, chciago <"gabriel.
nock"@siemens.de> wrote:
>or where can I find sources of IDEA which are working, I only want to
>use it for myself, not in a commercial way..
You can get a copy of a C implementation 7.101 Algorithm IDEA
encryption from _Handbook of Applied Cryptography_ by Alfred
J. Menezes et al. page 264 if you are a citizen of the United
States of America currently residing in the U.S. by emailing me
at the following address and requesting idea.c.
==Pate Williams==
[EMAIL PROTECTED]
http://www.mindspring.com/~pate
------------------------------
From: "Kenneth N Macpherson" <[EMAIL PROTECTED]>
Subject: Re: Spec
Date: Mon, 14 Jun 1999 16:24:54 +0100
Sorry - posted this to the wrong thread level - see the thread:
encrypt using ASCII 33 to 126 only?
Cheers,
Ken
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: IDEA in "aplied cryptography" BRUCE SCHNEIER
Date: Mon, 14 Jun 1999 14:07:26 GMT
In article <[EMAIL PROTECTED]>,
chciago <"gabriel. nock"@siemens.de> wrote:
> hey, i wanted to implement the IDEA-algorythm by the sources in bruce
> schneiers book....
>
> is there a fault in this codes, or am i only too silly, to copy code
> from a book, but : "it doesn't work"
>
> or where can I find sources of IDEA which are working, I only want to
> use it for myself, not in a commercial way..
I think there was a bug in the code. I would goto
http://www.counterpane.com
And check out the errata. Or you could disect PGP and take IDEA from
there :).
Tom
--
PGP key is at:
'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: Terje Mathisen <[EMAIL PROTECTED]>
Subject: Re: encrypt using ASCII 33 to 126 only?
Date: Mon, 14 Jun 1999 20:48:30 +0200
Kenneth N Macpherson wrote:
>
> Hello,
>
> I am trying to find code (vb) that will take a string (all chars in range 33
> to 126 ASCII) and encrypt it again using chars in range 33 to 126.
>
> Reason for range is so users can type in the encrypted string from the
> keyboard.
That's actually quite simple:
First compress the input, using LZ, Huffman or some other compression
algorithm:
This will reduce the length of your input data, since you've started
with a limited input range.
Then run any crypto algorithm you like on the compressed data, giving an
equal length encrypted output.
Finally encode the output using a binary to ascii encoding.
If you can use all 95 printable 7-bit ascii, then I'd suggest you encode
13 bits in each pair of characters, this works since the binary log of
95 is lightly over 6.5.
Good luck!
Terje
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
From: Greg Bartels <[EMAIL PROTECTED]>
Subject: Re: Followup: OTP is it really ugly to use or not?
Date: Mon, 14 Jun 1999 13:57:51 -0400
two copies of a 10 gigabyte DVD disk,
one for you, one for your friend.
rather than using the disk as a OTP,
you use it as a source of a wicked
complex pseudo random number generator.
Fill the disk with truly random numbers.
make a copy to the second disk.
reserve a megabyte or two of the disk
as true One Time Pad so that you can
transmit seeds to each other on occasion.
then, using the seed and the disk,
and a kick-butt one-way-hash, you generate
PRN which you then xor with your plaintext.
you could effectively diffuse the data
on the disk to stretch it out far beyond
the 10 gig limit. use several blocks of
Disk data to generate one block of Pseudo
OTP data.
every month or week or every message
(depending on your data rate/security
requirements) you use some of the reserved
data as a true one time pad to send
a new seed.
you could physically exchange one disk
with someone that could possibly last
a lifetime's worth of data exchange.
then again, who do you send 10 gigabytes
of data to, unless you wanted to encrypt
a video phone or something?
if you physically meet this person
more often than you send 10 gig to them,
then just burn a new CD everytime you see
them and hand it to them in person.
and use it as a straight one time pad,
no diffsion.
Greg
------------------------------
From: "Joe" <[EMAIL PROTECTED]>
Subject: Is there a short digest for short messages? Continued...
Date: Mon, 14 Jun 1999 19:04:19 GMT
> 1) Does anybody know a good message digest algorithm producing short
digests
> (<1,000,000) for messages in the range 2^64 to 2^160?
>
> 2) Would be MD4 modulo 1,000,000 good for that?
Thanks for all input on those questions. I would like to ask your comment
about the original problem (which brought up those questions and which I
maybe had to ask about in the first place). Anyway...
The original problem is quite common, it's software authorization. Obviously
only some part of it is a cryptology problem and it's worsened by some
practical restrictions. Let me describe it.
An user buys a program (including a hardware lock) from a software company.
Then she sends to the company an information identifying the program and
herself. The information consists of 1-2 DWORD program id (DWORD<2^32),
DWORD hardlock id, DWORD number of requested licenses, total is 3-4 DWORDs
and since not all values are valid this could be packed into 1-2 DWORDs.
The company checks that the user has indeed bought the program and sends
back to the user the message "Authorized for the given user's information".
Here the cryptology problem begins: the message must be signed (apparently,
only the signature needs to be physically sent back to the user).
0. Obviously the signature must somehow include the mentioned above
information from the user (since it signs the information)
1. The signature can be just the user's information encoded in some way.
Thus the size of the signature would be at least the same 1-2 DWORDs. But
the company asked to reduce signature to 6 decimal digits (based on the bad
previous experience with signatures of 15 alpha-numerical characters). So
this straightforward encoding is no good for us.
2. Thus the signature should be a digest of the user's information (up to 6
decimal digits). Here comes the question 1) stated above.
There are additional practical considerations which could influence a
theoretical solution.
a) The company wants a protection from a casual software piracy. Any
software authorization scheme could be broken by a determined attacker
because of the very nature of software authorization problem. So the company
does not want to burden honest users (most of users are honest) with any
complicated scheme.
b) Any particular user will have bought a limited number of programs (say
less than 17). So if the short digests(<1e6) will collide with the
probability 1e-3 (as was suggested in some reply) that's acceptable.
c) Signature verifier will implement a processing delay so a brute force
attack exploiting short length of digest would be impractical. (Attacker
would have to try on average 1e6/2 digests, if an answer is delayed by 30
secs, then the attack will succeed on average in 173 days. By then a new
version of the software could be on the market.)
============
My conclusions so far:
I'm going to use "a keyed message signature: have a secret key k (e.g. 128
bits) shared between signer and verifier, and sign a message M with H(k,M).
...shorten the result, by keeping 20 bits or taking the result mod 1e6" as
was suggested.
I welcome and very appreciate any comments on the subject,
Joe
------------------------------
From: Greg Bartels <[EMAIL PROTECTED]>
Subject: Re: SLIDE ATTACK FAILS
Date: Mon, 14 Jun 1999 11:15:40 -0400
I've been skimming messages on this thread for
a while now, mainly because I wouldn't have time
to ever read all of them.
if you wish to publish code without feedback,
then put it on your web page, post an announcement
here, and in the post, mention that you really
arent interested in any feedback, you just want
people to stare and wonder in awe of it.
then, everyone will at least know where you're
_really_ coming from.
and if everyone here is only good at playing
with crypto toys, then why not spare yourself and us the bother
and just not post the announcment here at all.
Greg
"lo, I am become death, the destroyer of worlds"
modern day translation:
"killfile, killfile, where oh where is my killfile"
"SCOTT19U.ZIP_GUY" wrote:
>
> 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 built to there
> speicifications. But my stuff they declare dead
> since I don't do things the way they do but when
> the acid test was done they where flat wrong.
> Sorry guys stick with breaking toy stuff
> no wonder your not working for the NSA.
> Maybe I should reword that maybe you are working
> for the NSA people still think you guys are actually
> trying to help people write secure code.
> I think Ritter is doing his best to stay a breast
> of the real advances in encryption but you guys
> aren't. If it is not spoon fed to people like you
> you pretend it doesn't exist. Sorry it does it exists
> and people are getting smarter every day. They
> are smart enough to see the need for encryption
> methods that work and can treat a whole file
> like a single block unlike the toy ciphers that
> you are more familar with.
>
> 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
------------------------------
** 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
******************************
