Cryptography-Digest Digest #969, Volume #11 Wed, 7 Jun 00 13:13:00 EDT
Contents:
Re: Enigma Variations (Jim Gillogly)
An idea of a simple unsophisticated encryption scheme (Mok-Kong Shen)
Re: Some dumb questions (Mok-Kong Shen)
Re: Cryptographic voting ("Thomas J. Boschloo")
Re: Could RC4 used to generate S-Boxes? (Simon Johnson)
Re: Enigma Variations (Mok-Kong Shen)
Re: Thoughts on an encryption protocol? (John Myre)
Re: Some citations (Mok-Kong Shen)
Re: Question about recommended keysizes (768 bit RSA) (Jerry Coffin)
Re: Observer 4/6/2000: "Your privacy ends here" ("Morgan Holt")
Re: Cryptographic voting (Mok-Kong Shen)
Re: testing non linearity of arithmetic-logic combinations (Terry Ritter)
Re: testing non linearity of arithmetic-logic combinations (tomstd)
Re: Could RC4 used to generate S-Boxes? (tomstd)
Re: Some dumb questions (Jim Reeds)
Re: Request for review of "secure" storage scheme (Anne & Lynn Wheeler)
Re: testing non linearity of arithmetic-logic combinations (Mark Wooding)
Re: Cryptographic voting (zapzing)
Re: testing non linearity of arithmetic-logic combinations (tomstd)
Re: Solution for file encryption / expiration? (Frank M. Siegert)
----------------------------------------------------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Enigma Variations
Date: Wed, 07 Jun 2000 15:13:50 +0000
John Spicer wrote:
> This led me to wonder what was the state of the cryptography used by the
> Allies and what in-roads had the Germans and Japanese made? Did the
> Allies learn from their successes against the Axis cryptos and
> strengthen their own, or did they fall into the same traps?
The Germans read American M-209 traffic, according to POW interviews.
So far as we know (unclassified, anyway) none of the Axis powers read
SIGABA, the top US system. If the British Typex was ever broken, I
don't know about it. At a conference I attended one speaker
said that while the blunders of German operators made the Allied
c/a effort much easier than it otherwise would have been, the Allied
operators were even sloppier. I didn't get a feel for how much actual
traffic was compromised by this.
The Japanese had some notable non-successes, including a failure to
read JFK's Playfair rescue message after PT-109 was rammed out from
under him; and an inability to crack the Navajo Code Talkers' tactical
system, even with the coerced help of at least one native Navajo POW
who wasn't trained in the system.
--
Jim Gillogly
Sterday, 18 Forelithe S.R. 2000, 15:01
12.19.7.4.18, 11 Edznab 1 Zotz, Eighth Lord of Night
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: An idea of a simple unsophisticated encryption scheme
Date: Wed, 07 Jun 2000 17:23:21 +0200
The following sketch of an encryption scheme is not claimed
to be particularly strong, being, I suppose, comparable and
in fact in some sense related to the methods centred on
base conversions (see the recent thread 'A Family of
Algorithms, Base78Ct', initiated by wtshaw), nor entirely
novel, being simply composed of basic and well-known
techniques (I should appreciate obtaining pointers, if the
same is already in the literature). It is a tiny response to
wtshaw's recent advocacy of wide crypto diversity (cf. his
utopic idea of 'a cipher each day').
Let n be the block size in bits and N=2^n. Let a range
[d1, d2] be chosen. Generate with a PRNG (with a secret
key as seed) a set of relatively prime numbers g_i in that
range, such that their product G>N. (For simplicity of
implementation, one could choose g_i to be all primes.)
Choose a random number R in [0, G-N]. Let P be the integer
number that represents the block of plaintext currently to
be processed and Q=P+R. Compute the sequence c_i with
c_i = Q mod g_i
Let c_i be appropriately represented, e.g. in hexs or
decimals and separated from one another with separators,
and let S be the string of their concatenation. (One
could dispense with the separators, but this is an
implemention issue.) Do a random permutaton of the
elements of S. This results in the ciphertext C. The
decryption of C is straightforward with application of
the Chinese remainder theorem.
M. K. Shen
==============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Some dumb questions
Date: Wed, 07 Jun 2000 17:23:15 +0200
Volker Hetzer wrote:
> Mok-Kong Shen wrote:
> > It is my fault for not having clearly/correctly stated what I had in
> > mind when I wrote that 'there is no plaintext knowledge available'.
> > I assume that the opponent knows the language used and even has
> > a good frequency distribution. But I assume (from what I know
> > about practical use of OTP) also that OTP is not used 'purely',
> > i.e. not used alone, and that there is a processing step before doing
> > the xor, in order to prevent the opponent from utilizing digram or
> > n-gram frequencies and locating certain headers in the messages
> > etc. etc.
> Depends on the quality of your key material. In theory it can't increase
> the security of an OTP, only of a reused keypad.
> If you want to hide source patterns and character distributions, why not
> simply use the first 15 Bytes as Key and IV for CBC-DES and encrypt the
> resulting random noise with your re-used keypad? That will *definitely*
> make statistical analysis hard.
As a matter of fact, I am personally even unsympathetic to OTP itself.
As noted previously, it is not the intention of my original post that
started this thread to recommend the use of OTP or n-OTP in practice
but to enquire whether, and if yes why, an accidental misuse of OTP
could by itself be very fatal. For that purpose I made certain
assumptions and considered that they are well satisfied for the querry
at hand.
> > However, I should mention (it's my fault for not
> > having done it at the beginning) that my original post does not have
> > the intention to 'recommend' the multiple use of OTP (not to
> > mention to imply that multiple use could be provably strong) but
> > simply to learn whether and why an erroneous employment such
> > that an OTP is e.g. used twice is 'really' that fatal, if precautions
> > in other respects of the security system are all properly taken.
> When people use the OTP its IMHO because they won't bother with
> additional stuff. Get a good keystream and you can encrypt anything you
> want just perfectly without additional processing. So, if you encounter
> a botched up OTP application, it's (IMHO) likely to be a pure OTP
> botched up instead of a beefed up botched up OTP. But you might disagree.
> If I had to develop an OTP package I'd put effort into ensuring that
> the key is never reused by this app and that the random numbers are good.
> It's much easier to show the security gain from those measures than from
> any preprocessing.
This is notably not the case with the well-known Venona, which used
a codebook to process the plaintext before doing xor with OTP.
That history also shows that ensuring no reuse can be difficult.
> > My point is that if you have a large number of messages and you know
> > that these form pairs such that each pair comes from the same segment
> > of OTP but no two pairs share the same segment, then the task of
> > finding some such pairs is very difficult, as far as I can see. One could
> > try all the possible pairings, but that's a combinatorial explosion, in view
> > of the fact there is nothing to tell whether the pairing is correct, when
> > one picks two arbitrary messages from the pool.
> If you know the character distributions of the data just before the xor'ing
> you can try all possible pairs. The number of pairs increases only quadratical
> with the number of messages, so it's within range of todays computing
> capacity.
Yes. But one should note that, after picking a pair, it is yet fairly 'difficult'
to determine whether they belong to the same segment of OTP. Thus
the resource required in the whole undertaking is going to be extremely
huge in my view.
M. K. Shen
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Cryptographic voting
Date: Wed, 07 Jun 2000 17:16:01 +0200
=====BEGIN PGP SIGNED MESSAGE=====
Jim Ferry wrote:
<s>
> Is there a way to do this in the literature? (Or, better yet, is
> it so trivial that it's not even in the literature?)
Some time ago I posted something to news:alt.privacy.anon-server about
this, but it's still very messy and needs cleaning up. Basically I
thought you would need remailers between the validator and the tallier.
And the voter would set the route between the two.
To vote you would get a large number, securely, and this number would be
your ticket through the validator.
The validator would then sign your routed vote inside several layers of
encryption, so that when your vote was routed through all remailers the
tallier could see that the vote was signed by the validator and count
it.
I don't believe much in being able to check your vote afterwards, as
that greatly endangers your privacy. I can just imagine how some people
would get a gun placed against their head to force them to show they
voted 'correctly' and shoot them in terror if that vote didn't satisfy.
(But I'm no cryptographer, I'm just a remailer fanatic).
The remailers should check for duplicates to avoid replay attacks. This
is maybe not possible due to the mere size of all the voting packages,
so I figured figured that the voter could have generated a second random
number, which has the vote hidden inside of it (the vote should only
take up a few bits). The tallier stores this random number and disallows
further signed packages which result to the same random number. If this
number is big enough, and the RNG's strong enough, noone will get the
same number.
To increase reliability of the remailers between the validator and the
tallier, it might be possible to send your vote multiple times, though
multiple chains. The second random number would get rid of duplicates.
Furthermore there could be remailer stats which the voter could observe.
I haven't got a real sollution to trashing the remailers or
validator/tallier, but then again, the recent attacks on amazone showed
nearly nobody is safe from a Distributed DOS attack :-(
The whole thread, with my sometimes afterward corrected thoughts is
still readable on Deja News:
<http://www.deja.com/=dnc/viewthread.xp?AN=573376522>. But don't spend
too much time on it as it is very messy.
Hope this all makes sense to you,
Thomas
=====BEGIN PGP SIGNATURE=====
iQB5AwUBOT5Y9gEP2l8iXKAJAQFMpQMePBaecqBMB5LS7RBM9qrfvTdcuGC479cv
4xoY0r6jU3ovVMG7hK3o4O1XshnFcUlPyMpawcIoR1INxEG6hX+emb2Ix0FKOaPo
n9bIh/MBw93Od96dT2XRy4rRPstSuxYMWzAuBQ==
=9JIh
=====END PGP SIGNATURE=====
--
We live in the Matrix <http://www.whatisthematrix.com>
http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x225CA009
Email: boschloo_at_multiweb_dot_nl
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Could RC4 used to generate S-Boxes?
Date: Wed, 07 Jun 2000 15:12:43 GMT
On the subject of s-box analyisis....
does anyone know a good tutorial on the subject (pdf or html formats
only)?
=======
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: Enigma Variations
Date: Wed, 07 Jun 2000 17:30:18 +0200
John Spicer wrote:
> This led me to wonder what was the state of the cryptography used by the
> Allies and what in-roads had the Germans and Japanese made? Did the
> Allies learn from their successes against the Axis cryptos and
> strengthen their own, or did they fall into the same traps?
See the books of D. Kahn listed in the literature references of
Schneier's Applied Cryptography.
M. K. Shen
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Thoughts on an encryption protocol?
Date: Wed, 07 Jun 2000 09:20:13 -0600
I have a couple of thoughts on this, off the top of my
head. (Which is to say, maybe I'm overlooking the really
important stuff...)
First, the technique of creating the session key based on
the prior key seems prone to problems. Not security problems,
but communication problems. If you ever lose "sync", you need
to design a way to recover. You need to consider lost messages,
reboots (on either end), and so forth.
Second, you haven't explicitly mentioned a threat model. What
are the capabilities and interests of the attacker(s)? Could
they conceivably "hack into" the client machine and steal things,
like the master keys? How much do you trust those with physical
access to the server or clients? And so forth. Often these
kinds of considerations can reveal fatal assumptions about what
you are protecting against (or that you are working too hard).
On the technical crypto front, the mechanism you described for
deriving a 256-bit key from a prior one doesn't really do that.
It derives a (pair of) 128-bit key(s) from a prior one (pair).
That is, the two halves are independant. It would be better to
mix all 256 input bits together for the output. For example,
try hashing all 256 input bits twice (getting 128 bits out each
time); the first time prefix one constant, and the second time
prefix a different one. Alternatively, see if you can find a 256
bit hash (e.g., Panama), although I don't think there is one with
the level of trust in MD5 or SHA. Of course, many would say that
this is all overkill, as 128-bit keys ought to be adequate.
Maybe you could compromise, and use SHA-1 with 160-bit keys,
or maybe Tiger, with 192-bit keys.
Finally, I thought I'd mention that you might have to work pretty
hard to generate 512 bits of real entropy for every client. You
probably already considered this, but for those listening out
there: the weak part of the whole scheme could turn out to be
a poor source of "random" numbers for keys.
John M
P.S.
Have you considered any "ready-made" protocols? Is public-key
stuff "too hard"? What about Kerberos, etc? There is an awful
lot of source code out there...
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Some citations
Date: Wed, 07 Jun 2000 17:36:56 +0200
Paul Koning wrote:
> That's not to say you should make your designs public if
> there is no reason to. It only says that you can't
> *rely* on the secrecy of the design as a source of security.
I agree with you fully. Compare my follow-up of 06 June.
M. K. Shen
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
Subject: Re: Question about recommended keysizes (768 bit RSA)
Date: Wed, 7 Jun 2000 09:25:45 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... the Cyber 175 ]
> It did run the worst designed timesharing system I've ever
> used. (Then again, I never did get to use RAX...)
Out of curiousity, which was that? Scope and NOS were both pretty
awful, but if there was something even worse, it'd be interesting to
know what it was...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: "Morgan Holt" <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.politics.uk,alt.security.scramdisk,uk.telecom
Subject: Re: Observer 4/6/2000: "Your privacy ends here"
Date: Tue, 6 Jun 2000 13:56:42 +0100
Reply-To: "Morgan Holt" <[EMAIL PROTECTED]>
Charles Bryant <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <511.393a83f0.6d2e@scgf>, Phillip Deackes <[EMAIL PROTECTED]> wrote:
> >The answer is simple. A massive campaign to get all email users to
> >include certain words in every email they send.... they *cannot* deal
> >with mass civil disobedience.
>
> They can't? So why haven't speed limits been abolished? About 70% of
> people break the speed limit at some time or another.
And 70% of stats are made up on the spot. The reason that a national speed
limit exists in this country is because people generally believe it to be
the safest option.
HMG has a big PR job on its hands to convince everybody that they can have
their letters opened by authorities.
Morgan
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Cryptographic voting
Date: Wed, 07 Jun 2000 17:44:11 +0200
There is at least one commercial undertaking in the business
of voting, but its webpage [EMAIL PROTECTED] doesn't contain
much interesting material in my humble view.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: testing non linearity of arithmetic-logic combinations
Date: Wed, 07 Jun 2000 15:42:52 GMT
On Wed, 7 Jun 2000 16:46:37 +1000, in
<[EMAIL PROTECTED]>, in sci.crypt "cranky cransky"
<[EMAIL PROTECTED]> wrote:
>could somebody point me towards some research, if there is any, on non
>linearity or linearity of certain chip level operations (addition,
>subtraction, xor, shift, etc..) i was thinking of coding something to try
>different combinations of these operands on integers and examine the
>results for the combinations that produce the most non linearity. is such an
>extensive test necessary? is this a well worn path?
Articles have been published on this, but no arithmetic-level function
is very nonlinear. Much better nonlinear functions and related
operations are random-like substitutions, Latin squares, and
orthogonal Latin squares.
>is it possible to
>examine the nature of the function itself ( like boolean logic, or addition
>axioms or whatever ) and work it out, instead of testing????!?!?!
>aaargh...anywho, help appreciated.
The form of nonlinearity which is currently measured is "Boolean
function nonlinearity," on which topic I have a page of description
with JavaScript computation of results.
http://www.io.com/~ritter/JAVASCRP/NONLMEAS.HTM
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
Subject: Re: testing non linearity of arithmetic-logic combinations
From: tomstd <[EMAIL PROTECTED]>
Date: Wed, 07 Jun 2000 09:16:21 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry
Ritter) wrote:
>
>On Wed, 7 Jun 2000 16:46:37 +1000, in
><[EMAIL PROTECTED]>, in sci.crypt "cranky
cransky"
><[EMAIL PROTECTED]> wrote:
>
>>could somebody point me towards some research, if there is
any, on non
>>linearity or linearity of certain chip level operations
(addition,
>>subtraction, xor, shift, etc..) i was thinking of coding
something to try
>>different combinations of these operands on integers and
examine the
>>results for the combinations that produce the most non
linearity. is such an
>>extensive test necessary? is this a well worn path?
>
>Articles have been published on this, but no arithmetic-level
function
>is very nonlinear. Much better nonlinear functions and related
>operations are random-like substitutions, Latin squares, and
>orthogonal Latin squares.
Latin squares have the problem of consuming too much memory, and
even still I have yet to see any published results on good
sboxes formed by Latin Squares.
Ideally you want your 'substitution' whether table or
arithmetically driven to conform to SAC, BIC, have low in-out
xor pairs and be as close to 'bent' as possible.
>>is it possible to
>>examine the nature of the function itself ( like boolean
logic, or addition
>>axioms or whatever ) and work it out, instead of
testing????!?!?!
>>aaargh...anywho, help appreciated.
>
>The form of nonlinearity which is currently measured is "Boolean
>function nonlinearity," on which topic I have a page of
description
>with JavaScript computation of results.
>
> http://www.io.com/~ritter/JAVASCRP/NONLMEAS.HTM
>
Stuff's pretty cool, you should make a 'sboxgen' like program to
go with 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: Could RC4 used to generate S-Boxes?
From: tomstd <[EMAIL PROTECTED]>
Date: Wed, 07 Jun 2000 09:17:46 -0700
In article <8hlooo$3ej$[EMAIL PROTECTED]>, Simon Johnson
<[EMAIL PROTECTED]> wrote:
>On the subject of s-box analyisis....
>does anyone know a good tutorial on the subject (pdf or html
formats
>only)?
I may undertake a paper reviewing the early work by the CAST et
al team. Stay tuned (I am finishing another paper right now).
Other then that... just ask questions here.
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: Jim Reeds <[EMAIL PROTECTED]>
Subject: Re: Some dumb questions
Date: Wed, 7 Jun 2000 16:18:28 GMT
My 2 bits for this interminable discussion:
Among other things, Mok-Kong Shen wrote:
> This is notably not the case with the well-known Venona, which used
> a codebook to process the plaintext before doing xor with OTP.
> That history also shows that ensuring no reuse can be difficult.
This is false in point of detail: the Venona codebooks had numerical
code words (4 digits each, I think), where were mod 10 added to the
digits printed on the sheets of the one time pad. The common
confusion of the XOR of the Vernam cipher (invented by my firm in
1917 or so) and of the mod 10 addition of the one time pad (invented
in Germany in the early 1920s) is a mistake introduced by modern
text books, whose authors care more about underlying mathematical
principles than historical accuracy.
--
Jim Reeds, AT&T Labs - Research
Shannon Laboratory, Room C229, Building 103
180 Park Avenue, Florham Park, NJ 07932-0971, USA
[EMAIL PROTECTED], phone: +1 973 360 8414, fax: +1 973 360 8178
------------------------------
Subject: Re: Request for review of "secure" storage scheme
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Wed, 07 Jun 2000 16:24:37 GMT
Baruch Even <[EMAIL PROTECTED]> writes:
> A simpler method could be used in my opinion.
>
> Most probably the user has a userid and password, and I assume so
> for this scheme.
>
> It should be noted that when you deal with credit card numbers
> and any other sensitive infomation you should be carrying this
> steps in SSL/TLS (i.e. encrypted by the browser), you should further
> note that you can mark cookies to be sent ONLY over encrypted
> channels and for a cookie that carries sensitive informations this
> should be used.
note on SSL alert for IE:
http://www.cert.org/advisories/CA-2000-10.html
some misc. discussion excerpted from financial standards retail
payments mailing list (merchant comfort certificates):
http://www.garlic.com/~lynn/aepay4.htm
--
Anne & Lynn Wheeler | [EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: testing non linearity of arithmetic-logic combinations
Date: 7 Jun 2000 16:27:09 GMT
tomstd <[EMAIL PROTECTED]> wrote:
> Latin squares have the problem of consuming too much memory,
That depends on how large they are, surely. A pair of 4 x 4 squares
wouldn't be any larger than a standard S-box.
> and even still I have yet to see any published results on good sboxes
> formed by Latin Squares.
Surely you could analyse it in pretty much the same way as you do a
normal S-box: look at the output difference probabilities for each input
difference as usual; look at its nonlinearity in a similar way, and so
on.
In any event, it can't be much weaker than XOR, so you're onto a winner
from a strength point of view. The only question is whether it's worth
it for the performance penalty.
-- [mdw]
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Cryptographic voting
Date: Wed, 07 Jun 2000 16:21:58 GMT
Obviously before we make any progress on the solution
to this problem, we are going to have to figure out
what question (or more probably questions) we are
asking.
To that end, I hve compiled a little list
of questions and or options that mght apply
to te question of cryptograhic voting:
I encourage anyone to add to this list.
1) Is the voting to be secre or public
2) If it is to be secret, should the voter have a
way of checking that his vote has been counted
correctly.
3) If the ans. to the above two questions is "YES",
then is the voter to have a way of making it appear
that he voted differntly than he did?
4) Is there to be a trusted party? Is there to be a
trusted party who sets up the system but does
not need to be a part of the protocol after that?
5) What kinds of communications abiities do the
voters have? Can they all communicate with each other,
or do they communicate by posting to a common
bulletin board?
Personally, I think it would be nice to have the
following: Voting is secret, but voters can check to
make sure their vote was tallied correctly. Voters
can also make it appear that they are checking
their votes, but in a way that causes it to appear
that they voted differently than they did. No
trusted party should be required.
Now, *that* would be a protcol.
--
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.
------------------------------
Subject: Re: testing non linearity of arithmetic-logic combinations
From: tomstd <[EMAIL PROTECTED]>
Date: Wed, 07 Jun 2000 09:31:31 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Mark Wooding) wrote:
>tomstd <[EMAIL PROTECTED]> wrote:
>
>> Latin squares have the problem of consuming too much memory,
>
>That depends on how large they are, surely. A pair of 4 x 4
squares
>wouldn't be any larger than a standard S-box.
If you used a pair of 4x4 latin squares (presumably to make a
8x8 sbox?) then you still have the problem that each of the
columns/rows of the latin squares must be good sboxes.
I assume this because a latin square is just a F : Snxn -> Tn so
the output is half the size of the input. So logically you
would have to use the "pair" in this fashion.
It's not a good idea though.
>> and even still I have yet to see any published results on
good sboxes
>> formed by Latin Squares.
>
>Surely you could analyse it in pretty much the same way as you
do a
>normal S-box: look at the output difference probabilities for
each input
>difference as usual; look at its nonlinearity in a similar way,
and so
>on.
>
>In any event, it can't be much weaker than XOR, so you're onto
a winner
>from a strength point of view. The only question is whether
it's worth
>it for the performance penalty.
As compared to a normal 2nx2n sbox, I think the normal sbox will
be a winner, but I have never actually tested this. Will do
after school.
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] (Frank M. Siegert)
Subject: Re: Solution for file encryption / expiration?
Date: Wed, 07 Jun 2000 17:02:31 GMT
On Wed, 7 Jun 2000 07:01:59 GMT, Anders Thulin
<[EMAIL PROTECTED]> wrote:
> You may want to check http://www.ebxwg.org/ for some related information.
>www.glassbook.com has a PDF reader which uses the EBX security handler.
>
> My impression is that it won't stop someone who is *very* determined to
>get at your books, but it will stop those 80% of computer users who
>never try anything out of the ordinary.
I suggest reading above URL and then
http://www.ebooknet.com/story.jsp?id=1671
------------------------------
** 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
******************************
