Cryptography-Digest Digest #995, Volume #11 Sat, 10 Jun 00 09:13:00 EDT
Contents:
Re: Arithmetic Coding (Tim Tyler)
Re: Multiple encryptions (Guy Macon)
Re: Random IV Generation (Tim Tyler)
Re: Double Encryption Illegal? (Simon Johnson)
Re: Observer 4/6/2000: "Your privacy ends here" (Mok-Kong Shen)
Re: Multiple encryptions (Guy Macon)
Re: PK analogue for passwords (Daniel James)
Re: Random sboxes... real info (Simon Johnson)
Re: Random sboxes... real info (Simon Johnson)
Re: Some dumb questions (Guy Macon)
Re: randomness tests (Tim Tyler)
Re: Random sboxes... real info (tomstd)
Re: Some dumb questions (Guy Macon)
Re: Arithmetic Coding (tomstd)
Re: Arithmetic Coding (tomstd)
Re: My lastest paper on Block Ciphers (tomstd)
Re: Some dumb questions (Guy Macon)
Re: Large S-Boxes (tomstd)
Re: How does DES work? (tomstd)
Re: randomness tests (tomstd)
Re: How does DES work? (Quisquater)
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Arithmetic Coding
Reply-To: [EMAIL PROTECTED]
Date: Sat, 10 Jun 2000 11:02:04 GMT
tomstd <[EMAIL PROTECTED]> wrote:
: Please enlighten me as to what "information" programs like pkzip
: add to the compressed data stream that aid's in cryptanalysis?
For one thing, not all decrypts are valid compressed files.
This allows an analyst to reject possible keys with no knowledge of the
plaintext, except that it's been compressed.
: From what I can see, yes in LZ77 out there are "invalid" output
: words, but similar to the case of ASCII, so what is your point?
: LZ77 compresses much better then Huffman coding for the most
: part so except for the initial blocks of text, most of the lz77
: stream has more information per bit then Huffman could possibly
: have. This is simple to prove too. Let's assume you are using
: a lzss coder with a 15 bit index, and 9 bit length (24 bit
: words). We can theoretically pack 512 bytes per 3 bytes or a
: ratio of 170:1. Now look at huffman. Each input byte can be
: packed into as little as a single bit... this is only 8:1.
Huffman symbols need not represent bytes. They can represent anything you
like. The same goes for arithmetic coding.
You could even produce a 1-1 adaptive Huffman compressor that works with
dictionaries of strings - provided the dictionary is constrained in
a manner similar to the way I describe at:
http://mandala.co.uk/securecompress/dictionary/
Besides - the fact that the first 1-1 compressor happened to be a
Huffman-based coding scheme does not imply that no other types of 1-1
compressor are possible.
: So at it's best huffman is 21 times less efficient then lzss at
: it's best.
Compression ratios depend on your data. There will be streams for which
David's own implementation of Huffman coding is better than lzss - evey
"efficient" compressor is optimal for *some* type of data.
I could write a compressor that "at its best" compresses N Mb of all-zero
data into a few bits. This would be thousands of times "better" than
Huffman by your metric.
Comparing maximum compression ratios on different types of data is an
almost totally useless way of comparing compressors.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ VIPAR GAMMA GUPPY.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Multiple encryptions
Date: 10 Jun 2000 07:25:17 EDT
jkauffman wrote:
>
>But surely if the combination of D & E is weaker than alone
>then D represents the first stage of a cryptoanalytic attack
>on E. And if D was developed independently of E then this
>attack would be by pure chance.
"D was developed independently of E" is not the same as
"D is independent of E". Maybe the two developers had
the same bright idea. Maybe there is a suptle interaction
that you haven't forseen.
>Another way of looking at it is that if E is a secure cipher
>it must be secure no matter what the input. This includes
>normal ASCII text, bitmaps, letters to Grandmother and the
>output of D. If its security can be compromised by chosing
>certain inputs then it is not a good cipher.
Then any cipher that uses XOR with the plaintext as a final step
is not a secure cipher, because if I choose to use as my plaintext
my original plaintext encrypted with the same algorithm and key,
then the output is my original plaintext. I am not ready to say
that OTP, ciphersaber, and RC4 are insecure, even if your logic
leads to that conclusion.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random IV Generation
Reply-To: [EMAIL PROTECTED]
Date: Sat, 10 Jun 2000 11:12:49 GMT
Mark Wooding <[EMAIL PROTECTED]> wrote:
: Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
:> I agree with your first sentence, but I think that it helps, if one
:> can keep the IV unknown to the opponent.
: For CBC and CFB it can only protect the first plaintext block. [...]
<fx: nitpicks>
It /could/ protect more than the first plaintext block - if the first
plaintext block is ever shared between different messages.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ This tagline no verb.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Double Encryption Illegal?
Date: Sat, 10 Jun 2000 11:16:13 GMT
In article <PWg05.167$[EMAIL PROTECTED]>,
"Adam Durana" <[EMAIL PROTECTED]> wrote:
>
> This is just a guess, since I have never used this software. I would
guess
> that this software uses a small key size so it can be exported, and
double
> encrypting with two _different_ keys would increase the key space to
> something beyond what is allowed to be exported.
>
> - Adam
Wasn't the encryption law relaxed in the US? - So it doesn't matter now
:)
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Observer 4/6/2000: "Your privacy ends here"
Date: Sat, 10 Jun 2000 13:41:10 +0200
Cinder wrote:
> What about a program which encrypts 2 files at once using different keys?
> If only one file is specified, it encrypts a random string with a random
> key instead. Presumably you could then say that you only had one file
> encrypted, so you don't know the second key.
I don't yet understand what you wrote. Are you addressing deniable
encryptions? I remember the topic was discussed some time back
in sci.crypt. Could someone give good pointers to that theme in
literatures? Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Multiple encryptions
Date: 10 Jun 2000 07:38:54 EDT
James Felling wrote:
>So long as D and E do not work by similar mechanisms there will be
>little risk of this occurring though -- effectively 0 if you choose
>D and E with care.
I fully agree with the above. I, of course, am a clueless newbie
who lacks the ability to choose the two methods with care, and the
top crypto experts may make a mistake when choosing the two methods
with care. The probability of them doing so is almost certainly
higher than the probability of the first method being cracked.
That being said, I think that I can prove that the two methods are
unrelated and therefor not weaker than either one alone if one of
the methods it OTP. I have a gut feeling that making the two methods
symmetric key and asymmetric key will make them unrelated, but I can't
prove it.
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: PK analogue for passwords
Date: Sat, 10 Jun 2000 12:40:00 +0100
Reply-To: [EMAIL PROTECTED]
In article <8hr7kl$6md$[EMAIL PROTECTED]>, sarnold wrote:
> [sigh. sorry for formatting. I am too lazy to fix it today.]
You're forgiven. It's nice that you care enough to apologize.
> Well, the twonz program does indeed base64. The program is GPL, so
> what the heck, lets post it! ;)
[snip]
Hmm. Well, I don't speak perl (perhaps it /is/ time I bought that Perl book
I've been meaning to buy) but that's clearly NOT RFC1938, and DOES use
Base64. Sorry for the red herring.
Cheers,
Daniel.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Random sboxes... real info
Date: Sat, 10 Jun 2000 11:25:13 GMT
In article <[EMAIL PROTECTED]>,
tomstd <[EMAIL PROTECTED]> wrote:
> at
>
> http://tomstdenis.com/sboxes.txt
>
> Is some testing on random 8x8 sboxes... (about 200 or so). I
> will leave the test go overnight and see what it comes up with.
>
> This should help settle the futile argument.
>
> Tom
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion
Network *
> The fastest and easiest way to search and participate in Usenet -
Free!
>
>
Could you describe the tables please?
Here is what i think it means:
LPmax - Maximum Probability of Linearness existing
MPmax - Maximum Probability of Differenitals existing
What the numbers mean i have no idea.
Could you describe them fully please, otherwise i can't understand them
and therefore your time is wasted :)
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Random sboxes... real info
Date: Sat, 10 Jun 2000 11:27:54 GMT
In article <[EMAIL PROTECTED]>,
tomstd <[EMAIL PROTECTED]> wrote:
> at
>
> http://tomstdenis.com/sboxes.txt
>
> Is some testing on random 8x8 sboxes... (about 200 or so). I
> will leave the test go overnight and see what it comes up with.
>
> This should help settle the futile argument.
>
> Tom
Sorry, i get it now, methinks.
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion
Network *
> The fastest and easiest way to search and participate in Usenet -
Free!
>
>
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Some dumb questions
Date: 10 Jun 2000 07:43:53 EDT
Jim Gillogly wrote:
>
>
>Mok-Kong Shen wrote:
>> from other viewpoints, e.g. operating expenses/difficulties. (To
>> avoid flames from other readers due to misunderstanding, let me
>> repeat that I don't 'recommend' or 'propose' using n-OTP with
>> frequency flattening as desciribed above and that I am in fact not
>> even sympathetic to OTP as such.)
>
>Why, then, did you restart this discussion? Trying to help somebody
>out who was trying to breathe new life into the rotting corpse of
>a dead system seemed like a worthy goal, but wanking around with
>something <nobody> believes in seems like a waste of time. I'm out
>of this one.
I think that you are being unfair. Are you saying that, when I read
in this newsgroup that doing X is insecure, I am wrong to want to
understand why?
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: randomness tests
Reply-To: [EMAIL PROTECTED]
Date: Sat, 10 Jun 2000 11:25:45 GMT
[EMAIL PROTECTED] wrote:
: hello all,
: in order to check randomness of my random number(bit) generator
: i use
: 1. ent package
: 2. diehard package [...]
: can anyone suggest me any tests?
pLab have a C++ test-suite for download: (at the bottom of)
http://random.mat.sbg.ac.at/tests/
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Be good, do good.
------------------------------
Subject: Re: Random sboxes... real info
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 10 Jun 2000 05:04:35 -0700
In article <8ht8ii$k62$[EMAIL PROTECTED]>, Simon Johnson
<[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> tomstd <[EMAIL PROTECTED]> wrote:
>> at
>>
>> http://tomstdenis.com/sboxes.txt
>>
>> Is some testing on random 8x8 sboxes... (about 200 or so). I
>> will leave the test go overnight and see what it comes up
with.
>>
>> This should help settle the futile argument.
>>
>> Tom
>>
>> * Sent from RemarQ http://www.remarq.com The Internet's
Discussion
>Network *
>> The fastest and easiest way to search and participate in
Usenet -
>Free!
>>
>>
>
>Could you describe the tables please?
>
>Here is what i think it means:
>LPmax - Maximum Probability of Linearness existing
>MPmax - Maximum Probability of Differenitals existing
>
>What the numbers mean i have no idea.
>
>Could you describe them fully please, otherwise i can't
understand them
>and therefore your time is wasted :)
That would be bad... GHmm at
http://tomstdenis.com/sbox8.txt
is the overnight results from my test. The LPmax means the
strongest linear bias is 'x'. In this test I group them in 2
units so if you look at "LPmax = 28: %0.187" that means %0.187
of all tested 8x8 sboxes have a linear bias of either
p = 1/2 +/- 28/256
or
p = 1/2 +/- 30/256
This is usefull obviously in linear cryptanalysis. The DPmax
means the strong in-out xor pair has prob of x/256 of occuring.
If you look at the table it says "DPmx = 12: %0.002" that means %
0.002 of the tested random sboxes has a maximum probability for
any pair of 12/256.
Good 8x8 sboxes should have a LPmax of no more then 32
(preferably lower) and a DPmax of no more then 8.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Some dumb questions
Date: 10 Jun 2000 08:06:30 EDT
Mok-Kong Shen wrote:
>
>Nonetheless, I like to point out it is a subjective matter whether
>OTP is a 'dead system'. At least till recently there have been several
>discussion threads on that in the group. (For instance, in one thread
>Guy Mason proposed to pad the plain text with random bits at the
>beginning and the end.) So apparently there are people who have
>'deviant' opinions concerning whether OPT is dead, which I think
>is not only an inevitable fact in sciences but also an indication of the
>healthy state of sciences.
(That's "Guy Macon"...)
Exactly so.
Besides, this isn't sci.crypt.not-dead, and some of us are here to learn.
I decided one day to learn more about crypto, and chose to become an
expert in a series of systems as my method of learning. So far I have
achieved what I believe is expert status in understanding ROT-X, One-to-one
character substitution with 256 byte table, Two-to-two character-pair
substitution with 65.536 word table, and OTP. I am now digging into
ciphersaber. If I choose this path to learning and certain kind folks
choose to help me understand, who can say that this is wrong, even if
ROT-X is easy to break? Having someone explain how to attack each
of the above has been an eye opener to me, and is a sound foundation
for gaining further knowledge. *I* want to know how to start cracking
the two XORed plaintexts that reusing an OTP key gives an attacker.
It's on-topic and of interest to me. Who cares if these systems are
dead? I use PGP for serious protection, but it's a poor choice for
learning at my present skill level.
------------------------------
Subject: Re: Arithmetic Coding
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 10 Jun 2000 05:06:17 -0700
No matter how you treat the EOF, I can always just
decrypt/decompress and test for ASCII. You can't stop a brute
force search with compression.
Tom
In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]>
wrote:
>tomstd <[EMAIL PROTECTED]> wrote:
>: In article <[EMAIL PROTECTED]>, Tim Tyler
<[EMAIL PROTECTED]> wrote:
>:>tomstd <[EMAIL PROTECTED]> wrote:
>:>: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>
>:>:>[...] matt's site that has the best info on useful with
>:>:> source code adaptive unadulterated arithmetic coding. [...]
>:>
>:>: To the best of my knowledge no arithmetic coder adds
anything
>:>: that doesn't need to be there. So your logic is flawed my
friend.
>:>
>:>What if the arithmetic stream does not terminate on a byte
boundary?
>:>
>:> Think about it - an arithmetic coding stream is pretty good -
>:> but it is only rarely as perfect as you will find at:
>:>
>:> http://www3.sympatico.ca/mtimmerm/biacode/biacode.html
>
>: While your site looks nice, it's pure crap. [...]
>
>It's not my site. It belongs to Matt Timmermans
(http://www.timmermans.org/)
>
>: Nowhere in any OS does it state that your file must contain
at least or a
>: boundary of 8 bits of *information*.
>
>What is the purpose of this statement? Most modern OSs enforce
an 8-bit
>*data* alignment. Compression produces a stream of *data*.
It's
>information-content from the perspective of some observer is
moot.
>
>: Note: It is possible to write 7 bits of *information* to a
file
>: using ms-dos for example, you just end of wasting the last
bit.
>
>So - if I have this straight - you're advocating padding out
the file with
>an "impossible" token that takes the last arithmetic coding
symbol beyond
>the EOF?
>
>This is likely to allow analysts to reject decrypts as being
invalid
>compressed files - and increases the average length of the file
compared
>to what's possible with Matt's end-treatment. There seem to be
no
>compensating advantages.
>
>: All real arithmetic coders do is calculate the high/low and
when
>: they match in the upper decimal (bit) they shift the bit out.
>: This isn't secret hidden information, it's part of the bloody
>: number!!!
>
>Your objection here appears to be addressing a point nobody
ever raised.
>
>The only "problem" with added information in arithmetic coding
schemes
>occurs at the end of the file.
>--
>__________ Lotus Artificial Life http://alife.co.uk/
[EMAIL PROTECTED]
> |im |yler The Mandala Centre http://mandala.co.uk/ Breast
is best.
>
>
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: Arithmetic Coding
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 10 Jun 2000 05:09:05 -0700
In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]>
wrote:
>tomstd <[EMAIL PROTECTED]> wrote:
>
>: Please enlighten me as to what "information" programs like
pkzip
>: add to the compressed data stream that aid's in cryptanalysis?
>
>For one thing, not all decrypts are valid compressed files.
>This allows an analyst to reject possible keys with no
knowledge of the
>plaintext, except that it's been compressed.
>
>: From what I can see, yes in LZ77 out there are "invalid"
output
>: words, but similar to the case of ASCII, so what is your
point?
>: LZ77 compresses much better then Huffman coding for the most
>: part so except for the initial blocks of text, most of the
lz77
>: stream has more information per bit then Huffman could
possibly
>: have. This is simple to prove too. Let's assume you are
using
>: a lzss coder with a 15 bit index, and 9 bit length (24 bit
>: words). We can theoretically pack 512 bytes per 3 bytes or a
>: ratio of 170:1. Now look at huffman. Each input byte can be
>: packed into as little as a single bit... this is only 8:1.
>
>Huffman symbols need not represent bytes. They can represent
anything you
>like. The same goes for arithmetic coding.
>
>You could even produce a 1-1 adaptive Huffman compressor that
works with
>dictionaries of strings - provided the dictionary is
constrained in
>a manner similar to the way I describe at:
> http://mandala.co.uk/securecompress/dictionary/
>
>Besides - the fact that the first 1-1 compressor happened to be
a
>Huffman-based coding scheme does not imply that no other types
of 1-1
>compressor are possible.
>
>: So at it's best huffman is 21 times less efficient then lzss
at
>: it's best.
>
>Compression ratios depend on your data. There will be streams
for which
>David's own implementation of Huffman coding is better than
lzss - evey
>"efficient" compressor is optimal for *some* type of data.
>
>I could write a compressor that "at its best" compresses N Mb
of all-zero
>data into a few bits. This would be thousands of
times "better" than
>Huffman by your metric.
>
>Comparing maximum compression ratios on different types of data
is an
>almost totally useless way of comparing compressors.
My point was that on virtually all types of data string
compressors outperform symbol encoders. This is nothing new.
Therefore it's reasonable to assume after compression with say
LZSS there are closer to 64 bits of info per '64-bit block' of
plaintext.
As for a brute force search, if your compressor is reversible
then I can still recognize valid plaintext. This doesn't make
brute force search any faster no matter what the input is.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: My lastest paper on Block Ciphers
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 10 Jun 2000 05:10:15 -0700
In article <[EMAIL PROTECTED]>, Dido Sevilla
<[EMAIL PROTECTED]> wrote:
>tomstd wrote:
>> >
>> >Can I suggest that you use a file format that 1) is portable,
>> and 2) less
>> >hostile?
>>
>> At: http://wheel.compose.cs.cmu.edu:8001/cgi-bin/browse/objweb
>>
>> You can translate documents, I don't guarantee it will format
my
>> file properly... if you must there is an unzipped copy of the
>> paper at
>>
>> http://tomstdenis.com/ffunctions.doc
>>
>> it's in word97 (ms-word) format.
>
>Jeez, I mean, how hard is it to get Word97 to save a document
in an open
>format like HTML or PostScript? I don't own a copy of Word97
(which is
>probably M$'s submission to the AES!), and so your file might
as well be
>in some unbreakable cryptosystem. I believe there are commands
that
>allow you to save a Word document to PostScript, which is,
after all,
>the canonical file format used for scientific papers.
Maybe you posted this at the same time..... but...
I now have a PS copy of the draft at
http://tomstdenis.com/ffunctions.ps.gz
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Some dumb questions
Date: 10 Jun 2000 08:12:15 EDT
Jim Gillogly wrote:
>Not at all. The discussion is the one with the above title, i.e. the
>entire thread -- you initiated it apparently to find out ways to improve
>the security of N-time pads, but you've said here that you do not
>recommend or propose either N-time pads or 1-time pads. This leads
>me to wonder what the point was of this exercise -- was it simply to
>increase the volume in sci.crypt?
>
>The "dead system" is the N-time pad, not the 1-time pad.
Substituting characters from a random table in the form "A=Q, B=H, C=N..."
is dead too, but learning WHY it's dead is a great way of starting out
on the path of learning cryptanalysis. If I want to learn more about
cracking N-time pads and someone is willing to teach me, you are wrong
to discourage such on-topic behaviour.
------------------------------
Subject: Re: Large S-Boxes
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 10 Jun 2000 05:13:17 -0700
In article <8hstkt$dik$[EMAIL PROTECTED]>, Simon Johnson
<[EMAIL PROTECTED]> wrote:
>In article <8hsknh$bov$[EMAIL PROTECTED]>,
> "Scott Fluhrer" <[EMAIL PROTECTED]> wrote:
>>
>> Simon Johnson <[EMAIL PROTECTED]> wrote in message
>> news:8hrtja$nte$[EMAIL PROTECTED]...
>> >
>> >
>> > I think i'm flogging a dead-horse here, but i'm after
evidence in 'a
>> > dummies guide to' style to the pro's and con's of randomly
>generated S-
>> > boxes.
>> >
>> > I'm thinking 16x16 for a block-cipher i'm devolping (don't
hold u're
>> > breath, i don't have 1/2 a clue what i'm doing :), i just
having
>fun.)
>>
>> So, you're think about an sbox that will take 128k of
memory? Well,
>that'll
>> work in the sense that (with high probability) there won't be
any
>> troublesome characteristics, however, an sbox that big won't
fit in a
>> conventional L1 cache. Assuming you're running it on any
modern CPU,
>any
>> sbox reference will take several cycles while the CPU waits
for the
>memory
>> (or more likely, the L2 cache) to retrieve it. Since this
will
>happen to
>> almost every sbox reference, you're performance is likely to
be
>dreadful,
>> and as has been pointed out, a secure block cipher is
actually pretty
>easy
>> to design if you are willing to settle for dreadful
performance...
>>
>> --
>> poncho
>
>I never even considered that. I suppose the real question is
two block
>thru an 8x8 faster than one block thru a 16x16? Another
important, and
>linked, question is how long does it take to retreive from the
L1 cache?
>Moreover, won't the operating system be using this cache?
8x8 sboxes take 256 bytes of ram, so they will most certainly
fit on the cache. The look ups should take a cycle each if they
are in the cache, maybe less I dunno. At anyrate a single 16x16
lookup will take you about 3 or more cycles, not to mention
making the sbox....
>These points considered, it looks like the signs point to an
optimized
>s-box. The problem with this approach is i don't even know
where to
>start.
Try
http://tomstdenis.com/sboxgen.c
It has LP and DP tests as well as SAC and BIC. If you can
follow the code. If you have questions ask, I don't mind
explaning it.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: How does DES work?
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 10 Jun 2000 05:15:19 -0700
In article <01bfd2bc$e067b200$0100a8c0@downstairs>, "Michael
Brown" <[EMAIL PROTECTED]> wrote:
>Hi there,
>
>I was reading about DES's insecurities and wondering a bit
about how it
>works. I read somewhere else that it "folds" up the string of
bits or
>something, and was wondering if it is something like this: each
bit
>specifies a command, for example 0=swap each bit with its
neighbour to the
>right, 1=swap each bit with its neighbour to the left, so a 56
bit key
>would have 56 "instructions". Is is instruction based, or
something
>completely different. If it's different, are there any other
encryption
>things that use this method (there seems to be a <lot> of
different ones
>mentioned...) or a similar one (eg:16 instructions)?
>
>Any pointers to DES info also appreciated.
Who on earth told you that? hehehehhohohohoh...
DES is certainly a dead cipher, but you can find some papers Eli
Biham on DES (he is one of the dudes that broke DES). Also
check out FIPS-42 I think... (NIST).
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: randomness tests
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 10 Jun 2000 05:18:09 -0700
In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]>
wrote:
>[EMAIL PROTECTED] wrote:
>
>: hello all,
>
>: in order to check randomness of my random number(bit)
generator
>: i use
>: 1. ent package
>: 2. diehard package [...]
>
>: can anyone suggest me any tests?
>
>pLab have a C++ test-suite for download: (at the bottom of)
> http://random.mat.sbg.ac.at/tests/
Again, total garbage. The original poster never said what he is
using the prng for so how can you be sure that these tests are
good for what he needs?
Would people stop clinging to Diehard/ent/etc as the ONLY way to
test a prng!!!! IF you don't know what it's for, how can you
tell if it's good or not?
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Quisquater <[EMAIL PROTECTED]>
Subject: Re: How does DES work?
Date: Sat, 10 Jun 2000 14:57:53 +0200
tomstd wrote:
> DES is certainly a dead cipher, but you can find some papers Eli
> Biham on DES (he is one of the dudes that broke DES). Also
> check out FIPS-42 I think... (NIST).
>
> Tom
Certainly?
Can you elaborate, please? I don't agree at all (and differential
cryptanalysis found by Eli Biham and Adi Shamir is not breaking
DES at all). The only weak point (today!) is the key length of DES.
Triple DES is a solution (DES-X ?). Do you how many applications
are using DES today (correctly) and are not broken? DES was in the
field from 1975: How many "new" ciphers (IDEA, twofish, ...) will
be in the field for the next 25 years (I know I'm provocative here)?
========
Universit� de Louvain
UCL Crypto Group
see http://www.dice.ucl.ac.be/crypto
t�l. 32.10.47.25.41 (connected to my voicebox and cellular phone)
fax: 32.2.358.55.83 (only for me)
SMS: send an email (only the subject will be transmitted) to
[EMAIL PROTECTED]
------------------------------
** 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
******************************
