Cryptography-Digest Digest #160, Volume #12 Tue, 4 Jul 00 18:13:00 EDT
Contents:
Re: A thought on OTPs (David A Molnar)
Re: sliding window exp.:CLNW vs. VLNW (Anton Stiglic)
Re: RC4 question ("Joseph Ashwood")
Re: one time passwords and RADIUS ("Joseph Ashwood")
Re: Help programming ("Joseph Ashwood")
Re: Crypto Contest: CHUTZPAH... ("Paul Pires")
Re: Hashing Function (not cryptographically secure) (Simon Johnson)
Happy 4th (JPeschel)
Re: RC4 question ("Paul Pires")
AONT (Benjamin Goldberg)
Re: Diffie Hellman Primes : Speed Tradeoff Q (David Hopwood)
Re: Crypto Contest: CHUTZPAH... (David A. Wagner)
Hash and Entropy (Future Beacon)
Re: A simple all-or-nothing transform (David Hopwood)
----------------------------------------------------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: A thought on OTPs
Date: 4 Jul 2000 19:22:07 GMT
Guy Macon <[EMAIL PROTECTED]> wrote:
> Of couse I can't give provable <smile> answers about what impression
Heh. :)
> wordings will make, but to me, it seems like "secure" implies resistance
> to attacks other than codebreaking. As far as the assumption that the
Ok. We have different intuitions about what "secure" and
"unbreakable" mean, then. I wouldn't make the distinction.
All the more reason to define terms and all that.
> key is truly random goes, that seems to me to be an issue for those who
> have strong opinions about whether true randomness exists, not for a
> lay person who is recieving an explaination about why an OTP cannot
> be broken through cryptanalysis. I would skim by such important
> concepts as "random", "XOR", "one time" etc. when explaining it to
> the lay person. Too much detail.
Agreed, assuming that the person isn't about to stake something major
on using a OTP...
-David
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: sliding window exp.:CLNW vs. VLNW
Date: Tue, 04 Jul 2000 16:10:34 -0400
I obvisously made a mistake in my example.
the CLNW partition should give
10110 11100 0000 10011 0000 10110 0
which gives 4 non zero blocks (not 5), and thus
no advantage from VNLW.
Sorry for the mistake
Anton
> 10110 11100 00001 00110 00010 1100
> can be put into blocks using CLNW, with block
size d = 5, this way
> 11100 11100 0000 10011 00001 01100 (5 non zero
blocks)
>
> but with VNLW you can get
> 1011 0 111 000000 10011 0000 1011 (4 non zero
blocks)
>
> So there is an improvement.
>
> Anton
>
> >
> > Thanks
> >
> > [1] - Cetin Kaya Koc, "High Speed RSA
Implementation", RSA Labs.
> > [2] - Cetin Kaya Koc, "Analysis of sliding
window techniques for
> > exponentiation", ???
>
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: RC4 question
Date: Tue, 4 Jul 2000 13:13:12 -0700
Unfortunately, doing that would open some avenues for a
chosen-plaintext attack, by giving an attacker the ability
to influence the likelihood of each output value. I would
recommend against it, but the CipherSabre idea presented by
someone else remains quite good. Oh and don't forget to
prime the pRNG by first removing several values from the
beginning (512 is certainly sufficient).
Joe
"dexMilano" <[EMAIL PROTECTED]> wrote in message
news:8jse4j$5m6$[EMAIL PROTECTED]...
> I know that the strenght level of RC4 is considered very
good because
> of the key preparation.
>
> I've thought to enforce it using a variant of CFB (Cipher
feedback).
> I mean that the Nth character is shifted of M position
depending on the
> n-1 ciphered character.
>
> With this shifting the code-resulting of the character
depends on the
> previous sequnces. SO its more difficult an attack based
on frequency.
>
> What do you think of this idea?
>
> dex
>
> In article <uY1sV0Y5$GA.279@cpmsnbbsa07>,
> "Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
> > That's correct. This is because all RC4 does is create a
> > pseudo-random pad, which is then XORed with plaintext at
a
> > later time (with no plaintext/ciphertext dependancy).
> > Joe
> >
> > "dexMilano" <[EMAIL PROTECTED]> wrote in message
> > news:8js32m$t7j$[EMAIL PROTECTED]...
> > > A silly question.
> > >
> > > I've tried the implementation of RC4 you can find on
the
> > web.
> > > Is it correct the felling that the same sequence of
bits
> > in the same
> > > position, with the same key, is coded in the same way,
> > indipendently
> > > form the previos bit sequences.
> > >
> > > I mean that, if yuo have to code gufy and pufy, the
cript
> > version shold
> > > be something like 1234 and 9234.
> > >
> > > (I hope the example is clear)
> > >
> > > thx
> > >
> > > dex
> > >
> > >
> > > Sent via Deja.com http://www.deja.com/
> > > Before you buy.
> >
> >
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: one time passwords and RADIUS
Date: Tue, 4 Jul 2000 13:24:51 -0700
A sensible attack on the card would be carried out a bit
differently in my opinion, and would in fact not involve the
server at all. It would be much more reasonable to record a
long series of outputs with their associated time, and
perform a known-time analysis, with knowledge of the
algorithm. There is really no telling if the algorithm is
secure against a significant attack, a good counterexample
would be if one were to take the time concatenate the
secret, run that through SHA-1, and take the lower 8 bytes,
most of us would agree that this would be difficult to
break, and that your best bet would be through a birthday
paradox exploiting attack. However I doubt that the SecurID
card was designed with such a strong algorithm in mind, it
is probably an actual encryption algorithm, using the secret
as the key, and the time as the plaintext. It's safe to
assume that the secret is no larger than 64-bits, making it
brute-forcable. There are probably attacks against it that
will be much more effective than brute force, but the
secrecy of the algorithm, combined with the security of
hardware makes it difficult to analyze. For reference I
would refer everyone to the analysis of the clipper chip
that was performed before the algorithm was made public
(limited to little more than disabling the LEAF), and the
analysis done afterwards, leading to significant analysis.
Joe
"greuh" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Thanks for this quick answer, you confirmed my personal
feeling
> about this device. I have been keeping looking for docs in
the
> scope of my problem until I found a paper about
Differential
> Power Analysis (http://www.cryptography.com/dpa/) and I
fear
> such a device could be vulnerable against this kind of
attack
> (at least it would probably help finding the algorithm
used in
> the card's chip, allowing a more serious cryptanalysis
later on).
> I am still bothered by the fact this device could be weak
> against a brute force attack. Is a 8-digit password with a
60-
> second long lifetime strong against "bruteforcing" ?
(unless the
> RADIUS protocol provides a solution against this risk,
such as
> allowing only three authentication tries)
>
> See you soon,
>
> Greuh
>
>
> ----------------------------------------------------------
-
>
> Got questions? Get answers over the phone at Keen.com.
> Up to 100 minutes free!
> http://www.keen.com
>
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Help programming
Date: Tue, 4 Jul 2000 13:36:28 -0700
It may be a good idea, it may be a bad idea. If the pictures
to be used are in the public domain (as opposed to being
completely secret and held only by the n parties involved)
then the security is certainly not very good, I don't even
have to look around to tell know that most websites house
fewer than 2^32 (~4000000000) pictures, and under IPv4 there
can be only 2^32 ip addresses, under these constraints, I
can tell you quite certainly that there are fewer than 2^64
(~16000000000000000000) pictures available, you can offer no
more than 64-bits of security with publically available
pictures, this is a problem since we currently consider
anything under 80-bits to be too small to be usable.
Joe
<[EMAIL PROTECTED]> wrote in message
news:8jt6ss$mlg$[EMAIL PROTECTED]...
> I have an idea for an encryption that takes one file to
encrypt
> another. So the key is the would be 3 pic files and each
byte of the
> pics would change the file to be encrypted. I have work
out an
> algorithm. And could use a lot of help to turn it into
code. Is
> their any other programs like this or am I wasting my
time?
>
> Duey
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Crypto Contest: CHUTZPAH...
Date: Tue, 4 Jul 2000 13:42:23 -0700
David A. Wagner <[EMAIL PROTECTED]> wrote in message
news:8jt831$cgt$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>,
> Boris Kazak <[EMAIL PROTECTED]> wrote:
> > While I understand the practicality
> > of "known-plaintext" and even "chosen-plaintext" attack, the very
> > concept of "chosen-ciphertext" strikes me as devoid of reason.
> >
> > Really, if you have access to the decryption engine loaded with the
> > proper key, you can just choose your ciphertext to be the message under
> > investigation, get the decrypted plaintext and go away [...]
>
> But the same argument `shows' that chosen-plaintext attacks are also
> just as devoid of reason! So, this should be a giant hint that you've
> made a mistake in your reasoning.
>
> What you're missing is that the threat model may be more complicated
> than you described. More likely is a `lunchtime' attack:
> An insider gains temporary access to the encryption or decryption
> engine, but only over lunchtime (say), and he'd like to be able to
> exploit this to recover encrypted traffic that may be sent in the
> future (after his lunch break is over, i.e., after he loses access
> to the device).
I think I have a grip on why chosen-ciphertext or known-plaintext
attacks are valid but it seems that there is something unspoken here.
Boris's comment is valid that the attack mentioned is meaningless if it
recovers the associated plaintext since by definition, you already have that
power through loss of physical security.
It seems to me that the break that these attacks provide is knowledge of
the key used or some other ability to read other messages or blocks that
could not be read directly from the attack. Am I missing something?
Back on point, I don't see how this attack is applicable here since Boris
did not show (as yet) how this information gained aids in recovering a
working key or other plaintext blocks. It may be obvious to you guys but I
haven't seen the light.
It is relevent since this is the reason that I posted this thing in the
first place. I think I have a way to encrypt in this way so that the key
cannot be recovered from known plaintext-ciphertext pairs. I erroneously
considered known-plaintext a worst case scenario and neglected
chosen-ciphertext but I still don't see how this attack yeilds the attacker
any more information or ability than he had before the attack was launched.
I am not trying to be thick-headed here, I just want to understand.
Paul
> If he has access to the encryption engine, a chosen-plaintext attack
> allows the adversary to learn the key using his lunchtime access and
> then decrypt all future traffic; if he has access to the decryption
> engine, it's chosen-ciphertext attacks which are dangerous.
>
> Personally, my experience is that chosen ciphertexts are often _easier_
> to obtain than chosen plaintexts, so chosen-ciphertext attacks should
> be even more of a concern (in practice) than chosen-plaintext attacks.
>
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Hashing Function (not cryptographically secure)
Date: Tue, 04 Jul 2000 20:44:29 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mack) wrote:
> Benjamin Goldberg [EMAIL PROTECTED] wrote:
>
> >Scott Fluhrer wrote:
> >>
> >> Benjamin Goldberg <[EMAIL PROTECTED]> wrote in message
> >> news:[EMAIL PROTECTED]...
> >> > Simon Johnson wrote:
> >> > [snip]
> >> > >
> >> > > Padding: if (length of message) mod 64 != 0 then message =
> >> > > message & length of document & trailing 0's (to make: len
> >> > > (message) mod 64 = 0)
> >> > >
> >> > > Hashing: for the 0 to i blocks: Hash = block[0] XOR block[1]
> >> > > XOR........ block[i]
> >> > >
> >> > > Any suggestion for this check digit system?
> >> >
> >> > It's bad ... don't use it; use a 64-bit CRC instead. With an N-
bit
> >> > crc, if two messages differ by N bits or fewer, they will
*always*
> >> > have different CRC values. With your method, suppose I have 60
> >> > 64-bit blocks, and I use your hash function... If I change the
last
> >> > bit in all those blocks, the hash remains the same. If I uses
> >> > CRC64, changing the last bit in all 60 blocks will result in a
> >> > different result.
> >> Actually, a N-bit CRC has the property that the CRC's of two
messages
> >> differ if the bit differences are confined to an area at most N
bits
> >> in length.
> >> His hash has precisely that property, and in retrospect, it's not
> >> surprising: the last step is essentially a 64-bit CRC with the
> >> polynomial x**64 + 1 (!).
> >
> >I'm not so sure of the accuracy of your description of what an N-bit
CRC
> >does... I challenge you to find two messages that differ by 2 bits,
> >with more than 16 bits between the differing bits, but which have the
> >same CRC16 value.
> >
>
> Since the CRC-16 and CRC-CCITT (0x11005 & 0x11021) both detect all
> 2 bit changes that is impossible.
>
> The code described is a CRC-64 with a bad polynomial. A simple
> 64 bit checksum would probably work a little better ie. use addition
> mod 2^64 instead of mod 2. Speed for software would be the same.
>
> The description of the function of CRC is accurate. A CRC will detect
> all changes confined to one block that is shorter than the CRC. But
> a good CRC will detect other errors better. ie 2 bit changes.
>
> Some CRCs are better than others even among the 'good' ie. primitive
> polynomials.
>
> Mack
> Remove njunk123 from name to reply by e-mail
>
Sorry for this newbie question; but, what is a CRC?
--
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] (JPeschel)
Subject: Happy 4th
Date: 04 Jul 2000 20:52:29 GMT
Happy 4th of July
http://www.debsfunpages.com/4th1.htm
Joe
(A Yankee Doodle Boy, at least once a year.)
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: RC4 question
Date: Tue, 4 Jul 2000 13:57:57 -0700
I had the same question and the answer I got was that you never re-enter the
key stream. i.e. originator and respondent don't re-key the cipher. party A
sends "gufy" using four states out of the cipher and party B responds with
"pufy" encrypted with the next four. The key stream is treated like an OTP
and you never re-use a portion of the keystream. I saw a protocol for using
RC4 this way and dealing with lost packets or packets received out of order
I think it was called "ESP" or "ESC". I'd have to dig to find it.
Makes sense to me.
Paul
dexMilano <[EMAIL PROTECTED]> wrote in message
news:8jse4j$5m6$[EMAIL PROTECTED]...
> I know that the strenght level of RC4 is considered very good because
> of the key preparation.
>
> I've thought to enforce it using a variant of CFB (Cipher feedback).
> I mean that the Nth character is shifted of M position depending on the
> n-1 ciphered character.
>
> With this shifting the code-resulting of the character depends on the
> previous sequnces. SO its more difficult an attack based on frequency.
>
> What do you think of this idea?
>
> dex
>
> In article <uY1sV0Y5$GA.279@cpmsnbbsa07>,
> "Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
> > That's correct. This is because all RC4 does is create a
> > pseudo-random pad, which is then XORed with plaintext at a
> > later time (with no plaintext/ciphertext dependancy).
> > Joe
> >
> > "dexMilano" <[EMAIL PROTECTED]> wrote in message
> > news:8js32m$t7j$[EMAIL PROTECTED]...
> > > A silly question.
> > >
> > > I've tried the implementation of RC4 you can find on the
> > web.
> > > Is it correct the felling that the same sequence of bits
> > in the same
> > > position, with the same key, is coded in the same way,
> > indipendently
> > > form the previos bit sequences.
> > >
> > > I mean that, if yuo have to code gufy and pufy, the cript
> > version shold
> > > be something like 1234 and 9234.
> > >
> > > (I hope the example is clear)
> > >
> > > thx
> > >
> > > dex
> > >
> > >
> > > Sent via Deja.com http://www.deja.com/
> > > Before you buy.
> >
> >
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: AONT
Date: Tue, 04 Jul 2000 21:21:02 GMT
What do you people think of the following all-or-nothing-transform
[good, bad, ugly?]
Start with a hash function H, which outputs N bits.
Partition the file into M N-bit blocks [it's ok if the last block is
short, but not-ok if the file is less-than one block]
To transform:
for i = 1 to M
// hash of all the data before and after block i
Z = H( data[1..(i-1)], data[(i+1)..M] )
data[i] = data[i] XOR Z
end for
To detransform:
for i = M to 1
// hash of all the data before and after block i
Z = H( data[1..(i-1)], data[(i+1)..M] )
data[i] = data[i] XOR Z
end for
Speedwise, it's bad -- O(M**2) -- but how good is it otherwise?
------------------------------
Date: Tue, 04 Jul 2000 17:48:00 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Diffie Hellman Primes : Speed Tradeoff Q
=====BEGIN PGP SIGNED MESSAGE=====
Mark Wooding wrote:
> Anton Stiglic <[EMAIL PROTECTED]> wrote:
[re: DH parameter generation]
> > you want a strong prime p = 2q + 1 in DH for different reasons,
>
> I'm aware that it's a good idea to work in a subgroup with prime order,
> since this defeats attacks whereby the adversary takes advantage of
> possible subgroups with smooth composite orders. Is there a further
> benefit to
>
> > you also want to work in the subgroup of size q
>
> Most definitely.
Ideally yes, although it's worth pointing out that when p = 2q + 1 for
q prime, there's no reason to believe that working in the whole group of
size 2q is less secure in practice. In that case the least significant
bit of the private exponent can be determined from the DH result, but
that doesn't matter because:
a) the DH result should only be used via a one-way hash or PRF, so
it will remain secret even if the session keys are broken,
b) it only reduces the amount of uncertainty in the private exponent
to what it would have been anyway for the prime order case (i.e.
about q possibilities),
c) there's no way to extend this attack to recover any of the other
bits.
Actually for most purposes, I would recommend choosing p = 2qr + 1 for
q and r prime, with q about 200 bits [*], g generating a subgroup of
order q, and exponents chosen uniformly on [0, q). That makes the
exponentations much faster, because they take time linear in the exponent
size. It also makes parameter generation faster, because r can be fixed,
and then it's only necessary to find the smaller prime q such that
2qr + 1 is prime.
[*] this gives a security level of about 2^100 against square-root attacks;
adjust to suit your level of paranoia.
> > and preferably have g = 2 as a generator for that group
>
> Is there any particular reason for this?
Only for the (very minor) improvement in efficiency, no other reason.
The order of the subgroup generated by g matters for security, but apart
from that, the choice of a particular g does not.
> I can see that there'd be a
> minor efficiency gain to using g = 2 over (say) g = 4, which will
> *always* generate the prime-order subgroup, but it doesn't really seem
> worth throwing away half the candidate moduli. (I note that g = 2 will
> generate the order-q subgroup precisely when 2 is a quadratic residue
> mod p = 2 q + 1, which I believe happens with probability 1/2.)
Correct; the same number of elements generate the order-q subgroup as
generate the order-2q subgroup.
> > 1024 bit primes took less time, but not a fraction of a second.
>
> Indeed. Maybe Bob ought to tell us how to generate primes
> correctly. ;-) I'd love to know.
Perhaps he just has a spiffier computer than we do? :-)
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOWIU8zkCAxeYt5gVAQEEgAf/SJ0zMYCZJily3NgnOLngu2gtVz5DVzge
940LH0Rw21wbfwDJ5+bVcrD2PV+APMEKHT4XFoxmZup270JxJz7wUX4diPi+kVT2
LBYnljxA0OzgEPheTrG/bAqwOc656wGhWu4HjuciJLmB84jbFPUschg+vgbe5w+0
wU16zL8K7smAEvg8PVvPsOrQN0xKhRAvTapdOjSLtmgEf32y79zhaLHBSnY/aGKM
JK4nFXtlKBphVkFQHMMPVNW3lX6SEIpM40FzZYP//i9jF+7mcKm7KvZjscOwnisz
KEL7INsl4voBhuvQKE0Zk6/UrMur61pDB77woCznCdm4oonMNlJU0g==
=TSHZ
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Crypto Contest: CHUTZPAH...
Date: 4 Jul 2000 13:59:07 -0700
In article <O0s85.793$[EMAIL PROTECTED]>,
Paul Pires <[EMAIL PROTECTED]> wrote:
> It seems to me that the break that these attacks provide is knowledge of
> the key used or some other ability to read other messages or blocks that
> could not be read directly from the attack. Am I missing something?
In practice, that's probably about right.
If we want to speak about academic or certificational attacks,
we go further and we often say that if a chosen-ciphertext attack
allows us to distinguish the cipher from an ideal cipher we should
be very suspicious of the security of the cipher.
I don't know which camp Boris Kazak's attack falls into, but
that's about how it seems to break down, in my opinion.
------------------------------
From: Future Beacon <[EMAIL PROTECTED]>
Subject: Hash and Entropy
Date: Tue, 4 Jul 2000 17:59:24 -0400
Hash and Entropy are the most frequently use mystery words. I
wonder if everybody is operating on the same meanings. You could
follow this news group for a year without getting anybody's
expressed or implied definition for either of these words. If
nobody wants to risk a formal definition of either, maybe an
example calculation would help make these ideas clear.
So far, I get a sense that a hash function is like a number tumbler
that confounds the order of the original numbers and possibly makes
a string of numbers that is longer than the original string.
Entropy seems like some nutso metaphor that no self-respecting
statistician would ever use in calculations.
Go ahead. Enlighten my stupid head.
And Happy 4th of July.
Jim Trek
Future Beacon Technology
http://eznet.net/~progress
[EMAIL PROTECTED]
------------------------------
Date: Tue, 04 Jul 2000 18:27:13 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: A simple all-or-nothing transform
=====BEGIN PGP SIGNED MESSAGE=====
Mok-Kong Shen wrote:
> David Hopwood wrote:
>
> > If the requirement for the function to be unkeyed is dropped, then
> > "all-or-nothing transform" is the wrong term to use; instead use
> > either "pseudo-random permutation" (for deterministic functions) or
> > "semantically secure encryption scheme" (for non-deterministic
> > functions).
>
> I don't share your view. All-or-nothing transform means that one
> applies a procedure to make the encryption (component) processes
> of a message so, that the opponent is forced to deal with the whole
> of the ciphertext material and can't simply concentrate his efforts to a
> part of it and thus achieve economy in his attack (which may even
> be critical for his success).
For *any* secure encryption scheme, an adversary can't simply concentrate
his efforts on a part of the ciphertext. Roughly speaking, if an
adversary can feasibly recover any information about the plaintext given
all of the ciphertext, the encryption scheme is not semantically secure.
This obviously also holds if the adversary is given only part of the
ciphertext (if a scheme is considered insecure when an adversary can break
it given some amount of information, it must also be considered insecure
when he/she can break it given a strict subset of that information).
This means that what you appear to be requiring of a keyed AONT can't be
objectively distinguished from what is required of any other semantically
secure encryption scheme. That's why I claim that it is clearer to use
one of the terms "all-or-nothing transform" (which must be unkeyed),
"pseudo-random permutation", or "semantically secure encryption scheme".
All of these have formal definitions of security, the first given in
[Boyko99], and the other two in [BDJR97], for example.
> Thus, whether the first scientific paper treating the theme happens
> to use a secret key or not is irrelevant to the term 'all-or-nothing
> transform' as such.
If you don't use the term as it is defined in those papers
[Rivest97 and Rivest98], you'll have to define exactly what you mean
by it. Rivest is quite clear about it being unkeyed:
# It is possible to make the chaffing and winnowing technique much more
# efficient, allowing many bits per packet instead of just one. Here is
# one approach. Suppose Alice has a one-megabit message. She might
# pre-process the message using an "all-or-nothing" or "package
# transform" [Rivest97] -- this is a keyless (non-encryption)
# transform that takes the message and produces a "packaged message"
# with the property that the recipient (Bob) can't produce the original
# message unless he has received the entire packaged message. The
# packaging operation can be undone by anyone who receives the packaged
# message; as noted, packaging is not encryption and there are no shared
# secret keys involved in the packaging operation.
> As to the second half of your sentence, I wonder how I am going to
> classify my use of two non-linear block chaining steps (see a follow-up
> of mine of 3rd. Jul), which also forces the opponent to treat the entire
> message, according to your terminology.
I wouldn't try to classify what security properties it has unless I had
time to analyse it thoroughly, which I don't.
[Rivest97] Ronald L. Rivest,
"All-Or-Nothing Encryption and the Package Transform,"
Proceedings of the 1997 Fast Software Encryption Conference,
Springer-Verlag, 1997.
http://theory.lcs.mit.edu/~rivest/fusion.ps
[Rivest98] Ronald L. Rivest,
"Chaffing and Winnowing: Confidentiality without Encryption,"
http://theory.lcs.mit.edu/~rivest/chaffing.txt
[Boyko99] Victor Boyko,
"On the Security Properties of OAEP as an All-or-Nothing
Transform,"
Advances in Cryptology - CRYPTO '99.
Also in http://theory.lcs.mit.edu/~cis/cis-theses.html
[BDJR97] M. Bellare, A. Desai, E. Jokipii, P. Rogaway,
"A Concrete Security Treatment of Symmetric Encryption: Analysis
of the DES Modes of Operation,"
http://www-cse.ucsd.edu/users/mihir/papers/sym-enc.html
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOWIeQDkCAxeYt5gVAQHLNAgA0BBXDe0dnNixkTxASYsKm/N+UKE3YYrw
2lB0kCm0lJJKTOeUFwpDzwE8KFuXymxdWqa++jsxmM28VnLBcCWHCczopPlpcc6c
NtLPW9SzmfpRAFKBmYZikEeYmRtGsTYjECjBV0/hx4LFVddmxtILXp4smuspbtUZ
KWETguerAvUVel4U+e4uRicwgnFUeUBsnrZSOL/yOxsaPNSCyWW2FnFFBfV4F3Uc
4rDJ93QAhU7ihyMAbsKkzpAxgzVOQIrwJmQspl4gAO/nuFOSWCjcLcdemNNNoaDZ
JsljLRTzVnOUEhTbVamz02u0AupFwyYdqaE1drfES+nw4MgYmWUc+Q==
=3ve5
=====END PGP SIGNATURE=====
------------------------------
** 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
******************************
