Cryptography-Digest Digest #68, Volume #12 Tue, 20 Jun 00 06:13:00 EDT
Contents:
Re: XOR versur MOD (Mok-Kong Shen)
Re: small subgroups in Blum Blum Shub (Mok-Kong Shen)
Re: small subgroups in Blum Blum Shub (lcs Mixmaster Remailer)
Re: Encryption on missing hard-drives ([EMAIL PROTECTED])
Re: Random sboxes... real info (Jack)
Re: salt length? (Mok-Kong Shen)
Re: Flattening of frequency distributions (Mok-Kong Shen)
Re: Encryption on missing hard-drives (Guy Macon)
Re: Forgot ZIP File password. ([EMAIL PROTECTED])
Re: obfuscating the RSA private key (Mack)
Re: XOR versur MOD (Mack)
Re: Newbie: germans please: field == Koerper ? (math) (Runu Knips)
Re: (somewhat OT) Non-US webhosting (Eric Hambuch)
Re: XOR versur MOD (Mack)
Re: Is this a HOAX or RSA is REALLY broken?!? (Arturo)
Re: Encryption on missing hard-drives (Mok-Kong Shen)
Re: Encryption on missing hard-drives (Mok-Kong Shen)
Re: Encryption on missing hard-drives (Mok-Kong Shen)
Re: New Hash Function (Runu Knips)
Re: oneway encryption for password (Runu Knips)
Re: small subgroups in Blum Blum Shub (Bryan Olson)
Re: RIP Bill 3rd Reading in Parliament TODAY 8th May (James Hammerton)
Variability of chaining modes of block ciphers (Mok-Kong Shen)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: XOR versur MOD
Date: Tue, 20 Jun 2000 09:26:24 +0200
"Tony T. Warnock" schrieb:
> The operands are in order, these are the result tables
>
> XOR for 2 bits ADD for 2 bits
> 00 01 10 11 00 01 10 11
> 01 00 11 10 01 10 11 00
> 10 11 00 01 10 11 00 01
> 11 10 01 11 11 00 01 10
>
> Each row and each column each table is a permutation of the
> corresponding row or column of the other table. Both tables are latin
> squares. For larger bit strings, the tables look even more different
> from each other.
I see that I misunderstood you. You mean in effect that a+x and a^x
generate the same set of values. However, I don't yet clearly see what
(practically essential) implications can be drawn from that. An analogy
would be comparing x and E(x), where E is a block encryption and
both x and E(X) generate the same set of values.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: small subgroups in Blum Blum Shub
Date: Tue, 20 Jun 2000 09:26:15 +0200
Terry Ritter wrote:
> Secret Squirrel <[EMAIL PROTECTED]> wrote:
> >If you cannot
> >respond with a mathematical argument, you should go away until you can.
> >You certainly should not be making unsupported technical claims purely
> >on the basis of what your imagination suggests is the motivation of
> >other researchers.
>
> And you have not been able to describe *your* position at all. Do you
> imagine that short cycles do or do not exist in BB&S constructions?
> Do you imagine that using such a cycle would be weak or not? Do you
> imagine that it is actually impossible for a short cycle to be
> selected? Or perhaps you simply missed the many times I have stated
> that -- as far as I know -- this is not a problem in practice. But it
> is a *theoretical* problem, and as such stands directly in the way of
> any serious claim of "proven security."
I am not sure but I have the impression that the presently very heated
dispute is somewhat analogous to a dispute over OTP. Person A
gets some hardware generated extremely high quality random bit
sequences and claims that his encryption is provably secure because
OTP is proved to be secure, while person B maintains that, because
the sequences obtained in practice must necessarily have some minute
deviations from what is assumed in the proof of OTP's security, A's
system is not provably secure.
M. K. Shen
------------------------------
Date: 20 Jun 2000 07:20:09 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: small subgroups in Blum Blum Shub
David Wagner wrote:
> In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
> > And you have not been able to describe *your* position at all. Do you
> > imagine that short cycles do or do not exist in BB&S constructions?
> > Do you imagine that using such a cycle would be weak or not? Do you
> > imagine that it is actually impossible for a short cycle to be
> > selected?
>
> I think it was already clear, but I'll answer your questions.
>
> Yes, short cycles exist in BB&S. Yes, using such a cycle would be weak.
> No, it is not impossible to encounter such a cycle. Yes, BB&S is provably
> secure (under appropriate assumptions and definitions). There is no
> contradiction here.
To expand on this:
The proof of security says this: if x_0 is chosen at random from among
quadratic residues, the BBS sequence starting from x_0 is as secure as
deciding quadratic reciduosity. This is the proof of security you get
with the BBS - no more, no less.
It doesn't say that the RNG is secure. It doesn't say that it can't
be predicted. What it says is, IF the RNG is insecure, IF it can
be predicted, THEN you can build an algorithm to decide quadratic
reciduosity. Effectively this is the same as saying that you can factor
RSA moduli of this form.
Your proof of security is essentially that if the RNG can be predicted,
you can factor the modulus. The informal proofs seen here apply to the
special case where you predict the RNG by finding a cycle. This is a
simpler case than what BBS consider, and the proof is elementary.
You can turn this proof around and say, if you believe that a given Blum
modulus is safe against factoring, then it follows that it is equally
safe against predicting the BBS sequence.
You get this proven security simply by choosing a Blum modulus and a
random starting point. That's all the proof requires.
This is why David says that BBS is provably secure, even though cycles
exist. It is because the proof of security, the equivalence to quadratic
reciduosity, is not affected by the presence of cycles.
Obviously if short cycles exist, you can predict the RNG. It follows
by the BBS proof, and the short demonstrations posted here, that you
can factor the modulus.
If you think you need to pick a special modulus to avoid short cycles,
that means that you think you need to pick a special modulus to avoid
it being factored. The two weaknesses are equivalent.
You cannot consistently advise people to choose special moduli for BBS
without advising them to choose those same moduli for RSA. And then
when you are asked to justify this advice with regard to RSA, there is
nothing you can say.
And your suggestion to choose the seed carefully is completely absurd.
Your opponent can choose his own seeds! If you have to be careful
picking your seed so that you don't accidentally get one with a short
cycle, the game is already lost. Your opponent can pick as many seeds
as he likes, and check all of them for cycles.
There is nothing you can do to strengthen your RNG by picking a special
seed, because your opponent is not limited to your choices. If you
think short cycles are a risk, then he could find a short cycle, factor
the modulus, and you have lost your security. You gain no benefits
whatsoever by carefully choosing a seed.
Obviously Terry Ritter is not going to be convinced by these arguments.
Years of frustrating debate have established that. The hope is that other
readers will come to a clearer understanding of exactly what proof of
security is provided by BBS. They will then see why such authoritative
references as RFC 1750 describe the RNG in its simple form, without
the elaborate additional checks and precautions which Terry Ritter has
claimed are necessary.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Encryption on missing hard-drives
Date: Tue, 20 Jun 2000 07:21:28 GMT
Guy Macon <[EMAIL PROTECTED]> wrote:
> There is a way, even if the slave drive method was used. I will put
> in a bit of scrolling now so you can try to think of it before reading
> my answer. It's clever, but a non technical person could think of it.
[clever answer deleted :]
I'm curious exactly what you would look for. In particular the
variation of the clever method I was thinking of would only work if
there had been writes to the disk. Are there clues that would be left
even if the bits were only read off? For the sake of argument, let's
discount bad sectors that may have been remapped during the reading,
as it's improbable they had such a good snapshot of the drive
beforehand.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Jack)
Subject: Re: Random sboxes... real info
Date: 20 Jun 2000 07:34:59 GMT
[EMAIL PROTECTED] (Joseph Ashwood) wrote in <es#udNm2$GA.347@cpmsnbbsa08>:
>> comes with compileable source code.
>
>I will only bother to address this one point. I once had the
>free time to download and attempt to compile your supposed
>source code. I attempted to compile it with (result):
>Win95/Borland (failed)
>Win95/MSVC 4(failed)
>WinNT x86/MSVC 5(failed)
>WinNT Alpha/MSVC 4 (failed)
>WinNT Alpha/MSVC 5 (failed)
>Solaris SPARC/ cc (failed)
>SunOS / cc (failed)
>Solaris/gcc (failed)
>Digital UNIX/cc (failed)
>Digital UNIX/gcc (failed)
>
>I think that list is complete enough to establish that you
>simply seem incapable of writing code that will compile, or
>if nothing else you didn't publish the same code you
>compiled. Would you care to try again?
> Joe
>
>
>
>
>
If you have ever been to my site the scott19u,zip
was designed in DJGPP which is a gnu C port to the pc.
it relies on the way x86 type of machines handle data.
It was not written for other machines. I did get copies
of scott16u from various people when I had a 486. I
am sure if you asked you could get versions that run
with other C compliers. Unix gcc is actaully what I use
to use a lot. It was only a few key routines such as entering
the passphrases invisably that you should have had trouble with.
The only C complier I presently have contact with is the DGJPP
copmplier. ITs free.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: salt length?
Date: Tue, 20 Jun 2000 09:53:40 +0200
"David A. Wagner" wrote:
> No, RC4 is a pseudo-random generator G : key |--> output, not a
> pseudo-random function F : (key,input) |--> output. As stated in my
> comments above, a pseudo-random generator is insufficient; you need a
> full pseudo-random function.
>
Couldn't one (certainly pedantically) argue that G can be employed
where F is used, since one can always use 'key||input' of F as 'key' of
G? (We disregard sizes of input arguments of the two.)
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Flattening of frequency distributions
Date: Tue, 20 Jun 2000 09:53:46 +0200
Guy Macon wrote:
> Mok-Kong Shen wrote:
>
> >Are you assuming that the compression algorithm is secret? If not,
> >and there is no secret key involved, then the opponent can decompress,
> >so that he is in the same situation as if no compression has been done.
>
> Getting down to practical matters, would using PKZIP with its
> know-to-really-suck encryption before using a Real Man's Cipher
> make the attackers job any harder?
My personal view about components of a encryption scheme is that
anything that requires the opponent to make a decision/guess can help
to defeat or delay analysis and is thus useful, though the (economic)
justification of employing any specific component is certainly dependent
on the application environment and not the least also on the more or
less subjective jugement of the system owner/users.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Encryption on missing hard-drives
Date: 20 Jun 2000 04:00:22 EDT
[EMAIL PROTECTED] wrote:
>
>
>Guy Macon <[EMAIL PROTECTED]> wrote:
>> There is a way, even if the slave drive method was used. I will put
>> in a bit of scrolling now so you can try to think of it before reading
>> my answer. It's clever, but a non technical person could think of it.
>
>[clever answer deleted :]
>
>I'm curious exactly what you would look for. In particular the
>variation of the clever method I was thinking of would only work if
>there had been writes to the disk. Are there clues that would be left
>even if the bits were only read off? For the sake of argument, let's
>discount bad sectors that may have been remapped during the reading,
>as it's improbable they had such a good snapshot of the drive
>beforehand.
>
(stop reading now if you want to try to guess cleve answer by yourself)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
You are missing the point. The clever method does not involve looking at
what's written on the disk. It doesn't even involve powering up the disk.
It involves looking at the pins on the disk drive connectors. When you
attach the cable, it causes microscopic scrtaches on the gold plating.
You can read them like you read scratches on a bullet from a gun barrel.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Forgot ZIP File password.
Date: Tue, 20 Jun 2000 07:56:17 GMT
In article <[EMAIL PROTECTED]>,
Pranshu Singhal <[EMAIL PROTECTED]> wrote:
> I encrypted a Win ZIP file and now after many weeks I am unable to
recall
> the
> password. I have tried many options which I thought possible but to
no use.
Try password recovery software from
http://passwordservice.com/officepsw.htm
There IS a password recovery tool for WinZip, it might be just what you
need.
best wishes,
Marc
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: obfuscating the RSA private key
Date: 20 Jun 2000 08:18:38 GMT
I am having a hard time following exactly what you want to do.
If you want to store the private key then encrypt it with a
conventional block cipher. If you want to use a recovery
scheme then all the parts of the key must be distributed
outside of the program. If you MUST store the key
within the program code or data there is no way
to guarantee security. Just how secure do you
need this to be?
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: XOR versur MOD
Date: 20 Jun 2000 08:36:39 GMT
[EMAIL PROTECTED] (Mark Wooding) wrote
A reallly good analysis of what I was talking about.
Thanks Mark.
The non-commutative properties of XOR and addition
are definitely important in RC5s security. But back to
the original topic which is whether XOR or addition is
better. I still say it depends on the cipher. And in the
RC5 case we need both.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
Date: Tue, 20 Jun 2000 10:35:41 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Newbie: germans please: field == Koerper ? (math)
Christof Paar wrote:
> Ja, "Field" translates into "Koerper". The translations for "Galois field"
> (und nicht Galouis :) is "endlicher Koerper". Note that "Galois
> fields" and "finite fields" are the same thing.
Aaaaah thank you ! :-)))))))
------------------------------
From: Eric Hambuch <[EMAIL PROTECTED]>
Subject: Re: (somewhat OT) Non-US webhosting
Date: Tue, 20 Jun 2000 10:50:26 +0200
Dido Sevilla wrote:
>
> It's kinda off-topic, but there is something I'd like to ask... Does
> anyone know of any free non-US webhosting service? I've implemented
> several encryption algorithms in 80186 assembly: putting the finishing
> touches on Serpent, have TEA, and an implementation of SHA-1 all ready
> now, and probably I'll try doing Rjindael after Serpent is finished. I
> don't want any stupid EAR or other idiotic laws to come back and bite me
> because I keep strong encryption programs on my web page. My ISP
> provides webhosting space, but it's pathetically small (1meg!)... As my
> sig implies, I'm not a US citizen, so the law's scope is questionable,
> but just to be on the safe side...
Try some free European ISPs:
http://www.tripod.de
http://tripod.lycos.com/international/
http://freehomepage.de/free/dateien/webspace.htm
or simply enter "free webspace homepage" into a search engine.
Eric
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: XOR versur MOD
Date: 20 Jun 2000 08:55:08 GMT
tomstd [EMAIL PROTECTED] wrote:
>
>No, again it's because the addition and xor does not commute
>through the rotation (see mod n analysis).
Yes the non-commutative nature of addition and xor
are important. My X8 series of ciphers used
a chaining function of addition and xor.
Mark wrote a good example of what I was talking about.
Highlighting the non-commutative property.
>
>Anyways, mixing add and xor is not a bad idea...
Again this depends on the design. Mixing is good if it
makes the cipher more secure. Of course DES did
just fine with XOR. And was easily reversible. And it worked
well in hardware. Of course not quite so good in software.
It never was the fastest cipher on the block.
>
>Tom
>
Sorry couldn't resist.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED]=NOSPAM (Arturo)
Subject: Re: Is this a HOAX or RSA is REALLY broken?!?
Date: Tue, 20 Jun 2000 07:50:18 GMT
On Mon, 19 Jun 2000 22:11:37 -0700, Roger Schlafly <[EMAIL PROTECTED]>
wrote:
>Adam Durana wrote:
>> that can do this yet. They merely said that quantum computers would be able
>> to break RSA. This isn't anything new. Everyone knows that quantum
>> computers will be very fast and be able to very quickly exhaust the
>> keyspaces that we consider secure by today's standards.
>
>Actually no one knows if such computers will ever be built.
>The optimists in the field believe that in 5 or 10 years
>it will be possible to build a quantum computer that can
>factor the number 4 as 2x2. RSA is still safe for a long time.
QC reminds me of the "artificial intelligence" debate back in the late
80s and early 90s. It was said that AI could make a computer do anything, from
surgical operations to star-wars battle management. And now? The few surviving
AIs are now called "expert systems", and they work fine but far from earlier
expectations. Are we putting again too much faith into a deus et machina?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Encryption on missing hard-drives
Date: Tue, 20 Jun 2000 11:23:02 +0200
"SCOTT19U.ZIP_GUY" wrote:
> Well as an X governemnt worker I would bet that the story that the
> data was encrypted is false. Also condsidering the locked bag had the
[snip]
All official statements in the world need to be taken with some grains
of salt. One can sometimes also never exclude the possibility that
stories are purposedly spun and spread by official organs as a
manoeuvre for achieving some hidden goals.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Encryption on missing hard-drives
Date: Tue, 20 Jun 2000 11:23:14 +0200
"John E. Kuslich" wrote:
> DO NOT BELIEVE anything you federal government says about national security!
Or insecurity. A government always attempts to convince its citizens
that big achievements have been made in national security through wise
expenditure of tax revenues and simultaneously that big insecurity remains
to justify collecting ever more tax revenues.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Encryption on missing hard-drives
Date: Tue, 20 Jun 2000 11:23:09 +0200
"Douglas A. Gwyn" wrote:
> Apparently some agencies don't pay enough attention to established
> security procedures, and that is the actual problem. Historically we
> have had this problem in various guises "forever".
Yes, much much more is needed for information security than simply
having strong (or even provably secure) encrytion algorithms. But
this entirely trivial truth seems never to come to the mind of many,
particularly among those who are very well paid.
M. K. Shen
------------------------------
Date: Tue, 20 Jun 2000 11:31:39 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: New Hash Function
tomstd wrote:
> Runu Knips <[EMAIL PROTECTED]> wrote:
> >You're right, and I was wrong.
> So I'm gonna sing the I was right song?
>
> Hehehe...What do you think of it though?
If your algorithm would have an obvious weakness it
would have surprised me. ;-)
The Feistel structure worked well against my attempts
to attack it. That damned thing remembers me of RC5,
but that didn't helped me much, the rotations are not
dynamic and there is no key to discover in a one way
hash function anyway.
These fixed rotations in F() destroy all informations
about the lower bits. There was already another
rotation in the initialisation of W[] which is also
evil for the attacker, just like the constant term
in the XOR. So, AFAICS, there is also no weakness.
I still think there might be a problem with parity.
You use XOR everywhere but when you store the results
of your Feistel loop. Damned, but I can't see a way
to use that property.
In short: I can't see any way to attack it. :) Why
can't you store the loop results with '=' instead of
'+=' or remove those ugly rotations ? ;-) However,
I would use addition instead of XOR in the
initialization of W[] so that parity doesn't slip
through.
------------------------------
Date: Tue, 20 Jun 2000 11:34:46 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: oneway encryption for password
John Savard wrote:
> My web site describes SHA-1; however, for passwords, it would
> generally be considered overkill. Using the password as a DES
> key to encrypt a constant value or a modified form of itself
> is probably sufficient for most applications.
Hmmm why overkill ? DES is hardly faster than SHA-1, isn't it ?
I would concanate a salt and the password and compute the one
way hash.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: small subgroups in Blum Blum Shub
Date: Tue, 20 Jun 2000 09:25:56 GMT
Mok-Kong Shen wrote:
> It would be fine if someone could show the theoretical
> underpinning
> of this.
Given a prime p, for each x in Z_p* (Z_n* is the
multiplicative group modulo n),
x^2 == (p-x)^2 mod p
(Using == to mean 'is congruent to).
No element other than x and p-x is a square root of x^2,
since for y to be a square root of x^2 we need,
p | x^2 - y^2
p | (x+y)(x-y)
(The verical bar reads "divides"). Since p is prime it has
to divide one of the factors (x+y) or (x-y), so the two
solution are y=x and y=p-x. Thus each (mod p) square has
exactly two square roots and half the elements of Z_p* are
squares, (usually called "quadratic residues") and half are
non-residues.
The multiplicative group mod p always has a generator, call
some generator x. The even powers of x are quadratic
residues, so the odd powers must be the non-residues.
Similarly, in the multiplicative group mod pq (distinct
primes) each quadratic residue x^2 has exactly four square
roots: x, pq-x, and the two unique elements a and b where a
is congruent to x mod p and to -x mod q, and b is vice-versa.
The quadratic residues mod pq are exactly those x that are
both quadratic residues modulo p and modulo q.
If a prime p is congruent to 3 mod 4, then negative one
(A.K.A. p-1) is never a mod p quadratic residue. Proof:
Consider a generator x, we know from Fermat that
x^(p-1) == 1, so x^((p-1)/2) is the other square root
of 1, which is -1, and that's an odd power of the
generator.
The product of a quadratic residue and a non-residue must be
a non-residue. Thus if p == 3 mod 4, exactly one of (x, -x)
is a mod p quadratic residue (for any x in Z_p*).
Blum integers are the product of two distinct primes both
congruent to 3 mod 4. Now look at a quadratic residue,
call it x^2, of pq, where pq is a Blum integer. The four
roots of x^2 are:
x
-x
a where a == x mod p and a == -x mod q
b where b == -x mod p and b == x mod q
These are the four combinations of x and -x, mod p and mod
q. Exactly one must be a residue of both p and q, and thus:
Exactly one of the four square roots of a quadratic
residue modulo a Blum integer is itself a quadratic
residue.
So Mark Wooding was correct when he wrote:
| within the subgroup of quadratic residues mod n
| where n is a Blum integer, the map x |-> x^2 is
| bijective.
If we start at a random point in Z_p*, we get a non-residue
3/4 of the time, and thus a tail of length one. After that
we're on the bijective map.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: James Hammerton <[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,uk.telecom
Subject: Re: RIP Bill 3rd Reading in Parliament TODAY 8th May
Date: 20 Jun 2000 10:40:11 +0100
Adrian Kennard <[EMAIL PROTECTED]> writes:
> Dave Howe wrote:
> >
> > In our last episode (<alt.security.pgp>[Wed, 31 May 2000 08:41:29
> > +0100]), George Edwards <[EMAIL PROTECTED]> said :
> > >How on earth can anyone prove that you HAVEN'T forgotten your key,
> > >unless you suvsequently use it? I see huge legal bills on this, all fees
> > >for the solicitors.
> > They don't have to - it is up to you to prove you have; *that* is what
> > is so worrying.....
>
> Proving you have forgotton a key *should* be easy though - surely.
>
> "Hmmm, nope, I cant remember it" - proved.
You have to prove you're not lying when you say that, which is well
impossible.
James
--
James Hammerton, Department of Computer Science, University College Dublin
WWW Pages: http://www.cs.ucd.ie/staff/jhammerton/
http://www.tardis.ed.ac.uk/~james
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Variability of chaining modes of block ciphers
Date: Tue, 20 Jun 2000 11:59:55 +0200
The most popular block chaining mode seems to be CBC.
There is also PBC which chains with plaintext blocks.
One can also accumulate the previous blocks for doing the
chaining and use plaintext as well as ciphertext for
chaining. (I used this in one of my own designs.) By
combinatorics this gives 8 variants. Obviously one can
also use modular addition instead of xor and do some
random rotations if one likes. I think that the variability
of chaining modes could be advantageousy exploited such
that the actual chanining mode used in a message has to be
guessed by the opponent, thus redering his task much more
difficult.
M. K. Shen
===========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
** 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
******************************
