Cryptography-Digest Digest #997, Volume #11 Sat, 10 Jun 00 15:13:01 EDT
Contents:
Encryption implimentation in windows - downsides? (ie: temp files, virt memory, etc)
([EMAIL PROTECTED])
Re: Arithmetic Coding (Jack)
Re: Large S-Boxes (Terry Ritter)
Re: How does DES work? ("Paul Pires")
Keys larger than the plaintext (David Hopwood)
Re: Large S-Boxes ("Scott Fluhrer")
Re: Cryptanalytic gap [was: Re: Some dumb questions] ("Paul Pires")
Re: Large S-Boxes (Tim Tyler)
Re: Cryptographic voting (Greg)
Re: Comments on "Encase" forum about EE ([EMAIL PROTECTED])
Re: Double Encryption Illegal? (Greg)
Re: Cryptographic voting (zapzing)
Re: Cryptanalytic gap [was: Re: Some dumb questions] (John Savard)
Re: new public key? (Macckone)
Re: Large S-Boxes (zapzing)
Re: Large S-Boxes (zapzing)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Encryption implimentation in windows - downsides? (ie: temp files, virt
memory, etc)
Date: Sat, 10 Jun 2000 16:56:59 GMT
Hi,
I have been reading a lot about the things to watch for when
implementing an encryption system, and the following thoughts struck me:
* When I decrypt a file, read it, then encrypt it again, is it not the
case that some part (if not all) of the decrypted file will be left in
widows virtual memory or some kind of temp files?
* I want to have a database of encrypted documents, and want them
stored (and used) as securly as possible - should I (a) encrypt the
documents individually and have also an encrypted TOC file so I
minimise the danger of 'left overs' when encrypting / decrypting, or
should I encrypt the entire collection of documents in one block and
crypt/decrypt them when I start and then terminate my program
* Finally, is there any methology known (for windows based os) for
determining what has gone into virtual memory so I can wipe over those
blocks after re-encryption ?
thanks!
- Jay.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Jack)
Subject: Re: Arithmetic Coding
Date: 10 Jun 2000 17:19:36 GMT
[EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>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.
Writting to little Tommy is a waste of time. I have tried and
his mind seems so full of crap that obvious facts seem to escape
him, Tim he is not capable of grasping the obvious facts of what
this kind of comprssion is all about. It is liking trying to teach
a pig. He can't learn and it only wastes your time and the pigs.
The only way he could even start to understand the concept would be
if a phony crypto god talked straight about the concept of compression
with encryption and getting and honest discussion out of them is
pretty much useless since it does not further there goals. Keeping
people like tom ignorant is much more inline with there thinking.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Large S-Boxes
Date: Sat, 10 Jun 2000 17:25:11 GMT
On Fri, 9 Jun 2000 22:31:06 -0700, in
<8hsknh$bov$[EMAIL PROTECTED]>, in sci.crypt "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...
I generally agree. On the other hand . . .
It may be interesting to think that the reason performance drops when
using large tables is that table elements are unlikely to be re-used,
and so will not be in cache. Yet it is often re-use itself which
allows values to be determined by cryptanalysis, resulting in a broken
cipher. Thus, the lack of such re-use might be a form of strength.
In a sense, computer caching is a hostile environment for
cryptography, in that it encourages constructions which re-use
internal data and discourages constructions which benefit less from
cache.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: How does DES work?
Date: Sat, 10 Jun 2000 10:27:07 -0700
It's really easy to understand how it works. Why it works is tougher. It's
actually a very simple collection of very simple parts. I say this because I
just went through the exercise of building DES in a Spreadsheet! Pretty
perverse activity but it is neat to see the avalanche occur cipherwide when
you change a bit in the plaintext or key.
Grab Bruce Schneiers book and build it. An afternoons work.
Paul
Michael Brown <[EMAIL PROTECTED]> wrote in message
news:01bfd2bc$e067b200$0100a8c0@downstairs...
> 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.
>
> Regards,
> Michael Brown
> --
> Hi, i'm the signuture virus,
> help me spread by copying me into Signiture File
------------------------------
Date: Sat, 10 Jun 2000 06:29:16 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Keys larger than the plaintext
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
> This brings to mind a question I have had for some time now; is there
> any point in using a key larger than the data to be encrypted?
There can be in some cases. Consider public-key encryption, for example:
in that case there is a minimum key size needed to make sure that the
problem on which the cryptosystem is based is sufficiently hard. Another
example is passphrase-based encryption; when encrypting a very small
plaintext, the passphrase may have to be longer than the plaintext in
order to be sure that it has enough entropy.
Also, if a system is used to encrypt variable-length messages, it may be
convenient to use a fixed length key, even if a particular message turns
out to be shorter than that key.
> If there is danger in brute-force-searching the key, why not brute-force
> search the plain-text instead? :)
"Brute-forcing" the plaintext doesn't give an indication of whether any
particular guess is correct. Brute-forcing the key might give such an
indication (even if there are fewer possible plaintexts than keys),
depending on the algorithm. It would in any system that includes an
integrity check, for instance.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOUHR5TkCAxeYt5gVAQHe9gf+JmpwY77A7LvqsPVHMKjqkg3RIECDxYFA
tY8mo4qwDwtRfBzInlI+LEm+nHFAHPDeWXUCiqe3i2ccND3ZjDXByVAe/KTardDU
HEGKQVG6GBwsQeCorORn6gZNKG4gQumwAc6MjsEtYGZARHG3EvLm5mn+EYI0CAa0
QzecJt1OT6vnQK+bR4ceE9p7dXy5Xcdy9Kj1m8iW90cnsUmZHXtiupXZZY+eNZcA
nToTEjSdNeQtrWOmMQ78dsuqFu8UnNooaKF2St0pjONwo/uLtUtOP3JjSEZl5hDR
ajtbOGS17OKxN9EUvtKUKY5fOCgZT6BI0N2a78wPTcuKk95FXXNDCw==
=TWPf
=====END PGP SIGNATURE=====
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Large S-Boxes
Date: Sat, 10 Jun 2000 10:16:12 -0700
Simon Johnson <[EMAIL PROTECTED]> wrote in message
news:8hstkt$dik$[EMAIL PROTECTED]...
> 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...
>
> 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?
I think you don't quite understand what L1 cache is. In modern CPUs (it was
different in the past, and it may very well be different in the future), you
have CPUs that can do a single operation in 2-5 nsec, and you have main
memory (the memory that is cheap enough to have multiple megabytes lying
around) that might be able to do a single access in 50nsec. So that the CPU
isn't spending all its time waiting for the memory, CPU designers insert a
'cache' between the two. This cache is designed so that the CPU can access
it in one 2-5nsec cycle (so the CPU doesn't slow down accessing it), and
usually the CPU can access multiple locations in the cache at once. This
cache is usually situated on the CPU chip, and is typically 4k-32kbytes
large. This cache (actually, any cache, this is the definition of "cache")
works by storing the contents of recently accessed portions of the main
memory, in hopes that the program will access them again. So, if you access
a location once, the CPU stalls for the 50 nsec waiting for that location
again. But, if you access the location again, the CPU can read that
location immediately. However, if the cache was full (every location [1]
was already holding a memory location), the L1 cache picks something already
in the cache and throws it out.
And, because the L1 cache isn't big enough, computer designers insert a
second 'L2' cache between the L1 cache and the main memory. This cache is
larger (128k-1Megabyte), and slower (10-20nsec, IIRC).
Now, suppose you have a 128k sbox, and a 32k L1 cache [2]. That means that
at most 1/4 of the sbox is currently in the L1 cache, even if your
encryption routine makes no other data accesses, and has been running long
enough to read the sbox into the cache. Sbox accesses are essentially
random, and so any sbox reference that your program makes has at least a 3/4
probability of missing the L1 cache, causing (at least) several cycles of
stall while the sbox contents are read from the L2 cache.
And so, yes, 2 8x8 sbox accesses (two distinct 8x8 sboxes easily fits in the
L1 cache) are usually considerably faster than a single 16x16 sbox access.
And, as for whether the OS is using the cache -- I think you are confusing
that with 'disk cache', which is the same caching concept applied to disk
accesses. The L1 cache is a feature of the CPU, and every program running
on the computer, including the OS, does use it. Practically speaking, only
the program currently running on the CPU has its data in the cache.
>
> 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.
A better approach might be to do an initial design (using either random
sboxes, or no sboxes), and see if you can break it. If you can't, simplify
the design. Breaking ciphers teaches you much more than just designing
them.
[1] Actually, L1 caches usually can't hold any memory location in any cache
element -- there are usually constraints. That can be ignored for this
overview
[2] L1 caches are often split up between 'instruction' and 'data', so a 32k
L1 cache can usually hold only 16k worth of sbox data. I will ignore this.
--
poncho
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Cryptanalytic gap [was: Re: Some dumb questions]
Date: Sat, 10 Jun 2000 10:49:48 -0700
> <Snip>
> This leaves a gap in the frequency of key use. Is there a kind of
> cryptographic system in which re-using a key is acceptable up to some
small
> limit (1 < limit <= polynomial(leylength))?
>
leylength = keylength ?
Sticking my neck out here..
How a bout a cipher running in CBC mode that uses an I.V. or salt between
the key generation and block encryption?
Paul
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Large S-Boxes
Reply-To: [EMAIL PROTECTED]
Date: Sat, 10 Jun 2000 17:57:32 GMT
Simon Johnson <[EMAIL PROTECTED]> wrote:
: Its ironic really, the subtly of cipher design is not being able to
: construct the cipher, its being able to analyse the cipher you have
: created. I know for a fact that no-one here is fully capable of that,
: otherwise you wouldn't be here, you'd be off in the NSA with all the
: other hamsters.
Life inside might not appeal to everyone - some folks might want to retain
full control over their own tongues.
Still - perhaps you're talking about kidnapping ;-) ;-)
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ This tagline no verb.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Cryptographic voting
Date: Sat, 10 Jun 2000 18:14:25 GMT
> > > The worst problem with this style of government is that
> > > it tends to be a popular democracy. All such systems
> > > become oppressive due to "the tyranny of the majority".
> >
> > That's why the constitution to keep the king in check.
>
> Pieces of paper do not keep rulers in check. Competing
> powers keeps rulers in check. Thus the "balance of power"
> in the US gov't tripod.
It would seem to me that the senate has enough power to keep
the king in check. They have a maximum of one year term. They
certainly don't want to be like the peon after their term if they
allow a dispot king to remain in power.
And the constitution with its "right to keep and bear arms" is
the check and balance for both the senate and the king.
> > The purpose of the "king" factor was to eliminate the
> > blame game.
> Clinton isn't the problem, he's a symptom. The problem is...
Thank you for proving my point...
--
Tyranny is kept at bay by guns and will. Our government
knows we have the guns, but they don't know if we have
the will. Nor do we.
The only lawful gun law on the books- the second amendment.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
alt.security.pgp,comp.security.firewalls,alt.privacy.anon-server,alt.privacy
Subject: Re: Comments on "Encase" forum about EE
Date: Sat, 10 Jun 2000 11:17:57 -0700
I can't possibly see how the EE bashers have a leg to stand on after having
read the posts at any of the two links, below.
But here is an opportunity for EE support to do what their name implies -
support their users in this forum.
EE Support - could you please reply to the three questions, below? Come on,
[EMAIL PROTECTED] has a function beyond mudfighting
trolls, right? Enlighten us with your technical savvy.
Awaiting a response
<[EMAIL PROTECTED]> wrote
>
> Look at what I found on the Guidance Software ("Encase") forum when I
> searched for "Evidence Eliminator". Both threads are interesting.
>
> http://www.guidancesoftware.com/ubb/Forum1/HTML/000183.html (Topic: BC
Wipe
> and/or Evidence Eliminator 4.5?)
> http://www.guidancesoftware.com/ubb/Forum1/HTML/000176.html (Topic:
Evidence
> Eliminator Software)
> EE support -
> I have a question about the following post:
>
> === (Post on Topic: Evidence Eliminator Software) ===
>
> FYI: I've done some experimenting with Evidence Eliminator. Sometimes
you're
> able to view previous internet history by viewing certain .DAT files.
> ------------------
> NY State Police
> Computer Crime Unit
>
> === (End post) ===
>
> 1. EE, are you aware of this?
> 2. What is the security risk of .DAT files from Norton Utilities Image?
They
> facilitate (extremely well) the complete unformatting of a HD, so does
that
> mean that they contain info re. internet history (or worse)? Should I not
> run Image? Please don't say it's so!.
> 3. On an unrelated note, try this: after doing your best wipe, put your
> cursor in the Windows "Address toolbar" of the taskbar (you may have to
> enable it first). Press Ctrl-Up and see what you get. In some cases, I get
> ancient history even after wiping all there can be wiped (short of my
entire
> HD :)
>
> Please comment
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: comp.databases.oracle
Subject: Re: Double Encryption Illegal?
Date: Sat, 10 Jun 2000 18:17:21 GMT
> Since when is it illegal to double encrypt in the US? I don't believe
> this is true.
Obviously, the author does...
--
Tyranny is kept at bay by guns and will. Our government
knows we have the guns, but they don't know if we have
the will. Nor do we.
The only lawful gun law on the books- the second amendment.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Cryptographic voting
Date: Sat, 10 Jun 2000 18:24:06 GMT
For goodness sakes, people could use laundry
tickets for money if they wanted to. Actually
that gives me an interesting idea about
cryptographic money .... I'll have to work on
it after I get the *cryptographic* *voting*
thing figured out (hint).
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Cryptanalytic gap [was: Re: Some dumb questions]
Date: Sat, 10 Jun 2000 18:24:17 GMT
On Sat, 10 Jun 2000 10:47:44 -0400, "Trevor L. Jackson, III"
<[EMAIL PROTECTED]> wrote, in part:
>Jim Gillogly wrote:
>> The "dead system" is the N-time pad, not the 1-time pad.
>This is a succinct summary of the issues of the original thread, but it
>sparked my awareness of a gap in the literature (more probably a gap in my
>knowledge or understanding of the literature) regarding key usage. On one
>hand we have the OTP model and on the other we have PK and SK systems. OTPs
>rely upon the quality and quantity of the key and its unique usage for
>strength. PK and SK systems rely upon the transforms applied to the key and
>text for their strength, allowing exponentially large key reuse (like reuse <
>2^(keylength/2))
>This leaves a gap in the frequency of key use. Is there a kind of
>cryptographic system in which re-using a key is acceptable up to some small
>limit (1 < limit <= polynomial(leylength))?
There might be, but let's try to imagine what such a system might look
like.
An OTP applies its key to the plaintext in a very simple way. An SK
system, like DES, applies its key to the plaintext in a very
complicated way.
So, a system in which the key can be used only a limited number of
times would be one where the key is applied to the plaintext in a way
that involves only a moderate complexity. Such as many
pencil-and-paper cryptographic systems. Or take DES with eight rounds,
known to be vulnerable to differential cryptanalysis with a certain
number of known plaintext blocks (but which could be brute-forced with
a single block, so it isn't really an example without some additional
cipher step).
The reason there is a 'gap', though, stems from the basic theory of
why cryptanalysis is possible, as developed by Claude Shannon. The OTP
is provably secure, because the ciphertext doesn't contain enough
information to specify the plaintext. Anything that isn't an OTP can,
in theory, be solved: the only thing that prevents solution is the
"work factor".
Thus, using the same key even two times means any cipher can be
solved, in theory. The only thing that prevents that solution is the
complexity of unravelling the cipher used. Thus, unless that
complexity is very high, enough to maintain security even if the same
key is used to encipher a large amount of text, there is no basis on
which to be very confident that security will exist even for a text
only twice as long as the key.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
------------------------------
From: [EMAIL PROTECTED] (Macckone)
Subject: Re: new public key?
Date: 10 Jun 2000 18:47:59 GMT
If you have a private lookup table isn't
it then a code book cipher rather
than a public key cipher?
Mack
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Large S-Boxes
Date: Sat, 10 Jun 2000 18:43:20 GMT
In article <[EMAIL PROTECTED]>,
tomstd <[EMAIL PROTECTED]> wrote:
> In article <8hs2m0$rgs$[EMAIL PROTECTED]>, zapzing <zapzing@my-
> deja.com> wrote:
> >In article <8hrtja$nte$[EMAIL PROTECTED]>,
> > Simon Johnson <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >> 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.)
> >>
> >
> >Well the DES s-boxes are quite small. They are
> >designed to be optimal against differential
> >cryptograpohy, but they are in the lowest
> >9-16% of the similar sized sboxes in terms
> >of resitance to linear cryptography. So much,
> >I say,for trying to design them optimally.
> >
> >Big random sboxes are resistant to both
> >differential and linear crypto :)
> >And it's easy for mere mortals to "design" them.
>
> While they are easy to design, they are hardly secure. Just
> wait till I publish my test results on 8x8 sboxes (which will
> also be in my paper as well).
I agree that 8X8 sboxes ared too small to design
randomly. One should never use any sboxes smaller
than 16X16 if they are designed randomly. I await
your tests with 16X16 random sboxes.
I was unable to find a reference for your
definition of LPmax and DPmax. What are they.
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Large S-Boxes
Date: Sat, 10 Jun 2000 18:49:44 GMT
> >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....
Well it depends on whether: 1-you might need less rounds
if you use a larger sbox. 2-you might have an optimizing
compiler that can do something else with the time while
it waits, 3-maybe this is a hardware implementation that
works in a totally different way.
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
