Cryptography-Digest Digest #751, Volume #9 Wed, 23 Jun 99 03:13:02 EDT
Contents:
Re: DES and a GRNN or RBFNN (Warren Sarle)
Re: A different method of encryption (AllanW)
Experimental Characterization of Recorded Noise (Terry Ritter)
Re: Just a small question ([EMAIL PROTECTED])
Critique of Street Performer Protocol paper (Anonymous)
Kryptos sculpture on Today Show (Jim Gillogly)
Re: A different method of encryption ([EMAIL PROTECTED])
Re: Question related to letter frequencies... (Tibaht)
Re: Experimental Characterization of Recorded Noise (John A. Sidles)
Re: winzip cipher and "dense ones" (followup) (Sundial Services)
Re: crack the winzip files with password ("Mulva")
How about using RSA in CBC mode? (Rob Beckers)
Re: How about using RSA in CBC mode? (S.T.L.)
Re: crack the winzip files with password (JPeschel)
Re: How about using RSA in CBC mode? (David A Molnar)
Re: Cipher (David Hamilton)
Re: News Group Folder Empty (JPeschel)
----------------------------------------------------------------------------
Crossposted-To: comp.ai.neural-nets
From: [EMAIL PROTECTED] (Warren Sarle)
Subject: Re: DES and a GRNN or RBFNN
Date: Tue, 22 Jun 1999 21:40:04 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (James Pate
Williams, Jr.) writes:
|> If one looks at a plot of DES encryption function over the domain
|> [0, 255] with the key {127, 255} it resembles a white noise plot.
|> What hope would we have of learning the complete DES function
|> by using a general regression neural network (GRNN) or radial
|> basis function neural network (RBFNN) over [0 , 255]?
If you mean using that specific key and no others, you should be
able to learn the training data exactly if you use 256 RBFs, or
a GRNN with a very small smoothing parameter (which amounts to
nearest neighbor in this situation). You might even be able
to use fewer RBFs. But a simple table look-up would be an
awful lot faster.
|> Would a GRNN or
|> RBFNN generalize (extrapolate) to interpolate the function values
|> for [256, 511]?
Absolutely not.
|> The domain of the DES encryption function is:
|> [0, 2 ^ 64 - 1] and it has the same range.
Then you can learn the whole thing with 2^64 RBFs.
--
Warren S. Sarle SAS Institute Inc. The opinions expressed here
[EMAIL PROTECTED] SAS Campus Drive are mine and not necessarily
(919) 677-8000 Cary, NC 27513, USA those of SAS Institute.
------------------------------
From: AllanW <[EMAIL PROTECTED]>
Subject: Re: A different method of encryption
Date: Tue, 22 Jun 1999 21:28:31 GMT
[EMAIL PROTECTED] wrote:
> I believe I have stumbled upon a method of encryption that
> uses not mathematical but logical locks to protect the encrypted from
> being decyphered. Fortunately, the method is simple enough to explain
> in this text.
[Snip very good explanation of how OTP's work]
[Snip sample code]
Others in this thread have mocked your idea as exceptionally
obvious. But in fact, it is not obvious until you have been
exposed to the idea. (Reading the FAQ would have been a good
idea, though.) However, the idea has been around for some
time. Replace your phrase "password" with the phrase "key"
and you have a very good explanation of the basics of the
OTP: One Time Pad.
There are some practical problems with the idea. The biggest
problem is how to transmit the key to the receipent, without
transmitting it to potential interceptors. If you have a
totally secure method of doing this, then you might just as
well send plaintext without bothering to encrypt the file!
One obvious way around this problem is to use a known
reference, such as a file that already exists on both computers
and is known to be identical. However, this is a bad idea. If
you re-use the same file several times, there are algorithmic
ways to determine what the reference file is -- and then all
messages are broken.
A better scheme (but still not foolproof) is to use some
known secret phrase to seed a pseudo-random-number generator.
Then you can generate as many bytes as needed for the key.
If both sides know the secret phrase, they can both generate
the same pseudo-random numbers, and the decryption succeeds.
A similar problem occurs if the key is shorter than the message
to encrypt. Re-using bytes from the beginning of the key can
make the process much less secure. Depending on how far you take
this, the message might still be fairly hard to crack, or it
might be child's play to crack -- consider the extreme case,
where you have a 1-byte key. One way to reduce this problem is
to modify (a copy of) the key as you use it, so that when you
go back to the first byte it no longer has the same value that
it did the first time you used it.
In fact, most encryption algorithms do almost precisely that.
They generate a key of some specific length, hopefully as
random as possible. Then they use the values in the key to
manipulate the text and encrypt it. The algorithm changes the
key as it works. Even though the byte values of the key have
changed, they are still used repeatedly, which weakens the
encryption strength. To bolster it, the algorithms also change
the order of the encrypted bytes in some way dependant on the
values in the key. Naturally, all of this has to be un-done
in order to decrypt.
The "PGP" program uses a variation on this scheme. The basic
operation of the program uses a very secure public-key
encryption algorithm, but that algorithm is very slow. So
rather than use it for the entire message, it generates a
random key and uses it to encrypt the message. (I think that
this key can be shorter than the message, which means it
isn't literally an OTP, but the concept is similar to your
"method 2".) Then it uses the strong publick-key encryption to
encrypt a copy of the random key, and attaches this to the
beginning of the message! That's how PGP allows you to encrypt
one message to be read by multiple people -- it saves multiple
copies of the encryption key, each copy encrypted with a
different public key.
Don't give up. Your idea is mathematically sound. Look for
ways around the problems. You have a good start, here.
--
[EMAIL PROTECTED] is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Experimental Characterization of Recorded Noise
Date: Tue, 22 Jun 1999 22:01:20 GMT
I have just placed on my pages the second phase of my work on random
noise generators: Experimental Characterization of Recorded Noise
http://www.io.com/~ritter/NOISE/NOISCHAR.HTM
This work includes 25 HTML sub-pages, each of which contains 3 unique
.GIF graphs for frequency spectrum, autocorrelation, and normal
distribution comparison. Certain unexpected flaws expose themselves
clearly on the graphs; the usual statistics are also computed but seem
less helpful.
If anyone has trouble with the HTML or links, or the graphs, please
let me know. As always, I would be glad to receive comments on the
HTML format or content.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Just a small question
Date: Tue, 22 Jun 1999 06:46:21 GMT
[ Sylvie Estrada ] <[EMAIL PROTECTED]> wrote:
> can anyone suggest a begginers book about cryptology? I am an engineer,
> and good with math. I just became interested in the topic, but I need
> the very basics.
Applied Cryptography.
http://www.amazon.com/exec/obidos/ASIN/0471117099
--
jakdaemon << berkeley is my baby and i want to kill it
------------------------------
From: Anonymous <[EMAIL PROTECTED]>
Subject: Critique of Street Performer Protocol paper
Date: Wed, 23 Jun 1999 01:37:10 +0200 (CEST)
[EMAIL PROTECTED] writes:
> Anonymous <[EMAIL PROTECTED]> wrote:
> > A customer will
> > want to buy a box that can play secured data if that data is much less
> > expensive than non-secured.
>
> You picked an auspicious time to argue this. The first major
> encrypted perimeter content system, Circuit City's "DIVX" has
> just gone belly up after they sunk a reported $200 million into
> it. See http://www.divx.com
You probably meant "inauspicious", since this event would seem to be
evidence against my claim that consumers would pay for limited devices.
However, another recent product introduction is more consistent with my
suggestions, a low-cost device for special purpose Internet browsing,
with a non-Windows OS that might offer higher hopes for security. This
is the iToaster, announced yesterday by Microworkz.com. It is said to
use a "hybrid" OS, based on Linux and BeOS.
While this may not be the perfect machine for viewing secured data, it
is an example of a non-Windows machine with a custom OS, used for
specialized purposes. This is exactly the niche into which a high
security machine for viewing copyrighted data might fall.
An independent news article about the iToaster is available at
http://www.news.com/News/Item/0,4,38074,00.html
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Kryptos sculpture on Today Show
Date: Tue, 22 Jun 1999 15:45:26 -0700
For those following the Kryptos sculpture decryption story, the
Today Show is planning to run a short segment on it on Thursday;
current scheduling is for the latter part of the 7:00-7:30 segment,
but of course that is highly variable.
Before they started filming, the sound guy looked at me and said
to the camera guy "We won't need the hair light this time." I
cocked an eyebrow at him and he had the grace to blush. I figure
five points each.
--
Jim Gillogly
Midyear's Day S.R. 1999, 22:42
12.19.6.5.7, 11 Manik 15 Zotz, Eighth Lord of Night
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: A different method of encryption
Date: Wed, 23 Jun 1999 00:27:35 GMT
Reply-To: [EMAIL PROTECTED]
In article <7kov5h$km5$[EMAIL PROTECTED]>,
AllanW <[EMAIL PROTECTED]> wrote:
> Don't give up. Your idea is mathematically sound. Look for
> ways around the problems. You have a good start, here.
Thanks; not everyone is so kind to newbies, or faithful of their
potential. The problems do indeed seem almost trivial, yet I must be
certain of one thing: given a plaintext file of unpredictable binary
data (as opposed to predictable text), and given a completely random
key file (not pseudo-random, but something I may have pecked away the
hexadecimal myself while half-asleep), is it possible to create an
encrypted file of **absolute** uncrackability (also given the absolute
protection of the plaintext and key files)? (True, I could simply
protect the plaintext file, but the issue here is not convenience but
iron-clad logic.) If no, where are the holes? (In other words, if c + d
= 122, how do you find c, or reduce the range of possible values for
c?) Also, given the same conditions above (especially the
unpredictability of the plaintext file), will the security hold if I
repeat the key file?
I suppose I probably could have found the answers to these and many
more questions if I read the faq, but somehow this seems more direct.
Thanks in advance!
--
Order breeds knowledge. Knowledge breeds order.
Chaos breeds ignorance. Ignorance breeds chaos.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Tibaht)
Subject: Re: Question related to letter frequencies...
Date: 23 Jun 1999 01:08:56 GMT
I'm just a newbie, but would like to find out more about 2 and 3 letter
grouping probabilities. where can i find some information? Thanks
------------------------------
From: [EMAIL PROTECTED] (John A. Sidles)
Subject: Re: Experimental Characterization of Recorded Noise
Date: 23 Jun 1999 01:43:24 GMT
In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
>
>I have just placed on my pages the second phase of my work on random
>noise generators: Experimental Characterization of Recorded Noise
>
> http://www.io.com/~ritter/NOISE/NOISCHAR.HTM
>
Dear Terry ...
You've got noise, well, I've got freely-available
LabView vi's that will test the statistical properties
of the noise! Plus a reasonably complete and
student-friendly TeX/PDF write-up of the statistical
tests embedded in the vi's. Go to:
ftp://ftp.u.washington.edu/public/sidles/MRFMLabViewVis/
These vi's will be useful mainly to experimentalists
who want to check whether their observed noise is
indeed OU noise.
One caveat --- these vi's test only one kind of noise:
Ornstein- Uhlenbeck noise (OU noise). Fortunately, OU
noise is ubiquitous; OU noise is what you get out of a
lock-in amplifier when the input noise is broad-band.
More formally, OU noise processes are Gaussian, stationary,
and Markovian. It follows by Doob's theorem that OU noise
has an exponential correlation function.
Another caveat -- the published literature on noise
analysis is rife with typographic errors. I have
corrected all that I found, yet my own analysis likely
has errors too!
Good luck .... JAS
------------------------------
Date: Tue, 22 Jun 1999 20:02:45 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: winzip cipher and "dense ones" (followup)
To all the gentlebeings who have flooded my mailbox with messages and
"challenge" files ... peace!
I do not claim to have a general, guaranteed "crack" to this cipher;
there were times that the computer ran for days without coming up with
the (known) solution! But I -did- find in my experimentation that there
are things you can know about the "correctly decoded" ciphertext, vs.
the garbage you get when the key is wrong.
For example, what I referred to as "dense ones" might better be
expressed as bit-frequencies, bit-runs, or the conditional probability
that, in certain parts of a file, "if bit 'n' is assumed to be 1, what
is the probability that bit 'n+1' is also 1? n+2?" What is the
distribution of the byte values (or, their shifted bytes, because this
is actually a bit-stream not a byte-stream?
Each portion of the compressed stream presents very strong
characteristics but these must be examined using bits not bytes.
It turns out that you can explore key-combinations (or even, portions of
keys) based on the knowledge that the correctly deciphered text will
exhibit certain frequency-characteristics and incorrectly deciphered
text will not. Unlike Conrad's work you do not know what any byte
actually will be. But you can hypothesize what it and its neighbors
might be.
Again, it is not a "crack," but it does pursue the same basic weakness
of the cipher, exploited in the published known-plaintext attack, using
less-exact knowledge.
Also bear in mind that you have a *collection* of ciphertexts which, one
may assume, were enciphered using the same key. The fact that it is a
stream-cipher means that it is not a simple "depth," but if a particular
key produces a "probable" in one and "garbage" in another...
------------------------------
From: "Mulva" <[EMAIL PROTECTED]>
Subject: Re: crack the winzip files with password
Date: Tue, 22 Jun 1999 22:34:02 -0400
Do you perchance have a link to the location of Conrad's source code for
a know plaintext attack against (pk)zip? Thanks.
Sundial Services wrote in message <[EMAIL PROTECTED]>...
>JPeschel wrote:
>> (snip)
>> Mount a known-plaintext attack. For info
>> on the format see the Kocher/Biham paper,
>> also Conrad's source code for the implementation.
>(snip)
>
>At one time I pursued Conrad's work further to explore a "probable
>plaintext" approach because much of the frequency-characteristics of a
>ZIP-encoded file are predictable regardless of what the plaintext is.
(snip)
------------------------------
From: Rob Beckers <[EMAIL PROTECTED]>
Subject: How about using RSA in CBC mode?
Date: Tue, 22 Jun 1999 23:52:42 -0400
At the risk of asking a rather naive question:
PKCS#1 prescribes how RSA should be used to avoid common security
pitfalls. One of the recommendations there is to pad data blocks with 11
bytes, in part to ensure the data is smaller than the modulus, in part
to to avoid low encryption exponent attacks (from my rather limited
understanding of RSA and its associated problems). My question is if
using CBC mode (like a regular block cypher) would have the same effect
on security while allowing 10 more bytes of data per block to be
encrypted (I guess the leading 0 will have to be left in place to avoid
overflow of the data, or rather, make this 40h or so to ensure a large
data value).
Any comments?
Thanks!
Rob
------------------------------
From: [EMAIL PROTECTED] (S.T.L.)
Subject: Re: How about using RSA in CBC mode?
Date: 23 Jun 1999 04:14:29 GMT
For an even more naive question: Hey, think you could point me to PKCS#1? I'm
interested in reading it now. :-D
-*---*-------
S.T.L. ==> [EMAIL PROTECTED] <== BLOCK RELEASED!
~~~ My quotes page is at: http://quote.cjb.net ~~~ 2^3021377 - 1 is PRIME!
~~~ My main website is at: http://137.tsx.org ~~~ F0 0F C7 C8
"Xihribz! Peymwsiz xihribz! Qssetv cse bqy qiftrz!"
I have released my E-mail block. Address is correct as it is. I believe the
courtesy of providing a correct E-mail address is more important than having
to delete junk, which gets through anyway. The block will simply go up again
if I am bombed again. I don't care, and it's an easy solution. If you see a
message of mine posted on two newsgroups, then it is because I have replied
to a crossposted message. I *never* crosspost of my own accord!
This signature contains 3910 bits of entropy.
-*---*-------
Patiently awaiting the launch of Gravity Probe B
Card-holding member of the Great SRian Conspiracy
Card-holding member of the Dark Legion of Cantorians
Avid watcher of "World's Scariest Warp Accidents"
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: crack the winzip files with password
Date: 23 Jun 1999 04:06:29 GMT
><[EMAIL PROTECTED]>writes:
>Do you perchance have a link to the location of Conrad's source code for
>a know plaintext attack against (pk)zip? Thanks.
Sure.
http://www.unix-ag.uni-kl.de/~conrad/krypto/pkcrack.html
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: How about using RSA in CBC mode?
Date: 23 Jun 1999 04:24:24 GMT
S.T.L. <[EMAIL PROTECTED]> wrote:
> For an even more naive question: Hey, think you could point me to PKCS#1? I'm
> interested in reading it now. :-D
Try www.rsa.com/rsalabs/pubs/PKCS/index.html
Just make sure you two are discussing the same version of PKCS #1.
-David Molnar
------------------------------
From: [EMAIL PROTECTED] (David Hamilton)
Subject: Re: Cipher
Date: Tue, 22 Jun 1999 17:48:40 GMT
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
(snip)
> Actually if you cipher is any good you will get few comments. However
>if it has errors you will get pleanty of comments.
Obviously false. For example, a cipher can be so weak that only one comment
is needed to show this. In addition, there are other reasons that can
determine the number of comments received. In the case of David A. Scott,
UNprofessionalism is just one.
>Many people who read
>post here are to lazy to bother to look at webpages where the code is
>discribed or even look at the source code you may porvide.
There are other reasons for not looking at web pages and/or source code. Yes,
you've guessed it: in the case of David A. Scott, again, UNprofessionalism is
just one.
>If it is really
>good they will dismiss it as easy to break but will never bother to prove
>it.
Proof is good, assertions are cheap. Which reminds me: is it true that you
asserted that you would break IDEA? Have you done so? Have you any proof that
you have done so? (As usual, David A. Scott will refuse to answer IDEA crack
questions. Guess why.)
(snip)
David Hamilton. Only I give the right to read what I write and PGP allows me
to make that choice. Use PGP now.
I have revoked 2048 bit RSA key ID 0x40F703B9. Please do not use. Do use:-
2048bit rsa ID=0xFA412179 Fp=08DE A9CB D8D8 B282 FA14 58F6 69CE D32D
4096bit dh ID=0xA07AEA5E Fp=28BA 9E4C CA47 09C3 7B8A CE14 36F3 3560 A07A EA5E
Both keys dated 1998/04/08 with sole UserID=<[EMAIL PROTECTED]>
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: Signed with 2048 bit RSA key
iQEVAwUBN2/Lgso1RmX6QSF5AQHeIQf/f7z+f7HGTExdFhxzJ70nPovHmRGpaKow
i88JfRyrIRy4h+owspqn4k3KGVYQYVCi0qb7yre4Vm1jxjiz49HQnHZtoqOEiaaZ
BzZ5Qj56ABFF2DLs+MhovmgORt4fnpFVJQCKwcuOWn0VnGQbbxmpYH6Tmc6bCeGX
4E78XKj3FiannNAjUYwBcyNvpzou8LBdAqwePsfEzjyx42Idw1h2FFCWlvN9BKOO
BLa0r66dD4AMw23u8Z+O0aEd50+wXPPedv85UJLzN3FS6jpZEkNYmTfKyRoPGA+K
c9IqZYCQCTLElVkhAqCs63lsyBEwuJwk+eUEwjA4/aYmcJCGcqi0jw==
=2SmF
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: News Group Folder Empty
Date: 23 Jun 1999 05:50:01 GMT
><[EMAIL PROTECTED]>writes:
>I have never seen this news group without messages. I suspect that
>there is something wrong with my new ISP's news server. Can anybody
>tell me which it is?
>
>
They probably don't save 'em for long. Use another server.
J
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
** 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
******************************
