Cryptography-Digest Digest #200, Volume #13 Tue, 21 Nov 00 19:13:01 EST
Contents:
Re: Legal issues for hobbiests (Steve Portly)
Re: Pseudo random sequence generation for xor encryption (OTP) (David Schwartz)
Re: A Simple Voting Procedure (David Wagner)
Re: A Simple Voting Procedure (David Wagner)
Re: vote buying... ("Tony T. Warnock")
Re: A Simple Voting Procedure (David Schwartz)
Capcom Encryptions ("Zen")
Re: Proof of posession (David Wagner)
Re: A Simple Voting Procedure (David Schwartz)
Re: Proof of posession ("Matt Timmermans")
Re: My new book "Exploring RANDOMNESS" (Richard Heathfield)
Re: need help claasifying my progrma (Richard Heathfield)
Re: Pseudo random sequence generation for xor encryption (OTP) (Tom St Denis)
Re: A poorman's cipher (Tom St Denis)
Re: Legal issues for hobbiests (Tom St Denis)
Re: Randomness from key presses and other user interaction (Terry Ritter)
Re: Q: fast block ciphers (Tim Tyler)
Re: Q: fast block ciphers (Tim Tyler)
Re: Pseudo random sequence generation for xor encryption (OTP) (Simon Johnson)
Re: A poorman's cipher (Mack)
Re: Randomness from key presses and other user interaction (David Schwartz)
RE: More about big block ciphers ("Manuel Pancorbo")
Re: Legal issues for hobbiests (Mack)
----------------------------------------------------------------------------
From: Steve Portly <[EMAIL PROTECTED]>
Subject: Re: Legal issues for hobbiests
Date: Tue, 21 Nov 2000 16:56:52 -0500
David Schwartz wrote:
> John Savard wrote:
>
> > It's when you are a little guy who wants to let people download off
> > the Internet that you have a problem.
>
> It depends upon how little. If you can get enough download volume, you
> may be able to get your product classified as 'retail', in which case
> there are no key-length limits. Unless your key length is your selling
> point, you should be able to make a restricted key length version, build
> volume, and then apply for retail status.
>
> DS
As Tom St. Denis pointed out elsewhere in this thread, creating an efficient code
is quite difficult.
I believe there is a subset of individuals that could write an expensive key
program in C without being able to stringently classify it. About 5 percent of
the population could program an expensive key system that would exceed NIST
guidelines if it were presented for classification. A cipher that is only 80 %
efficient would still be dangerous in the hands of a terrorist if the cipher is
strong.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Pseudo random sequence generation for xor encryption (OTP)
Date: Tue, 21 Nov 2000 14:20:23 -0800
Ivan Skytte J�rgensen wrote:
>
> What is the best way of producing a pseudo random sequence for use with
> xor encryption?
>
> Huge precomputed sequences stored on each computer seem impractical.
>
> I was thinking of seeding a random generator with a shared secret
> combined with a reasonably sized per-session "unique" seed, and
> periodically re-seeding the random generator with pieces of the
> cleartext.
>
> Both ends of the encryption channel is considered secure. The cleartext
> has some structure, so some of the cleartext are will be known by
> attackers, but not all of it.
I would suggest using rc4/arcfour. It already does all of this and is
well understood and well tested.
DS
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: A Simple Voting Procedure
Date: 21 Nov 2000 22:26:21 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
David Schwartz wrote:
> But with a receipt scheme, they can only claim that the receipt is
>their receipt. They can't prove it.
Then what good is the receipt? I don't see any point to have a receipt
if it doesn't prove anything!
One problem is that the goalposts seem to keep changing; every time
someone points out a problem, you change your proposal of how to build a
voting system, and I find it difficult to keep track of all the changes.
Why don't you work out a detailed, concrete proposal, listing all the
security goals and properties of a specific proposed scheme, and describe
why you feel it is immune to all of the attacks discussed here and elsewhere?
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: A Simple Voting Procedure
Date: 21 Nov 2000 22:27:49 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
David Schwartz wrote:
>Paul Rubin wrote:
>> > But with a receipt scheme, they can only claim that the receipt is
>> > their receipt. They can't prove it.
>>
>> DUH, then they can't establish how they voted.
>
> Sure they can. They can, for example, take a photograph of the receipt
>being printed with them in the picture and in the voting booth.
Well, look, then that very picture _is_ itself a proof of how you voted,
and it allows vote coercian and vote buying.
Look, you can't have it both ways. If voters can prove how they voted,
they can sell their votes, and they can be coerced after the fact. If
they can't prove how they voted, then there is no point in giving them
a special receipt.
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: vote buying...
Date: Tue, 21 Nov 2000 15:27:38 -0700
Reply-To: [EMAIL PROTECTED]
Jeffrey Williams wrote:
> Sorry if I wasn't clear. I believe that to be fair, honest, and trustworthy, a voter
> would have to present a national ID card containing a picture of the owner and an
> indication of the citizenship of the owner (the latter could be implicite if, and
>only
> if, such cards were issued only to US citizens). The card would presumably be a
> smartcard which the voting authority could validate with a central database.
Having a National ID Card would at least create opportunities for counterfeiters.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
Date: Tue, 21 Nov 2000 14:29:02 -0800
David Wagner wrote:
> Look, you can't have it both ways. If voters can prove how they voted,
> they can sell their votes, and they can be coerced after the fact. If
> they can't prove how they voted, then there is no point in giving them
> a special receipt.
There is a point, they can prove to themselves that their vote was
counted and counted properly.
DS
------------------------------
From: "Zen" <[EMAIL PROTECTED]>
Subject: Capcom Encryptions
Date: Sat, 18 Nov 2000 23:02:47 +0200
Does anyone know which company helped Capcom encrypt their CPS-2 Board
system??? any help or clues would be appriciated
[EMAIL PROTECTED]
remove the dont and the wantspam
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Proof of posession
Date: 21 Nov 2000 22:40:25 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
There was a recent thread on this very newsgroup entitled
"Proving continued possession of a file" that I think you
might find relevant to your problem.
See, e.g.,
http://www.deja.com/[ST_rn=ps]/threadmsg_ct.xp?AN=649762980&fmt=text
http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=650013360&fmt=text
http://www.deja.com/[ST_rn=ps]/threadmsg_ct.xp?AN=652080402&fmt=text
Those are messages with the following MessageID's:
<[EMAIL PROTECTED]>
<8lgn9h$r4i$[EMAIL PROTECTED]>
<8ltusp$rmb$[EMAIL PROTECTED]>
Does that help at all?
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
Date: Tue, 21 Nov 2000 14:32:02 -0800
David Wagner wrote:
>
> David Schwartz wrote:
> > But with a receipt scheme, they can only claim that the receipt is
> >their receipt. They can't prove it.
>
> Then what good is the receipt? I don't see any point to have a receipt
> if it doesn't prove anything!
It allows the voter to convince themself that their vote was counted
and counted for the correct candidate. If somehow their vote doesn't
appear in the count for the correct candidate, or appears in the count
for the wrong candidate, the voting receipt would be proof that their
vote was incorrectly tallied. While this may not have enormous value
from a technical standpoint (because injecting bogus votes for yourself
is as good as deleting legitimate votes for your opponent), it may have
tremendous subjective value in allowing people to know, for sure, that
their vote was counted and counted correctly as opposed to dropped on
the floor and forgotten.
> One problem is that the goalposts seem to keep changing; every time
> someone points out a problem, you change your proposal of how to build a
> voting system, and I find it difficult to keep track of all the changes.
As I've said, I'm not suggesting any particular proposal or scheme. I'm
trying to understand the requirements.
> Why don't you work out a detailed, concrete proposal, listing all the
> security goals and properties of a specific proposed scheme, and describe
> why you feel it is immune to all of the attacks discussed here and elsewhere?
Because I don't know what the requirements are. I keep trying to find
out what requirements people have but they keep responding with
arguments about pros and cons of particular implementation schemes.
DS
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: Proof of posession
Date: Tue, 21 Nov 2000 17:07:39 -0500
Reply-To: "Matt Timmermans" <[EMAIL PROTECTED]>
The best I can think of that doesn't require the central authority to keep a
copy of every file is:
Divide the file into 16K chunks, hash each of them separately, and cat the
hashes together. This is the level N hash.
Repeat the procedure until there is only one chunk and hash it to get the
level 0 hash.
The authority can send you the level 0 hash upon request. Given that,
before downloading a file you can download and check all hash levels.
------------------------------
Date: Tue, 21 Nov 2000 22:54:56 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.logic
Subject: Re: My new book "Exploring RANDOMNESS"
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>,
> Richard Heathfield <[EMAIL PROTECTED]> wrote:
>
> > Counter-examples, all of which (IMHO) are relevant to sci.crypt: >
> > "The Art of Computer Programming" - Knuth
> > "The C Programming Language" - Kernighan and Ritchie
> > "Applied Cryptography" - Schneier
> >
> > If any of these /are/ available online, I'd be astonished (and I want
> > the URL!).
>
> Why would that be surprising ? Is it not logical to spread
> best books first ? Nowadays most of security and computer related
> best-sellers are available in electronic format : from your list,
> at least AC2 and K&R do exist (.htm and .txt, respectively). However,
> for obvious reasons you will have to search a bit to get them.
Pardon me for being dense, but why would one need to search terribly
hard for them?
If AC2 is available electronically, it would be either on the Wiley site
or on Counterpane. As for K&R, it would be on Prentice Hall's Web site,
or possibly Lysator.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
------------------------------
Date: Tue, 21 Nov 2000 23:01:54 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: need help claasifying my progrma
Tom St Denis wrote:
>
> In article <[EMAIL PROTECTED]>,
> Richard Heathfield <[EMAIL PROTECTED]> wrote:
> > MyDimension wrote:
> > >
> > > I have created a program that encrypts using a chaotic signal
> instead of an
> > > x-bit key. how can I classify this so I can export the program
> without
> > > breaking export laws?
> >
> > I'm tempted to suggest that you put the idea safely in your head, and
> > move to a free country. Then dig the idea out again and use it however
> > you like.
> >
> > The trick is finding a free country.
>
> The trick is to decipher the guys goobly-gook.
His problem is not technological, but social, in that he is seeking
export assistance, if you'll forgive the pun. He's probably off-topic,
actually, although chaotic signal cryptography wouldn't be (if it
exists, on which I have no current opinion).
> "Chaotic Signal" is not
> a recognized scientific term for ANYTHING!
Three random hits from a Web search:
http://www.cplire.ru/win/InformChaosLab/papers/ndes99dkh.html (looks
authoritative, at any rate)
http://www.inet-one.com/cypherpunks/dir.1995.12.13-1995.12.19/msg00011.html
(/doesn't/ look authoritative!)
http://members.nbci.com/Templarser/mastring.html (looks authoritative)
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Pseudo random sequence generation for xor encryption (OTP)
Date: Tue, 21 Nov 2000 23:04:41 GMT
In article <[EMAIL PROTECTED]>,
Ivan Skytte =?iso-8859-1?Q?J=F8rgensen?=
<[EMAIL PROTECTED]> wrote:
> What is the best way of producing a pseudo random sequence for use
with
> xor encryption?
Technically "xor encryption" is not a real term in cryptography.
> Huge precomputed sequences stored on each computer seem impractical.
That's correct.
> I was thinking of seeding a random generator with a shared secret
> combined with a reasonably sized per-session "unique" seed, and
> periodically re-seeding the random generator with pieces of the
> cleartext.
Hmm bad idea. Using plaintext (not the wordage) as a re-seeding
mechanism opens the doors to chosen-plaintext attacks. This "seed" is
normally referred to as the "key" since it is supposedly required to
reproduce the stream to decrypt. The key should either be exchanged
via PK, DH or hashed with a random IV.
> Both ends of the encryption channel is considered secure. The
cleartext
> has some structure, so some of the cleartext are will be known by
> attackers, but not all of it.
Well if the plaintext is known cryptography WILL NOT protect you.
Structures (or known) plaintext can help a cryptanalysis but if the
algorithm you choose is any good they will need more then is feasible
to actually mount the attack.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: A poorman's cipher
Date: Tue, 21 Nov 2000 23:00:52 GMT
In article <zcCS5.17745$[EMAIL PROTECTED]>,
"Michael Scott" <[EMAIL PROTECTED]> wrote:
>
> "Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> >
> > Addendum (III)
> >
> > Globally, it may be observed that, while the common block
> > ciphers work vertically in the sense of first attempting
> > to achieve as much diffusion as possible within a small
> > number of bits inside a block and then attempting to
> > achieve diffusion throughout the message via block chaining,
> >......
>
> That's why Rijdael/Square is such a nice idea. By arranging the state
as a
> block of 4x4 bytes much tighter coupling is acheived between the
individual
> elements and hence much quicker diffusion. I wonder has anyone
extrapolated
> the idea to "CUBE", or perhaps a tesseract?
The problem with a SQUARE design like Square/Crypton/Rijndael is that
diffusion is amongst 32-bit words and not the byte granularity. If you
take SAFER+ with a 16x16 MDS matrix it would most likely be way
stronger then Rijndael for that reason alone. (hmm seems like a kooky
idea :-) )
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Legal issues for hobbiests
Date: Tue, 21 Nov 2000 23:07:18 GMT
In article <[EMAIL PROTECTED]>,
Steve Portly <[EMAIL PROTECTED]> wrote:
>
>
> David Schwartz wrote:
>
> > John Savard wrote:
> >
> > > It's when you are a little guy who wants to let people download
off
> > > the Internet that you have a problem.
> >
> > It depends upon how little. If you can get enough download
volume, you
> > may be able to get your product classified as 'retail', in which
case
> > there are no key-length limits. Unless your key length is your
selling
> > point, you should be able to make a restricted key length version,
build
> > volume, and then apply for retail status.
> >
> > DS
>
> As Tom St. Denis pointed out elsewhere in this thread, creating an
efficient code
> is quite difficult.
> I believe there is a subset of individuals that could write an
expensive key
> program in C without being able to stringently classify it. About 5
percent of
> the population could program an expensive key system that would
exceed NIST
> guidelines if it were presented for classification. A cipher that is
only 80 %
> efficient would still be dangerous in the hands of a terrorist if the
cipher is
> strong.
True. Most home-brew ciphers are either potentially weak or too
inefficient to be practical. Dave Scotts ciphers are for the most part
simple and most likely secure, but require huge tables and are slow
which makes them impractical. RC5 on the otherhand is also simple and
very efficient. It can encrypt at about 100 cycles per block on my
Athlon Thunderbird (using ASM code) and requires about 100 bytes of
memory....
N.B a current hardware cipher I am designing is very efficient in
hardware but not particularly good in software. So there is also that
type of tradeoff.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Randomness from key presses and other user interaction
Date: Tue, 21 Nov 2000 23:21:38 GMT
On 21 Nov 2000 16:26:50 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (Mack) wrote:
>[...]
>As another branch pointed out. If the user can just hold down a key
>then all of the entropy available is from the clock skew which is at most
>a couple of bits per minute.
For practical purposes, there is *NO* continuing entropy from "clock
skew."
There may be *at* *most* a one-time start-up difference.
The total available entropy is typically limited to 40 bits by the
exponential time needed to detect frequency differences via software.
So if you get a couple of bits in a first minute, the next couple of
bits will take two minutes, then four, then hours and days.
But to achieve even that situation, the system must start in a fully
random state each time. If power is applied to both oscillators
simultaneously, there may be very little true entropy present, maybe
just a few bits *total*. It seems unlikely that we could detect that
dangerous state, and so are forced to assume that has occurred.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Q: fast block ciphers
Reply-To: [EMAIL PROTECTED]
Date: Tue, 21 Nov 2000 23:17:05 GMT
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
: I would be interested in hearing how one would change a stream cipher
: into a block cipher.
You could encrypt each block using the stream cypher (as though it was a
separate message). It would probably be best to encrypt "in both
directions" - or the resulting block cypher may be of rather poor quality.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Q: fast block ciphers
Reply-To: [EMAIL PROTECTED]
Date: Tue, 21 Nov 2000 23:20:02 GMT
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
: Douglas A. Gwyn wrote:
:> Pranke wrote:
:> > I never have heared of the idea to use a stream cipher as a block
:> > cipher, and I really would like to know how THAT should work ?
:> > While using a block cipher as stream cipher is indeed trivial.
:>
:> To the contrary, a block cipher requires that PT be encrypted
:> in chunks rather than a single character at a time; if you
:> pervert a block cipher into a key generator, then yes the key
:> can be used in a stream cipher, albeit one subject to
:> exploitation, because that is not using the block cipher in
:> its designed enciphering role.
: How are Counter, OFB, or CFB, not "the designed enciphering role"?
I figure Douglas is trying to say that then the plaintext doesn't get fed
through the cypher. OFB mode has various poor qualities as a result.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Pseudo random sequence generation for xor encryption (OTP)
Date: Tue, 21 Nov 2000 23:22:15 GMT
In article <[EMAIL PROTECTED]>,
Ivan Skytte =?iso-8859-1?Q?J=F8rgensen?=
<[EMAIL PROTECTED]> wrote:
> What is the best way of producing a pseudo random sequence for use
with
> xor encryption?
>
> Huge precomputed sequences stored on each computer seem impractical.
>
> I was thinking of seeding a random generator with a shared secret
> combined with a reasonably sized per-session "unique" seed, and
> periodically re-seeding the random generator with pieces of the
> cleartext.
>
> Both ends of the encryption channel is considered secure. The
cleartext
> has some structure, so some of the cleartext are will be known by
> attackers, but not all of it.
>
A self shrinking LFSR is about as good a random number generator as one
can get. Okay, its not lightning in software, but with a dense
polynomial the sucker is secure. Not only that, your 100% sure that
sequence until (2^n)-1 interations (where n is the order of the
polynomial)
If you havn't seen these before, consult 'Applied Cryptography'.
Hope this of help,
Simon.
--
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] (Mack)
Date: 21 Nov 2000 23:38:09 GMT
Subject: Re: A poorman's cipher
>In article <zcCS5.17745$[EMAIL PROTECTED]>,
> "Michael Scott" <[EMAIL PROTECTED]> wrote:
>>
>> "Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]...
>> >
>> > Addendum (III)
>> >
>> > Globally, it may be observed that, while the common block
>> > ciphers work vertically in the sense of first attempting
>> > to achieve as much diffusion as possible within a small
>> > number of bits inside a block and then attempting to
>> > achieve diffusion throughout the message via block chaining,
>> >......
>>
>> That's why Rijdael/Square is such a nice idea. By arranging the state
>as a
>> block of 4x4 bytes much tighter coupling is acheived between the
>individual
>> elements and hence much quicker diffusion. I wonder has anyone
>extrapolated
>> the idea to "CUBE", or perhaps a tesseract?
>
>The problem with a SQUARE design like Square/Crypton/Rijndael is that
>diffusion is amongst 32-bit words and not the byte granularity. If you
>take SAFER+ with a 16x16 MDS matrix it would most likely be way
>stronger then Rijndael for that reason alone. (hmm seems like a kooky
>idea :-) )
>
>Tom
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
>
>
Interesting note is that Safer++ was presented at NESSIE.
This is a leaner meaner version of Safer+
see
http://cryptonessie.org/
For more details ...
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Randomness from key presses and other user interaction
Date: Tue, 21 Nov 2000 15:31:56 -0800
Terry Ritter wrote:
> For practical purposes, there is *NO* continuing entropy from "clock
> skew."
That would be true if oscillators were perfectly stable, but they're
not.
> There may be *at* *most* a one-time start-up difference.
Why do you say at most? How predictable do you think uncompensated
quartz oscillators are?
> The total available entropy is typically limited to 40 bits by the
> exponential time needed to detect frequency differences via software.
> So if you get a couple of bits in a first minute, the next couple of
> bits will take two minutes, then four, then hours and days.
>
> But to achieve even that situation, the system must start in a fully
> random state each time. If power is applied to both oscillators
> simultaneously, there may be very little true entropy present, maybe
> just a few bits *total*. It seems unlikely that we could detect that
> dangerous state, and so are forced to assume that has occurred.
That assumes that there is no unpredictable jitter in an uncompensated
quartz oscillator at all. But they actually drift by about 4 parts per
billion from second to second. I do not believe there is any way to
predict this jitter/drift as it is believed to be the result of
microscopic 'zone' temperature variations and thermal 'shot' noise.
DS
------------------------------
From: "Manuel Pancorbo" <[EMAIL PROTECTED]>
Subject: RE: More about big block ciphers
Date: Tue, 21 Nov 2000 23:46:38 GMT
"Tom St Denis" <[EMAIL PROTECTED]> ...
> >
> > Must the entire byte change? (hint hint hint hint!)
>
> Ok to clarify.
Thanks for this contribution. I really appreciate it.
> My point is let's say I change the lsb
>
> 00 00 00 0.
>
> And after the sbox look up we get a change in only one/two/three/four
> of the lsb bits...
>
> 00 00 00 0.
>
> And after the rotate <<<4
>
> 00 00 00 .0
>
> And in the next round we find a difference .0 -> 0. etc...
>
> So I could very easily form a change of differentials that only involve
> one sbox. Given you are using the sboxes from Rijndael they are
> bounded by a max prob of 4/256... so my attack on a single F(x) call
> (both layers of substitution) will work with a probability of no more
> then 16/65536 (or 2^-12). In theory though the "weak diffusion" will
> occur with much higher frequency (note my 2^-12 is a differential
> attack and not a form of diffusion modelling).
>
Then you must take into account that this attack must fit also this
requirement for the next unit; so 2^-24; and for the next, 2^-36; and for
the next, 2^-48... So 2^-(12 n), being 'n' the number of units from the
point of attack up to the end of the packet. And I didn't consider yet the
backward pass... perhaps this adds 2^-12 times more. So, 2^-(24 n).
If we start the attack near the end of the packet it could work because in
this case 'n' is small. This is why a previous backward cipher is made up to
a distance that I fixed in 8 units. Hence this attack will success after
2^192 tries... not too bad.
Also, you didn't consider the substitution in G-function...
> So nadadadada!
>
Revise your keyboard. It seems to be damaged.
--
____________________________________________________________________
Manuel Pancorbo
[EMAIL PROTECTED] (Apply ROT13)
____________________________________________________________________
------------------------------
From: [EMAIL PROTECTED] (Mack)
Date: 21 Nov 2000 23:48:23 GMT
Subject: Re: Legal issues for hobbiests
>In article <[EMAIL PROTECTED]>,
> Steve Portly <[EMAIL PROTECTED]> wrote:
>> What are the legal issues if an amateur crypto hobbyist in the USA
>> creates an encryption program that falls outside of the guidelines for
>> accepted key spaces? Certainly the program could not be sold
>> commercially. I also read somewhere that if the program is posted on
>> the internet in a useable form, NIST would need to be notified. Is
>> there any legal reason why the program could not be shared amongst
>> friends within the USA via private Email?
>
>Well most often amateurs (like me) make what seem like cool ciphers and
>tend not to be so (well TC5 is still secure but that's another story).
>I would seriously doubt that an amateur could create a cipher that
>could merit "non-export status" that is also efficient and practical.
>
>You're best bet if you are playing around is to IGNORE the laws and
>just play around. If you are in serious business then use a trusted
>algorithm (there are plenty to go around).
>
>Tom
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
>
Insecure does not mean that it meets export requirements.
For example a 256 bit block cipher might have an attack
that requires 2**200 plaintext. In the traditional sense it is
broken. But it is stronger than Rijndael.
Balancing security with speed is an art form. Even professionals
create insecure ciphers. Don't knock the 'Hobbyist'. Of course
today a broken cipher means that there are theoretic attacks that
are unlikely in practice. After all who uses the same key on 2**200
plaintexts? With the note that this may change sometime in the
future.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
** 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
******************************
