Cryptography-Digest Digest #560, Volume #9 Tue, 18 May 99 13:13:03 EDT
Contents:
Re: Fractal encryption (David A Molnar)
Re: True Randomness & The Law Of Large Numbers (R. Knauer)
Re: prime numbers and the multplicative inverse ([EMAIL PROTECTED])
Re: Can Somebody Verify My DES execution? (Matthias Bruestle)
Re: AES (Bruce Schneier)
Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO (SCOTT19U.ZIP_GUY)
Re: Need a simple encryption/decryption algorithm (Russell Harper)
Re: prime numbers and the multplicative inverse (Bob Silverman)
Re: Computer-generated random numbers (was Re: Magic) (John Savard)
Re: where can i find a frequency list? (John Savard)
Re: Can Somebody Verify My DES execution? ([EMAIL PROTECTED])
SV: prime numbers and the multplicative inverse ("Claes & Gunn Irene")
Re: Mandlebrot transform (John Savard)
Re: Can Somebody Verify My DES execution? (Robert G. Durnal)
----------------------------------------------------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Fractal encryption
Date: 18 May 1999 05:25:44 GMT
Lysergide <[EMAIL PROTECTED]> wrote:
> i have been searching the www and newsgroups for technical
> information/papers/methods etc about fractal encryption and ways of
> making an excryption algorithm from fractal formulae, can anyone help
> me out with some information/papers etc on fractal encryption, or any
> urls that anyone may know of. (as i cant seem to find any that are of
> any benefit, and have been looking for over 3 months!)
> thankyou :)
Will steganography do for a start? I found this reference :
Paul Davern, Michael Scott. Fractal Based Image Steganography,
i Information hiding: first international workshop, Cambridge, UK.
Springer Lecture Notes. No. 1174 1996. pp. 279-294.
from
http://www.jjtc.com/Steganography/bib/3000009.htm
and the University of Waterloo has a really short blurb about using
fractal representations for compression and error-correcting codes.
Maybe you could apply similar constructions to info-theoretic
security and/or secret sharing ?
-David
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Tue, 18 May 1999 12:10:14 GMT
Reply-To: [EMAIL PROTECTED]
On Sun, 16 May 1999 11:00:35 -0400, [EMAIL PROTECTED] wrote:
>> "The frequency concept based on the limiting frequency as the number
>> of trials increases to infinity does not contribute anything to
>> substantiate the application of the results of probability theory to
>> real practical problems where we always have to deal with a finite
>> number of trials."
>> --Kolmogorov (quoted in Li & Vitanyi, p. 55)
>This is a matter of opinion not science. And he's wrong.
I just love this! Usenet Twats taking on the giants of mathematics.
Such utter arrogance is unsurpassed anywhere else in the history of
science.
>> "We shall encounter theoretical conclusions which not only are
>> unexpected but actually come as a shock to intuition and common sense.
>> They will reveal that commonly accepted notions concerning chance
>> fluctuations are without foundation and that the implications of the
>> law of large numbers are widely misconstrued. For example, in various
>> applications it is assumed that observations on an individual
>> coin-tossing game during a long time interval will yield the same
>> statistical characteristics as the observation of the results of a
>> huge number of independent games at one given instant. This is not so.
>> Indeed, using a currently popular jargon we reach the conclusion that
>> in a population of normal coins the majority is necessarily
>> maladjusted."
>> --Feller, p. 67.
>Shock value. Exaggeration in order to provide drama. It works for
>books just as it does for TV shows and movies. But we only expect
>10-year-olds to be taken in by these techniques.
LOL
>Grow up.
You grow up.
<plonk>
Bob Knauer
"There is much to be said in favour of modern journalism. By giving us the opinions
of the uneducated, it keeps us in touch with the ignorance of the community."
-- Oscar Wilde
------------------------------
Date: Tue, 18 May 1999 07:31:45 -0400
From: [EMAIL PROTECTED]
Subject: Re: prime numbers and the multplicative inverse
[EMAIL PROTECTED] wrote:
>
> I haven't been able to find an answer to this question. Why does IDEA
> use a prime field for it's multiplication?
>
> Does the field need to be prime to have a multiplicative inverse?
Prime fields have multiplicative multiplicative inverses. I.e., the
inverse operation is multiplication by another value rather than
division by the orginal multiplier.
------------------------------
From: [EMAIL PROTECTED] (Matthias Bruestle)
Subject: Re: Can Somebody Verify My DES execution?
Date: Tue, 18 May 1999 12:31:17 GMT
Mahlzeit
I have a similar question:
Are there test vectors for wrong implementations?
E.g. "You got this vector, so you did not convert this into the
correct endianness."
Mahlzeit
endergone Zwiebeltuete
--
PGP: SIG:C379A331 ENC:F47FA83D I LOVE MY PDP-11/34A, M70 and MicroVAXII!
--
DO :1 <- #0$#256
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: AES
Date: Tue, 04 May 1999 21:39:14 GMT
On Fri, 30 Apr 1999 13:12:52 -0500, "Anthony King Ho"
<[EMAIL PROTECTED]> wrote:
>There is sometimes wonder comes cross my mind why the AES is necessary.
Good question, actually. Certainly triple-DES is more than secure
enough for the forseeable future, and has the benefit of being
well-studied and well-trusted.
>I
>thought security is not based on the algorithm itself,
It certainly is. If the algorithm is bad, no key length can save it.
A long key is necessary for security, but not sufficient.
>key length can be
>increased to increase security
Not all algorithms have a variable-length key. Triple-DES, for
example, has a 112-bit key.
>and algorithm such as Triple-DES is proven
>to be very secure.
Agreed.
There are a few reasons to have AES. The first is that DES was
designed for mid-70s hardware, and is sluggish in software. The
leading AES candidates are about 8 times faster on high-end CPUs than
triple-DES. They are also more flexible on 8-bit smart cards, 64-bit
CPUs, ARM processors, standard cell hardware implementations, parallel
processors, etc.
The second is that DES (and triple-DES) has a 64-bit block. AES has a
128-bit block. There are applications where the shorter block length
has security implications.
The third is that it's about the most fun you can have as a block
cipher designer. And I thank NIST for doing this.
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO
Date: Tue, 04 May 1999 21:49:40 GMT
In article <[EMAIL PROTECTED]>,
Geoff Thorpe <[EMAIL PROTECTED]> wrote:
> Kind of like the very fact that the candidate will decompress into a
> valid plain-text. All you're doing is forcing the attacker to run a
> decompression off the back-end of a decryption (with candidate key) at
> the same time as forcing the encrypter to run a compressor on the front
> end of an encryption. In terms of entropy arguments it's bogus too - if
> the known-presence of a "Z" at the end of the plain-text (or even at the
> beginning!) leads to any direct improvement for the attacker (in pruning
> out candidate keys BEFORE THEY'RE APPLIED) then the cipher system itself
> is fundamentally flawed ... proper application of a good chaining method
> (off an IV) should require essentially brute-force application of the
Actually you can't prove any of the common methods DES or IDEA or
the like are not fundamentally flawed as you decribe above. Just
becasue no one in the free press has published attacks for such does
not mean they are there. It is best not to have anything that can
lead to the weakness if they are flawed. an IV using regular chaining
is much overrated. Take IDEA use an IV encrypt a large file. Then
change the center byte of file. And then decrypt. Any a small portion
of the file has changed. The way an IV is used is flawed in most methods.
Try doing the same thing with scott16u or scott19u and use the random
padding (IV if you like) it is a different story
> decryption function (or the decryption function + decompression
> function) before detecting such candidates that do or do not contain the
> "Z". It's just a linear extension in time required to attack - which
> would be much better spent increasing the key-size of the cipher (where
> a linear extension in time for encryption results in a typically
> exponential extension of expected "attack" time).
>
Again if you want a big key cipher it is hard to beat scott19u
> Learning better English would help you communicate your thoughts a
> little better ... learning some common courtesy and manners would
> improve the reception they receive. And just learning, rather than
> ranting (or preaching, or whatever verb you prefer) would probably
> improve the quality of the thoughts themselves.
>
I like making people think. I don't care if my eglish sucks
I am more interested in learning Spanish.
David Scott
--
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
to email me use address on WEB PAGE
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Russell Harper <[EMAIL PROTECTED]>
Subject: Re: Need a simple encryption/decryption algorithm
Date: Tue, 18 May 1999 14:32:22 GMT
Paul Rubin wrote:
> This would be a very simple block cipher application, except for the
> above constraints. So you have to be more specific about the constraints:
>
> * What arithmetic and logical operations are available? Do you have
> addition and XOR? Do you have shifts? Do you have multiple shifts?
> (I.e. can you shift A by B bits, where A and B are both variables)?
> Do you have multiplication?
> * Can you store some fixed tables (say 256 entries of 32 bits each)
> and look things up in them?
> * Do you also have severe constraints on the amount of program space
> or RAM that you can use? On the number of instructions you can
> run before the cipher gets too slow?
>
> Also, how much security do you need? Enough to slow down the casually
> curious? Enough to stop supercomputer attacks by the NSA? Somewhere
> in between?
>
> It would help if you said exactly what the application platform is.
Thanks for reading! Here's some more information...
Shortly we will have a webpage that in turn accesses several other ones. These
web pages are accessed via parameters:
http://www.flabbergasted.com/survey/hitech/go.cfm?CRID=2001
http://www.flabbergasted.com/survey/hitech/go.cfm?CRID=2002
http://www.flabbergasted.com/survey/hitech/go.cfm?CRID=2003
http://www.flabbergasted.com/survey/hitech/go.cfm?CRID=2004
and so on...
Each page is a separate survey intended for only one department of a client,
and data is submitted by these pages. '.../go.cfm' is a Cold Fusion markup
page - Cold Fusion is basically an enhancement to allow DB access through HTML
web pages. It has arithmetic operators: + - * / and logical operations AND OR
NOT XOR on 32 bit integers. As well I made a mistake when I mentioned it had
no loops - it has 'for' and 'while', as well as arrays. Since Cold Fusion is
database oriented, table lookup is available, although the person implementing
it has mentioned that he would much prefer if the algorithm is entirely
formula based. There's lots of RAM and the language runs about as fast as any
scripting language.
The security problem is that it is possible for anyone to change the CRID to
any other number, and submit some unfavourable surveys to a department for
which they aren't affiliated.
I thought of appending a CRC checksum:
http://www.flabbergasted.com/survey/hitech/go.cfm?CRID=2001?CS=____
http://www.flabbergasted.com/survey/hitech/go.cfm?CRID=2002?CS=____
http://www.flabbergasted.com/survey/hitech/go.cfm?CRID=2003?CS=____
http://www.flabbergasted.com/survey/hitech/go.cfm?CRID=2004?CS=____
and so on...
Which has some advantages - in particular the original client '2001' is
available in the web address (in case someone calls us with problems). This is
my preference, and if anyone knows where I can find a way to generate 'good'
CRC polynomials other than the one used in XMODEM, that would be great. I
don't think we need any more security than this.
And as another option, I'm also exploring the option of using a completely
encrypted CRID.
We'll make a selection from all the available methods and use what we think is
the best one.
Thanks again...
Russell
[EMAIL PROTECTED]
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: prime numbers and the multplicative inverse
Date: Tue, 18 May 1999 14:15:35 GMT
In article <7hrgi1$1or$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I haven't been able to find an answer to this question. Why does IDEA
> use a prime field for it's multiplication?
I'm not sure I understand the question. Do you mean why it uses
GF(p) as opposed to GF(2^n)?? Or do you ask why it uses a finite
field in the first place?
>
> Does the field need to be prime to have a multiplicative inverse?
Huh? *Every* element in a field (except 0) has a multiplicative
inverse. What do you really want to ask here?
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: rec.arts.sf.science
Subject: Re: Computer-generated random numbers (was Re: Magic)
Date: Tue, 18 May 1999 16:42:25 GMT
"Riboflavin" <[EMAIL PROTECTED]> wrote, in part:
>[crossposted to sci.crypt]
That is, a crosspost was added.
>Frank Palmer wrote in message <7hmo5v$qeq$[EMAIL PROTECTED]>...
>>: [EMAIL PROTECTED] (Frank Palmer) writes:
>>: > Start with text, rotate each byte, XOR with the next byte;
>>: > repeat nine times. Result, random bytes.
I assume this means: Process ASCII text input as follows: divide it
into groups of nine characters. Start with the first character in the
group. Repeat the following eight times: rotate the current value one
bit left (or right), then XOR it with the next character. Advance one
character.
>>"Random byte" simply means that the preceding bytes provide no way of
>guessing
>>which byte will come next. Each byte provides 8 bits of information.
>>All the text need do is contain information for this system to work after
>some
>>number of repetitions. English text generally contains 1 bit of
>information
>>per letter. I used 10 letters to provide some margin.
I see I was wrong, there will be nine rotations, as the text is
divided into groups of 10 characters.
>>It wouldn't work for pages of the letter, A; it would work for normal
>English
>>text.
>No, this would not produce random numbers (unless you perform your XORs an
>infinite number of times). The numbers might look random to a casual glance,
>but would have certain patterns that would make any crypto based off of them
>much easier to crack. I crossposted this to sci.crypt, I think one of the
>experts there can do a better job of explaining why this is so than I can.
You're right that this system would not produce perfect random
numbers, that is, numbers as absolutely free of any pattern as numbers
generated by flipping coins.
Whether these numbers would, however, come close enough to being
random to be adequate as a stream cipher is another matter.
If one is going to use text as a source of stream cipher bits, even if
one is using a high-quality cryptographic hash function, there is
another weakness in such systems to consider. Probably, instead of
using text that no one else has ever seen, it is intended to use the
text of, say, a book that both parties have copies of as the key.
Someone knowing that this technique is being used could try a lot of
different books - and solve the cipher in this fashion.
Considering the algorithmic parts of the proposed method, can we say
anything?
The system proposed isn't all *that* bad, but there will be *some*
pattern to the 'random' bits.
Let us consider only 'easy' bytes. I will define an 'easy' byte as one
that results from a sequence of 10 ASCII characters that consists ONLY
of spaces and lowercase letters. (No capital letters, no punctuation
marks, no digits.) For typical text, a significant portion of the
bytes will be in this category.
The ASCII code for a space is 00100000. For a lowercase letter, the
ASCII code is 011ABCDE.
For each of the five LSBs, the letters for which it is 0 or 1 are:
A:
0 abcdefghijklmno
1 pqrstuvwxyz
B:
0 abcdefgpqrstuvw
1 ghijklmnoxyz
C:
0 abchijkpqrsxyz
1 defglmnotuvw
D:
0 adehilmpqtuxy
1 bcfgjknorsvwz
E:
0 bdfhjlnprtvxz
1 acegikmoqsuwy
For each of the bits, there are common letters taking either values.
Bit E is always 1 for a vowel. 0 seems to be slightly likelier than 1
for the other bits.
Also, when the last letter in the group of 10 letters matches the
current plaintext letter, the result will be like the product of a
group of 9 letters.
It seems like there is not too much here to exploit. Depending on the
direction of rotation, common digraphs and trigraphs will make certain
patterns, using up part of the 10 letters.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: where can i find a frequency list?
Date: Tue, 18 May 1999 16:31:15 GMT
[EMAIL PROTECTED] (Pete) wrote, in part:
>i used to have a book that had marvellous frequency tables, digraphs,
>double letters, etc. the book was stolen from me a long, long time ago
>and i can't remember what the title was.
>i looked in the faq, and the faq doesn't really answer the question.
>can someone point me to frequency tables on the net? if none exist (that
>are known) can you point me to a book with a decent one?
Try the Crypto Drop Box, at:
http://www.und.nodak.edu/org/crypto/crypto/
Also, from Dover, there is an inexpensive book, entitled
"Cryptanalysis", by Helen Fouche Gaines, which has extensive frequency
tables: it may be the one you remember.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Can Somebody Verify My DES execution?
Date: Tue, 18 May 1999 16:27:42 GMT
If you have Excel97 I implemented DES using Excel. Itshows the bit
values for each iteration. It is quite cool, I I should say so myself.
I am happy to send it to anyone that would like it. However, I would
much rather post it somewhere for anyone that wants it to download. If
anyone knows of a site I can upload it too, please let me know.
In article <7hntt4$jqj$[EMAIL PROTECTED]>,
"Zulkifli Hamzah" <[EMAIL PROTECTED]> wrote:
> Hi Forum,
>
> I'm newbie to encryption software development (and newbie to this
> group either) but ...
>
> I've made a simple program implementing stadard DES as described in
> Cryptography and Network Security by William Stallings, using exactly
> same tables and s-boxes.
>
> Here some output of my program (spaced manually for readability),
using
> the same key input with 3 plaintext inputs each differ by 1 bit. (The
book
> gives some output reference for SDES, but not much on DES).
>
> If anybody outthere has coded the DES algorithm and verified to work
> successfully,
> could you help verifying mine? - Thank you in advance.
>
> ZulH.
>
> Key:
> 0000001 1001011 0100100 1100010 0011100 0011000 0011100 0110010
> -------------------
> PlainText:
> 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
> Output:
> 10101011 11010000 10101110 01100111 11111010 10111101 10101010
10000010
> -------------------
> PlainText:
> 10000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
> Output:
> 11111111 11110101 11101111 11011111 11110101 10111111 01010101
01010110
> -------------------
> PlainText:
> 01000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
> Output:
> 01000011 11011111 00111100 01100111 11111010 11111101 10101010
10111111
> -------------------
>
>
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: "Claes & Gunn Irene" <[EMAIL PROTECTED]>
Subject: SV: prime numbers and the multplicative inverse
Date: Tue, 18 May 1999 18:49:40 +0200
Hi.... this is how and why primes and fields are connected in your case.
{Zm, addition modulo m, multiplication modulo m}
is a field if and only if m is a prime.
and one of the useful properties of a field is .... you can divide all
numbers in a field by all non-zero elements.
/Claes
=========================================================0
<[EMAIL PROTECTED]> wrote in message
news:7hrgi1$1or$[EMAIL PROTECTED]...
> I haven't been able to find an answer to this question. Why does IDEA
> use a prime field for it's multiplication?
>
> Does the field need to be prime to have a multiplicative inverse?
>
> Tom
> --
> PGP public keys. SPARE key is for daily work, WORK key is for
> published work. The spare is at
> 'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
> 'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
>
>
> --== Sent via Deja.com http://www.deja.com/ ==--
> ---Share what you know. Learn what you don't.---
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Mandlebrot transform
Date: Tue, 18 May 1999 16:43:44 GMT
[EMAIL PROTECTED] wrote, in part:
>This 'c' value is the output (usually the color) right?
No, the color is the number of times it takes before |c| becomes
bigger than 2. If it never happens, then the starting point is in the
Mandelbrot set, and is colored black.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (Robert G. Durnal)
Subject: Re: Can Somebody Verify My DES execution?
Date: 18 May 1999 16:41:38 GMT
In <[EMAIL PROTECTED]>, Goi Bok Min <[EMAIL PROTECTED]>
wrote:
: hi,
: i think the easiest way to check out whether the DES program can work
: properly or not,
: is decrypt the ciphertext. if after decryption with the same secret key, the
: output we gain is the same as the plaintext, then we can conclude that program
: is correct.
Not necessarily so. Conclusion is that program is *invertable*. The
best way to check for *correctness* is to use the published vectors.
=========
My home page URL=http://members.tripod.com/~afn21533/ Robert G. Durnal
Hosting HIDE4PGP, HIDESEEK v5.0, PGE, TinyIdea (link) [EMAIL PROTECTED]
and BLOWFISH in both Windows and mini-DOS versions. [EMAIL PROTECTED]
EAR may apply, so look for instructions.
------------------------------
** 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
******************************
