Cryptography-Digest Digest #779, Volume #12 Tue, 26 Sep 00 16:13:01 EDT
Contents:
quantum cryptography over optical fibres ("David C. Barber")
Re: differnetials... (Mike Rosing)
Re: On block encrpytion processing with intermediate permutations (Mok-Kong Shen)
Re: On block encrpytion processing with intermediate permutations (Mok-Kong Shen)
Re: DES (Mok-Kong Shen)
Re: continuous functions and differential cryptanalysis (Mok-Kong Shen)
Re: A Different Kind of Quantum Computer (Bill Unruh)
Re: What make a cipher resistent to Differential Cryptanalysis? (Mok-Kong Shen)
Re: continuous functions and differential cryptanalysis (Tom St Denis)
Re: continuous functions and differential cryptanalysis (Tom St Denis)
Re: What am I missing? (Lon Willett)
Re: On block encrpytion processing with intermediate permutations (Bryan Olson)
Re: differnetials... (Tom St Denis)
Re: continuous functions and differential cryptanalysis (Tom St Denis)
Re: Why is TwoFish better than Blowfish? (Tom St Denis)
Re: On block encrpytion processing with intermediate permutations (Tom St Denis)
----------------------------------------------------------------------------
From: "David C. Barber" <[EMAIL PROTECTED]>
Subject: quantum cryptography over optical fibres
Date: Tue, 26 Sep 2000 10:14:12 -0700
An interesting news article about secure transmission using quantum
cryptography over optical fibres
http://www.theregister.co.uk/content/1/13536.html
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: differnetials...
Date: Tue, 26 Sep 2000 12:32:52 -0500
Tom St Denis wrote:
> Arrg... calculus is all new to me... please help!
You're mixing finite fields and continuous analytic numbers.
As my kids would say "that does not include". The idea behind
calculus is that you can "infinitly" divide things down very
smoothly. The idea behind finite fields is that every element
is distinct. A better way to combine these is thru p-adic
numbers. I'd suggest you keep finite field ideas completely
separate from calculus ideas, at least for a few months :-)
Follow the proof carefully for why d/dx ( 1/x) = 1/x^2. You
use limits. Can't do that with a finite field!!
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Tue, 26 Sep 2000 19:48:42 +0200
Tom St Denis wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > Bryan Olson wrote:
> >
> > > Tom is right; the diffusion is obviously terrible.
> > > Here's a first-cut at an attack strategy:
> > >
> > > In a typical Fiestel cipher one might have 16 rounds
> > > or 8 round-pairs. Let's use chosen messages of about a
> > > thousand blocks. We introduce differential pairs in
> > > which only one block input differs. There probably
> > > exists a left half-block for which any input
> > > differential survives to become an output differential.
> > > That happens if at each of the seven between-round
> > > permutations the differential goes into a left block
> > > and the right blocks are still constant.
> > >
> > > We can easilly detect the case when it happens; the
> > > differential put into the left half of input block
> > > 'i', appears as the differential comming out of the
> > > left half of ouput block 'j'. Now we can put
> > > differntial pairs into the right half of i, holding
> > > everything else constant, and the differential that
> > > comes out in the left half of j is exactly the
> > > differential from the right half of i going through
> > > the f function in the first round. For most Feistel
> > > ciphers that will expose the first round-key, and
> > > allow us to push to the next round.
> > >
> > > There are other opportunities to extract information
> > > based on the poor diffusion. As a rule of thumb,
> > > letting information out from intermediate rounds is
> > > extremely dangerous.
> >
> > Suppose each half is a word (e.g. DES), the permutation
> > is rendering each one of them to go to a different
> > location that is unknown to the opponent. I don't yet
> > see how he can 'follow' the individual halves as they
> > get processed in the different cycles in order to be
> > able to exploit differentials etc. He has a moving
> > target, so to say, and the motion is invisible.
>
> That's just it. If the blocks diffuse poorly things like differential
> cryptanalysis will work. I can send a huge msg in with specific
> differences. Then I watch to see which output halves have the required
> difference. Then I can guess which are involved...While this is not a
> concrete attack if you only use say 2-round DES in each step the
> differences will propagate for sure.
Let's first agree that we are arguing about what I call
the full version of my scheme. You compute the differences.
but do you know which differences correspond to which
word/block of the original plaintext? Note that, due to
the word (or groups of words) permutation, everything
has got mixed up in a way that the opponent can't find
out. Please kindly re-read my original post and forget
for the time being the last two paragraph and do a
sketch with pencil of how you would go about with your
differential analysis with, say, DES as block encryption
algorithm and a message of 20 blocks. I think that my
idea would then be clear to you. Note in particular that
you have no knowledge of the permutations that are being
done. There could be poor permutations. Let's assume
that 2 are poor but 14 are good.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Tue, 26 Sep 2000 19:48:34 +0200
Tom St Denis wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > Tom St Denis wrote:
> > > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> > > > I don't think so. If the message is large, the number
> > > > of the parts a, b, etc. become large. In that case
> > > > the chance of a pair remain sticking together at the
> > > > same location should be lower. If a block consists of
> > > > 4 words instead of 2 words, there would be a similar
> > > > favourable effect.
> > >
> > > No, My point was that not all halves would affect each other
> DIRECTLY.
> > > That is optimum diffusion.
> >
> > Certainly, since there are only m cycles but commonly
> > lots more halves (and words) in a message, it is
> > impossible that all halves (and words) of the message
> > have the chance to interact with all others through the
> > permutation operation during the time of the encryption
> > process. But there 'are' some interactions and these
> > are difficult for the opponent to exactly trace out.
> > That's the intended effect.
> >
> > > >
> > > > What would interest me is the question whether employing
> > > > permutation could in general be better than block chaining
> > > > or not. If not, then the scheme would have no value.
> >
> > > Ok Consider a 128-bit block cipher where I permute the 16 bytes then
> > > pass the clumps through a 16x16 sbox...
> > >
> > > There will be alot of weak permutes where the diffusion is not
> terribly
> > > high amongst all words.
> >
> > You are considering the scaled-down case. That might be
> > indeed poor, if the original block algorithm is well
> > designed. But for the proper scheme (not the scaled-down
> > one) and considering, say, DES, in each cycle of the
> > common DES, one half-block is used to transform another,
> > and vice versa. If the effect of these transformations
> > are very good, it seems to be intuitively clear that it
> > shouldn't matter much if the 'transformer' of a particular
> > half-block comes from elsewhere in the message rather
> > than from the partner of the block as it happens to be
> > in the original sequence of the plaintext. Any weakening
> > due to change of partners are more than compensated
> > by the complexity introduced by the permutation, I
> > suppose. Techniques like differential analysis would be
> > confounded in their proceedings, I believe. (The
> > locations of the halves are constantly changing in ways
> > unknown to the opponent.) If the block is large, say,
> > of 4 words, and you fear that tearing apart the 2 words
> > making up one operational entity (i.e. one half) of the
> > Feistel cipher could be disadvantageous (presumably
> > because the design has been tuned to that), then you
> > could also permute, instead of words as I described,
> > group of 2 words to maintain the integrity of the halves.
>
> What's the diff between my 16-bit sbox example and your 64-bit sbox
> (DES) example?
Let me say that my main proposal is for blocks of at
least two words and a message containing quite a number
of blocks. Therefore I permute the words, because these
are more efficient than permuting the bytes. Then, as
an after thought, I wanted to indicate that the same idea
could in principle (though not so good) be applied to
a single block (which would allow for easy hardware
implementation). Now, for a block of two words, there
is no sense of doing permutation of words. Hence, one
has to scale-down, using permutation of bytes (there
aren't many unfortunately for a block of two words).
So for the scaled-down version, the situation is
less favourable from the start. Now it is known or can
be assumed that a well-designed cipher like DES is
optimized by its author. So if I do some tweaking, as
is the case with the scaled-down version, the result
has apparently a fair chance of being poorer. That's
why I commented on the scaled-down version in the
previous post (quoted above). I don't clearly see what
your argument goes beyond what I said about it. (You
were commenting on the scaled-down version, right?)
Please note that it is the full version with permutation
of the words (or even half-blocks or blocks, with larger
block sizes, etc.) and sufficiently long messages that
is the main concern of my original post and I have said
about that also in what is quoted above. To more directly
answer your question above, I used the DES above to argue
for the full version. In the full version, since the
example is for DES, the block size is even smaller
than your 128 bits. But you were considering solely
a permutation 'within' that block, which corresponds to
the scaled-down version, not the full version. And
for the scaled-down version I have already said that
my scheme 'might indeed be poor'. Do you have now any
essential points to say concerning the topic here?
>
> > > Also the PRNG must be reseed'ed for each block otherwise you have a
> > > stream cipher, not a block cipher.... not terribly usefull since
> > > seeking is a benefit of block ciphers.
> >
> > There is no reseeding of the PRNG during the processing
> > of a message/session. If you like, you could call it a
> > combination of stream and block processing. I would
> > rather prefer the term 'huge' block processing. One can
> > consider the whole message as a virtual 'block'. There
> > are operations at that level and there are operations at
> > another level, namely the proper block operations,
> > during each cycle. (PRNG need not cause in mind
> > 'association' with stream encryptions. You could think
> > that there is a key (the seed) that generates a set of
> > key-dependent permutations that are subsequently used.
> > Compare key-dependent S-boxes.) Does the appearance
> > of a novel (it isn't novel, I used such combinations of
> > processing techniques in my humble designs) form of
> > encryption as such trouble you? Why? I don't understand
> > your last phrase. In particular I can't figure out the
> > meaning of the word 'seeking' in the present context.
> > Could you explain a bit? Thanks.
>
> By seeking I mean if I want to read say an encrypted mp3 and seek to a
> minute into it... I can't do that. This protocal is only good if the
> entire file/msg is available at once to load and provided it's not too
> big.
The scheme intentionally does a whole-file processing
in order to avoid the opponent being able to easily
concentrate his effort on a tiny part. (Compare also
the all-or-nothing schemes.) Now, you always have
trade-offs. You can't eat a pie and have it too. You
cannot satify all different kinds of desires that
are good in all kinds of environments. What can be
used/justified depends on the environment present.
You want to be able to decrpyt block by block. That
certainly runs contrary to what I provide. Now, what
you call the advantage of block cipher could, in
exactly the same fashion, also be considered a
disadvantage. For a block of 64 bits, you have to
wait till there are 64 bits. But there are applications
where one may need to send upon availability of any
number of bits, even a single bitl. That can be
satisfied by a stream cipher that does e.g. on the
basis of bit xor-ing. In 'simulation' of your argument
I could claim that bit processing is a benefit of stream
ciphers and block ciphers are hence bad, couldn't I? Do
you see my point?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: DES
Date: Tue, 26 Sep 2000 20:02:36 +0200
[EMAIL PROTECTED] wrote:
> I am looking for a C implementation of DES to try to see how it works
> in practice and eventually, i have to come up with a HC05 assembler
> version of DES.
>
> Has anyone got any suggestions on how i should approach the assembler
> implementation?
A C code for DES is included in the book of Schneier.
If you are a VERY good assembler programmer (and hence
already know the 'approaches' you were asking), then you
could try to translate that to assembler. Otherwise,
it is common 'wisdom' in modern software engineering
that you, for doing such translations, would loose
much time doing debugging and the end result probably
doesn't run significantly faster at all. Trying to
get a good compiler is the normal way recommended.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: continuous functions and differential cryptanalysis
Date: Tue, 26 Sep 2000 20:30:21 +0200
Mika R S Kojo wrote:
>
> Derivative is well-defined for any field, but its usually called
> "formal derivative". It is even possible to talk about continuous
> functions, but for for this you need p-adic numbers.
Dumb question: Are p-adic numbers inside the theory of
GF or else at least compatible with it? If yes, could
you please provide references? Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: A Different Kind of Quantum Computer
Date: 26 Sep 2000 18:16:35 GMT
In <[EMAIL PROTECTED]> "A. Melon"
<[EMAIL PROTECTED]> writes:
>Quantum computers can only solve problems in BQP, which is not thought to include
>NP-complete problems. Now there is a new type of quantum computer being proposed:
>http://xxx.lanl.gov/abs/quant-ph/9910073
I would not worry about it. I do not believe it.
I suspect some referees do not as well-- note the revision history of
the paper.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: What make a cipher resistent to Differential Cryptanalysis?
Date: Tue, 26 Sep 2000 20:36:04 +0200
Tom St Denis wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> >
> > Tom St Denis wrote:
> > >
> >
> > > Ah, but something can be pratically random. Take the output of say
> RC4
> > > that is hashed (gather 30 bytes then hash it via SHA-1, etc...) I
> would
> > > bet 10 bucks that without knowing the RC4 seed you couldn't guess
> the
> > > output better then 1/2.
> > >
> > > Make the RC4 seed 256 bits long ... and voila.
> > >
> > > Of course how do you make a random RC4 seed? recursive problem...
> >
> > I am really confused. Aren't we discussing the 'ideal'
> > OTP that requires (theoretical) perfect randomness
> > all the time? Why here 'practical' randomness at all??
>
> That's just it. If you can't practically guess the output, isn't it
> effectively random?
>
> Random is not a point in uncertainty, it's a state of it. If something
> is random to you, that means you can study it to guess the next output
> with any success better then the standard distribution. (1/p ...).
>
> Universal randomness as people want to see it CANNOT EXIST. It's
> impossible for something to be totally random. But it's possible for
> me to take some americium and make a rng that you can't guess. Is that
> not random?
That is NOT the randomness underlying an ideal OTP and
I was arguing with someone else about ideal OTP's
exsistence in practice. If you want to join that
discussion, then please keep in mind that context
and do not 'deviate' to other related topics, whatever
important these appear to be important to you!
M. K. Shen
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: continuous functions and differential cryptanalysis
Date: Tue, 26 Sep 2000 18:42:31 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> Mika R S Kojo wrote:
> >
> > Derivative is well-defined for any field, but its usually called
> > "formal derivative". It is even possible to talk about continuous
> > functions, but for for this you need p-adic numbers.
>
> Dumb question: Are p-adic numbers inside the theory of
> GF or else at least compatible with it? If yes, could
> you please provide references? Thanks.
I can top that, what are p-adic numbers?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: continuous functions and differential cryptanalysis
Date: Tue, 26 Sep 2000 18:42:09 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> Mika R S Kojo wrote:
> >
> > Derivative is well-defined for any field, but its usually called
> > "formal derivative". It is even possible to talk about continuous
> > functions, but for for this you need p-adic numbers.
>
> Dumb question: Are p-adic numbers inside the theory of
> GF or else at least compatible with it? If yes, could
> you please provide references? Thanks.
I can top that, what are p-adic numbers?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Lon Willett <[EMAIL PROTECTED]>
Subject: Re: What am I missing?
Date: Tue, 26 Sep 2000 15:35:11 GMT
In article <8qnvlm$k41$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Scott Craver) wrote:
> Lon Willett <[EMAIL PROTECTED]> wrote:
> >[EMAIL PROTECTED] (Scott Craver) wrote:
> >>
> >> That doesn't matter. There are some operations that SHOULD
> >> NOT be undone by a compressor, even if they COULD.
> >
> >Not actually true, in theory.
>
> Oh, I disagree wholeheartedly. The reason that these certain
> operations should not be undone by a compressor is that in only
> in SOME cases are they allowable.
>
[snip examples of "off limits for compressors" manipulations]
Keeping in mind that I'm only talking theory, not practice, your
examples are all flawed. If something is OK for your watermarking
scheme to do, then it is OK for my magical super-AI compressor to
remove the viewable/audible redundancy. But this really is a tangent,
since I don't expect to see the magical super-AI compressor in my
lifetime. Pragmatically you are right; it is only in a pure
information-theoretical sense that you are wrong.
The best you can do (from an information theoretic sense) is to find a
set of modifications from which only a "few" (i.e. a relatively small
number) can be applied without distorting the content. See below for
a more precise treatment of this.
[snip]
> >In theory, it can be made very difficult indeed to detect a watermark
> >by looking at the raw data alone
[snip]
> >Assuming that the crypto isn't flawed, and that the watermarking has
> >a sequence of bits that it can play with whose distribution is
> >"effectively" random with a known distribution, and that those bits
> >aren't destroyed by a compression algorithm, then you can indeed
> >watermark effectively.
>
> Indeed.
>
> >But reverse-engineering of the scheme need only be done _once_ by
> >_one_person_, and the whole thing is dead.
>
> But this is true for anything. RSA need only be cracked
> once by one person. That doesn't mean it will be done, or
> should not be trusted.
RSA doesn't need to be reverse-engineered. It is known. Its security
rests on keeping secret a private key that is sufficiently difficult
to crack. And if you want to produce and distribute millions of
consumer devices, all containing some particular RSA private key that
is supposed to be kept secret, then I would say the same thing.
Someone will manage to take apart those devices and find out what the
key is. Or discover some sort of side-channel attack on the devices
that reveals the key.
As far as I can see, if you really want a watermarking scheme that is
secure from this style of cracking (i.e. for which even knowing how to
detect watermarks isn't enough to be able to remove them), then you
need to find a solution to the following problem (as well as the
technical problems of reducing your actual data down to something that
fits this model; in practice, it probably won't cleanly break into
these two parts):
For some data-length "n" and acceptable distortion limit "m" (n
and m are counts of number of bits), then for any random data D
composed of "n" bits, you have at the watermarking source a
function "mark" s.t. mark(D) and D differ by no more than "m"
bits. (The function "mark" can be secret, although the scheme is
obviously better if it doesn't help your adversary if he knows it).
The devices that check for the watermark have a function
"is_marked" (which is publicly known) s.t.
(i) is_marked(mark(D)) is true.
(ii) is_marked(D) has a _very_ low probability of being true.
and
(iii) It is cryptographically hard, given mark(D), to find a
D' that differs from mark(D) in m or fewer bits and does not
satisify is_marked(D').
With, of course, the corollary:
(iii') is_marked(distort(mark(D))) has a _very_ low
probability of being false, where distort() is a function that
flips up to "m" random bits of its input.
Off the type of my head, this looks impossible; requirements (ii) and
(iii') seem to be working directly contrary to each other. Am I
mistaken? Has someone solved this problem? It seems more likely that
a little thought might show that this is impossible (I'm writing off
the top of my head; so I haven't even tried to think it through).
So, assuming that the above problem hasn't been solved, any
watermarking scheme is going to rely on keeping the "is_marked"
function (or equivalent) secret. And while there probably are
applications where such schemes can be useful, it is stupid to try to
put them in consumer items. Because the "is_marked" function will not
remain secret for long. One may as well skip all the sophisticated
stuff, and just include a "do not copy me" mark in the clear.
"Hackers" will of course, just remove it. But people who don't bother
bypassing the built-in hardware/software still won't be able to copy
it. Same effect. Much easier and more sensible implementation (at
least a bit more sensible, still not great).
(BTW, being a old time "hacker", I don't like using the word in this
sense, but oh well, the popular media wins again).
[ snip ]
> >Trying to artificially control the technology
> >("this program is illegal to possess") will probably do far more harm
> >than good in the long wrong.
>
> I like that, the "long wrong." In fact, many have asked this
Oops. Brain crash while editing. :-)
Cheers,
Lon Willett <[EMAIL PROTECTED]>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Tue, 26 Sep 2000 17:55:47 GMT
Mok-Kong Shen wrote:
> Suppose each half is a word (e.g. DES), the permutation
> is rendering each one of them to go to a different
> location that is unknown to the opponent. I don't yet
> see how he can 'follow' the individual halves as they
> get processed in the different cycles in order to be
> able to exploit differentials etc.
No need to follow the path. Just recognize that when
all other input blocks are held constant, the input
differential on block i always becomes the final output
differential on block j.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: differnetials...
Date: Tue, 26 Sep 2000 17:58:19 GMT
In article <[EMAIL PROTECTED]>,
Mike Rosing <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> > Arrg... calculus is all new to me... please help!
>
> You're mixing finite fields and continuous analytic numbers.
> As my kids would say "that does not include". The idea behind
> calculus is that you can "infinitly" divide things down very
> smoothly. The idea behind finite fields is that every element
> is distinct. A better way to combine these is thru p-adic
> numbers. I'd suggest you keep finite field ideas completely
> separate from calculus ideas, at least for a few months :-)
>
> Follow the proof carefully for why d/dx ( 1/x) = 1/x^2. You
> use limits. Can't do that with a finite field!!
Gotcha actually... hehehe
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: continuous functions and differential cryptanalysis
Date: Tue, 26 Sep 2000 18:42:09 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> Mika R S Kojo wrote:
> >
> > Derivative is well-defined for any field, but its usually called
> > "formal derivative". It is even possible to talk about continuous
> > functions, but for for this you need p-adic numbers.
>
> Dumb question: Are p-adic numbers inside the theory of
> GF or else at least compatible with it? If yes, could
> you please provide references? Thanks.
I can top that, what are p-adic numbers?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Why is TwoFish better than Blowfish?
Date: Tue, 26 Sep 2000 17:59:41 GMT
In article <[EMAIL PROTECTED]>,
Eric Lee Green <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> > Why? I know the NSA broke Scottu19 which is why he totes it so
much.
> > Oh proof? Um left that in my other pants... hehehehe
> >
> > His posts are funny if not completely useless....
>
> In other words, scottu19 is a NSA plant who is here in order to cast
doubt on
> secure algorithms, right? And the NSA funded the development of
scott19u, who
> is actually an artificial intelligence that only simulates being a
person?
>
> Tom promises to fax me the evidence shortly :-).
Shhhh. they might hear you.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Tue, 26 Sep 2000 18:02:52 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Let me say that my main proposal is for blocks of at
> least two words and a message containing quite a number
> of blocks. Therefore I permute the words, because these
> are more efficient than permuting the bytes. Then, as
> an after thought, I wanted to indicate that the same idea
> could in principle (though not so good) be applied to
> a single block (which would allow for easy hardware
> implementation). Now, for a block of two words, there
> is no sense of doing permutation of words. Hence, one
> has to scale-down, using permutation of bytes (there
> aren't many unfortunately for a block of two words).
> So for the scaled-down version, the situation is
> less favourable from the start. Now it is known or can
> be assumed that a well-designed cipher like DES is
> optimized by its author. So if I do some tweaking, as
> is the case with the scaled-down version, the result
> has apparently a fair chance of being poorer. That's
> why I commented on the scaled-down version in the
> previous post (quoted above). I don't clearly see what
> your argument goes beyond what I said about it. (You
> were commenting on the scaled-down version, right?)
> Please note that it is the full version with permutation
> of the words (or even half-blocks or blocks, with larger
> block sizes, etc.) and sufficiently long messages that
> is the main concern of my original post and I have said
> about that also in what is quoted above. To more directly
> answer your question above, I used the DES above to argue
> for the full version. In the full version, since the
> example is for DES, the block size is even smaller
> than your 128 bits. But you were considering solely
> a permutation 'within' that block, which corresponds to
> the scaled-down version, not the full version. And
> for the scaled-down version I have already said that
> my scheme 'might indeed be poor'. Do you have now any
> essential points to say concerning the topic here?
Again what is the difference fundamentaly from a "byte" or "block". If
you have 16 blocks or bytes the idea is just the same. Of course I
picked 16 out of the blue, but I find things easier to think of in
terms of their fundemental parts, i.e sbox, linear function, etc...
Tom
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
******************************
