Cryptography-Digest Digest #201, Volume #13 Tue, 21 Nov 00 21:13:01 EST
Contents:
Re: Q: fast block ciphers (Benjamin Goldberg)
Re: need help claasifying my progrma (Tom St Denis)
why scramdisk menu don't work on win95 ? ([EMAIL PROTECTED])
Re: A poorman's cipher (Tom St Denis)
Re: Legal issues for hobbiests (Tom St Denis)
RE: More about big block ciphers (Tom St Denis)
Re: A Simple Voting Procedure (Paul Rubin)
Re: A Simple Voting Procedure (David Schwartz)
Re: A Simple Voting Procedure (Stanley Chow)
Re: Legal issues for hobbiests ("Brian McKeever")
Re: Legal issues for hobbiests (Mack)
Re: A Simple Voting Procedure (David Schwartz)
Re: Entropy paradox ("Trevor L. Jackson, III")
Re: Q: fast block ciphers (Benjamin Goldberg)
----------------------------------------------------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Q: fast block ciphers
Date: Wed, 22 Nov 2000 00:03:46 GMT
Tom St Denis wrote:
>
> In article <[EMAIL PROTECTED]>,
> Lauri Pesonen <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > I'm trying to figure out, which block cipher would fit my needs the
> > best. I'm in need of a very fast block cipher that could be used to
> > encrypt multiple (as many as possible) simultanious network streams.
> > The system would also use Matt Blaze's RKEP Protocol [1] (which
> > requires a block cipher instead of a stream cipher). The main point
> > is that multiple streams should be encrypted with as small a CPU
> > load as possible. Decryption is not all that performance sensitive
> > (of course it's not a minus if decryption is fast as well). The
> > cipher should be strong in the present day as well as for, let's
> > say, the next five years.
> >
> > I seem to remeber hearing from someone that blowfish is relatively
> > fast. Any faster block ciphers out there?
> >
> > Thanks for all your help.
>
> I once designed a block cipher that uses decorrelation modules for
> security. The idea was to precompute multiplication in GF(2)^32 as a
> series of four 8x32 sboxes. With six rounds I achieved a rate of
> about 13 cycles/byte on my AMD K6-II machine which is the fastest
> speed for a block cipher I ever heard of.
You've gotten GF(2)^32 and GF(2^32) confused (again!).
GF(2)^32 means that your cipher uses 32 independent values each of which
is an element of GF(2). Multiplying a pair of GF(2)^32 values means
that you take the 0th of each, multiply in GF(2), take the 1nd of each,
multiply in GF(2), etc... essentially doing a logical AND of the two
values. Multiplying a pair of GF(2^32) values means that you do
polynomial multiplication, then polynomial division by some primitive,
and use the remainder as the result.
> On my website some code called TC6a.c is available. The irreducible
> polynimal was entered wrong so you have to fix the source to use it.
polynomial
> Also the algorithm has had no formal analysis... user beware!
>
> Tom
Aside from my complaints about terminology, I do happen to think that
it's a good cipher.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: need help claasifying my progrma
Date: Wed, 22 Nov 2000 00:02:10 GMT
In article <[EMAIL PROTECTED]>,
Richard Heathfield <[EMAIL PROTECTED]> wrote:
> 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)
Often I think chaotic processes referred to the analytical modelling of
undefined stochastic processes. Such as the decay of a radioactive
isotope (sorry I am not a physicist) is considered chaotic mainly
because we cannot purely define all the events required to describe an
output. The events are specific and follow some subset of given rules
(hence stochastic) but are unknown to us.
Things like fractals and IFS's are other forms of analytical modelling
of real life data (in this case pictures).
However, such things are often not good for cryptographically secure
systems. Such as cellular automaton which are provably no more secure
then LFSR's and other types of feedback schemes...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.security.misc
Subject: why scramdisk menu don't work on win95 ?
Date: Wed, 22 Nov 2000 00:02:36 GMT
I have just tried to install scramdisk 3.01a, in a win98 pc, and work fine, but,
installing it in with win95b the interface menu don' t work, I just see two
"box" and the menu bar is not visible.
It's a bug in my computer or a software defect ?
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: A poorman's cipher
Date: Wed, 22 Nov 2000 00:07:44 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mack) wrote:
> Interesting note is that Safer++ was presented at NESSIE.
> This is a leaner meaner version of Safer+
>
> see
>
> http://cryptonessie.org/
>
> For more details ...
As a side note this is how you make SAFER+ way more secure.
1. Take the sbox from Rijndael (nice properties and the affine
transform is cool).
2. Take a 16x16 MDS where it's inverse is also a MDS.
3. Put them together :)
In theory the best differnetial attack could only break two rounds and
a linear attack far less. So with these new ideas and say six rounds
the cipher would be immune to ALL known attacks.
It would be slower since you must computed the MDS multiply on the
fly. One could be smart and precompute the multiplications (i.e make
sure there are only 8 or less unique elements).
It would be able to run out of a smartcard (slowly) or on a desktop
with precomputed mults fast enough to be usefull...
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: Wed, 22 Nov 2000 00:14:04 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mack) wrote:
>
> 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.
I never said that.
> 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.
The idea is that if a cipher resists all known attacks it is less
likely to emit a bias in another way. Unfortunately this rarely holds
true but it's the best metric we have. Sometimes efficiency is over or
mis-rated. A cipher that takes 10 cycles on a pentium may be cool but
it's hardly the panacea of technology. In virtually all cases the
current technology (blowfish, rc5, the AES proposals) are good enough.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: RE: More about big block ciphers
Date: Wed, 22 Nov 2000 00:11:45 GMT
In article <yPDS5.1117$[EMAIL PROTECTED]>,
"Manuel Pancorbo" <[EMAIL PROTECTED]> wrote:
>
> "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.
No problemo.
> > 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).
Well do future packets affect the stream backwards? Is the cipher
always rekeyed between new communications? (i.e is it a block or
stream cipher?). If it's not re-keyed I can break the first usage of
the F function with the 2^-12 attack. Otherwise it gets harder.
Why not change your F function to the following
F(X) = MDS * S(X xor K)
Where X is a 4x1 matrix (the input), S is four parallel 8x8
substitutions (all different, take different moduli for inversion in GF
(2^8)), K is your key and MDS is a 4x4 MDS matrix (hmm the one from
twofish?)
This would have way better diffusion and can be computed with only four
xors and look ups.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
Date: 21 Nov 2000 16:29:02 -0800
David Schwartz <[EMAIL PROTECTED]> writes:
> There is a point, they can prove to themselves that their vote was
> counted and counted properly.
Suppose that it turns out that according to their receipt, their vote
*wasn't* counted. They are screwed. If the receipt doesn't prove
anything to anyone else, what can they do besides feeling screwed?
They can feel screwed without the receipt, so the receipt isn't
useful.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
Date: Tue, 21 Nov 2000 16:34:18 -0800
Paul Rubin wrote:
>
> David Schwartz <[EMAIL PROTECTED]> writes:
> > There is a point, they can prove to themselves that their vote was
> > counted and counted properly.
>
> Suppose that it turns out that according to their receipt, their vote
> *wasn't* counted. They are screwed. If the receipt doesn't prove
> anything to anyone else, what can they do besides feeling screwed?
> They can feel screwed without the receipt, so the receipt isn't
> useful.
They can present the reciept and dispute the accuracy of the results of
the election. Since the receipt is signed, it's prima facie evidence
that a vote was cast the particular way they claim they voted. Also they
can't prove who cast the vote, they can prove that it was a vote that
should have been counted.
DS
------------------------------
From: Stanley Chow <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
Date: Wed, 22 Nov 2000 00:56:42 GMT
David Schwartz wrote:
>
> 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.
It seems there are some terminology confusion here. There are several
distinct points:
1) the voter can tell if his vote is correctly counted
2) the voter can prove if his vote is incorrectly counted
3) 3rd party can force voter to reveal the vote
Note that 2) is pretty much the same as 3) in that there are lots of
scenarios involving corrupt official, revolutions, vote-buying, etc.
that turns 2) into 3). So if you claim 1) and 2), you are logically
claiming 3), which is objectionable to many people.
It is conceivable that 1) is useful in and of itself without 2). That
is, the voter would know, but cannot prove to anyone. Presumably, a
revolution would follow if enough people felt cheated. On the other
hand, one election is enough for a lot of mischef - there may not
even be another election.
--
Stanley Chow VP Engineering [EMAIL PROTECTED]
Cloakware Corp (613) 271-9446 x 223
------------------------------
From: "Brian McKeever" <[EMAIL PROTECTED]>
Subject: Re: Legal issues for hobbiests
Date: Tue, 21 Nov 2000 17:13:16 -0800
"Steve Portly" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> 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?
what about posting source code on the internet? Is this still ok? Is it
only
executables that are restricted?
Brian
------------------------------
From: [EMAIL PROTECTED] (Mack)
Date: 22 Nov 2000 01:15:41 GMT
Subject: Re: Legal issues for hobbiests
>Steve Portly" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> 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?
>
>what about posting source code on the internet? Is this still ok? Is it
>only
>executables that are restricted?
>
>Brian
>
It is a complicated mess ... executables are restricted more than
source code. Source code of publicly available algorithms is not
restricted only new algorithms.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
Date: Tue, 21 Nov 2000 17:15:37 -0800
Stanley Chow wrote:
> David Schwartz wrote:
> > 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.
> It seems there are some terminology confusion here. There are several
> distinct points:
> 1) the voter can tell if his vote is correctly counted
> 2) the voter can prove if his vote is incorrectly counted
> 3) 3rd party can force voter to reveal the vote
> Note that 2) is pretty much the same as 3) in that there are lots of
> scenarios involving corrupt official, revolutions, vote-buying, etc.
> that turns 2) into 3). So if you claim 1) and 2), you are logically
> claiming 3), which is objectionable to many people.
No, I think you can have both 1 and 2 without having 3. So either I'm
misunderstanding your argument, your argument is incorrect, or your
statement (or my understanding) of one of those three requirements is
wrong.
Consider a system where each voter has an ID but no voter can prove
which ID is his and no official can map an ID to a particular voter.
When you vote, you are given a receipt (which is also ultimately made
public) that proves that your ID voted for whichever candidate you
actually voted for.
When the election is complete, the list of voter IDs that voted for
each candidate is presented.
You have '1' because if you can check if your ID is on the correct list
and you know your ID.
You have '2' because you have a receipt that says that your ID voted
for your candidate. If it appears on the wrong list, presenting your
receipt demonstrates this error.
You don't have '3' because no third party could ever be sure you were
presenting your own receipt, as opposed to one some other voted made
public. If all receipts are made public after the election, you can
present anyone's receipt you choose -- that of literally any voter.
DS
------------------------------
Date: Tue, 21 Nov 2000 20:34:26 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Entropy paradox
Mok-Kong Shen wrote:
> This is a re-formulation of an issue that I questioned
> previously. Suppose one has m perfectly random bits and
> uses that in some appropriate way to get a BBS generator
> to generate u bits, with u >> m. We know that (accepting
> certain plausible assumptions) the u bits are provably
> secure.
This conclusion is invalid due to ambiguity in the phrase "provably
secure". In fact there is a sense of provable insecurity in that the
space of the output, u, can be searched in time proportional to 2^m
rather than 2^u.
> It seems thus that we have obtained more entropy
> that way, i.e. having obtained an amount of additional
> entropy from nothing.
Hardly. There is not even an increase in unpredictability. The size of
the initial state space is identical to the size of the final state
space: 2^m.
> How is this apparent paradox to be
> properly explained? (Or does each bit of the generated
> sequence have in average m/u bits of entropy?)
Exactly.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Q: fast block ciphers
Date: Wed, 22 Nov 2000 02:02:36 GMT
Tim Tyler wrote:
>
> 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.
There is still CTR and CFB...
Also, my other point, how to turn a stream cipher (eg Arc4, Panama) into
a block cipher, was not answered.
I would really love to see an example.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
** 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
******************************
