Cryptography-Digest Digest #108, Volume #12 Mon, 26 Jun 00 08:13:00 EDT
Contents:
Re: Public key algorithm conversion - does it possible? (Mark Wooding)
On a notation issue of Feistel ciphers (Mok-Kong Shen)
RPK ([EMAIL PROTECTED])
Re: MD5 Expansion (Mark Wooding)
Re: TEA-wmlscript question (dexMilano)
Re: How Uncertain? (Runu Knips)
Re: DES 64 bit OFB test vectors (Jack Spencer)
Re: security problem with Win 2000 Encryption File System (S�bastien SAUVAGE)
Re: DES 64 bit OFB test vectors (Jack Spencer)
Re: Quantum computing (Rob Warnock)
Re: XOR versur MOD (Mark Wooding)
Re: DES and questions (Gerard Tel)
Re: DES 64 bit OFB test vectors (Mark Wooding)
Re: TEA-wmlscript question (Mark Wooding)
Re: Variability of chaining modes of block ciphers (Mark Wooding)
Re: Variability of chaining modes of block ciphers (Mark Wooding)
Re: On a notation issue of Feistel ciphers (tomstd)
Re: RPK (tomstd)
Key agreement in GSM phones (Gerard Tel)
Re: Algo's with no easy attacks? (Runu Knips)
Re: Quantum computing (Runu Knips)
Re: Idea or 3DES (jungle)
Has anyone got / read: "The CRC Handbook of Combinatorial Designs" ("Sam Simpson")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Public key algorithm conversion - does it possible?
Date: 26 Jun 2000 08:14:43 GMT
acoola <[EMAIL PROTECTED]> wrote:
> Maybe it's my fallacy but it seems to me that it's no trivial for
> cryptanalyst to get g.
You're right, it's not trivial. However, it's also irrelevant. *Any*
generator will do!
I'll restate the various parameters for your system, in more general
terms, and switching around the `public' and `private' labels:
Possibly shared:
A cyclic group G, with order q.
Public key:
An integer 1 < x < q.
Private key:
A generator g of the group G, and the element y = g^x.
`Signature'
A pair (a, b) = (g^k, M y^k)
`Verification'
b / a^x
The adversary chooses any generator g' of the group G. This is easy
enough to do. He computes y' = g'^x and uses the pair (g', y') as his
private key.
> > What's the difference between what you want to do and a digital
> > signature?
>
> I'd like to unite properties of digital signature and enciphering and
> I want to find out does it possible to make it at a time.
Investigate signature algorithms with message recovery, e.g., RSA.
-- [mdw]
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: On a notation issue of Feistel ciphers
Date: Mon, 26 Jun 2000 10:50:24 +0200
Feistel ciphers having two equal halves, e.g. DES, are
commonly described as follows for the i_th round:
L_i = R_(i-1)
R_i = L_(i-1) + F(K_i,R_(i-1))
If one combines two rounds into one combination ('big round'
for short in the following) and denotes the two halves of
the input to the big round with L and R, the two round keys
with K_1 and K_2 and the two halves of the output from the
big round with L' and R', one obtains
L' = L + F(K_1,R)
R' = R + F(K_2,L')
With this formulation one clearly sees the nature of the
iteration process involved when sucessive rounds are
performed, while in the original formulation this is
obscured a little bit by the 'swapping' of the two halves
of the block.
It may be interesting that using big rounds enables one to
simplify formulation for the (at least theoretically
conceivable, though for practical purpose presumably not
advantageous) case where the block is divided into, say,
three equal parts instead of two. Denoting the three parts
with U, V and W and the three round keys with K_1, K_2
and K_3, we have
U' = U + F(K_1,V)
V' = V + F(K_2,W)
W' = W + F(K_3,U')
M. K. Shen
=============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED]
Subject: RPK
Date: Mon, 26 Jun 2000 08:38:16 GMT
This public key cryptographic system seems to fit audio and video
application very well.
Does anyone know about "real" applications that use it ?
Does anyone work on trying to break it ? ( Just to know how robust this
system is and how reasonnable it is to use it).
Thank you
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: MD5 Expansion
Date: 26 Jun 2000 09:08:29 GMT
David A. Wagner <[EMAIL PROTECTED]> wrote:
> David Hopwood already posted one attack, so this is probably
> irrelevant, but here's another, just in case you're interested.
I think this works with the `fixed' version. I'll give up at this
point.
-- [mdw]
------------------------------
From: dexMilano <[EMAIL PROTECTED]>
Subject: Re: TEA-wmlscript question
Date: Mon, 26 Jun 2000 09:13:29 GMT
I love you guy.
I'll meka the test and let you know.
Just a question: How can I calculate a golden number (which is the
theory)? Have you some reference on the web.
Thanks
dex
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mark Wooding) wrote:
> dexMilano <[EMAIL PROTECTED]> wrote:
> > I've tried to implement TEA in wmlscript but I've found some
problem to
> > assign the Golden number delta (= 0x9e3779b9).
> > In the wmlscript we have (signed) int a 32 bit so the range arrive
to
> > 7fffffff.
> >
> > The question is: Is there a way to create a golden number minor than
> > 7fffffff?
>
> Try -0x61c88647.
>
> -- [mdw]
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Mon, 26 Jun 2000 11:15:05 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: How Uncertain?
tomstd wrote:
> ASCII data is not random simply because we use a language that
> has a bias towards certain chars. Have you ever wondered how
> programs like pkzip can compress a text file with a 75% ratio or
> more? That's because it's hardly random.
>
> So if you take a MB of text and take any bits from the chars
> your output is hardly going to be random.
I second that. The files A and B might be a good input for
algorithms to create cryptographically strong random sequences
(such as /dev/random device in many Unix systems), but they
themselves alone are not good enough random for an OTP. I
would be very surprised if not some statistical noise would
have been left in these files.
------------------------------
From: Jack Spencer <[EMAIL PROTECTED]>
Subject: Re: DES 64 bit OFB test vectors
Date: Mon, 26 Jun 2000 19:27:12 +1000
> --
> If you know about a retail source of
> inexpensive DES chips, please let
> me know, thanks.
That's easy: get a DES core and cheap FPGAs.You'll be able to fit
multiple cores on one chip, each
running at over 120MHz (480 Mbits/sec)..
You can get free DES core from the web or a commercial
one if you need support. Some commercial DES links:
http://www.ocean-logic.com
http://www.xentec-inc.com
http://www.cast-inc.com
I'm sure there's more.
> Sent via Deja.com http://www.deja.com/
> Before you buy.
JS
------------------------------
Subject: Re: security problem with Win 2000 Encryption File System
From: [EMAIL PROTECTED] (S�bastien SAUVAGE)
Date: Mon, 26 Jun 2000 09:33:15 GMT
[EMAIL PROTECTED] (james) wrote in <8j0hkv$1hl$[EMAIL PROTECTED]>:
>EFS ( encryption file system ) in Windows 2000 is a big shit.
>
>It doesn't encrypt a volume but each file individualy if you activate
>'crypted' in the properties of the file.
>Even if you activate 'crypted' in the properties of a directory , each
>file will be encrypt individualy ( with an other IV ) but the original
>file that wasn't encrypted, remains on the disk ( deleted ).
>
>No one can trust EFS !
Thanks for the info.
I will stick to E4M and ScramDisk.
--
S�bastien SAUVAGE - [EMAIL PROTECTED]
http://www.bigfoot.com/~sebsauvage
------------------------------
From: Jack Spencer <[EMAIL PROTECTED]>
Subject: Re: DES 64 bit OFB test vectors
Date: Mon, 26 Jun 2000 19:35:09 +1000
> I don't have any to hand, but maybe this will help:
>
> key 0123456789abcdef
> IV 0f1e2d3c4b5a6978
>
> First 256 bytes of output are
Thanks, I suppose these can be considered OFB vectors
with plaintext =0x0000000000000000 .
Thanks also to Hideo Shimizu <[EMAIL PROTECTED]>
for his cute on line routine.
JS
------------------------------
From: [EMAIL PROTECTED] (Rob Warnock)
Subject: Re: Quantum computing
Date: 26 Jun 2000 09:56:24 GMT
Bill Unruh <[EMAIL PROTECTED]> wrote:
+---------------
| "Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
| >Bill Unruh wrote:
| >> Uh, no. Error correction itself requires incredibly unnoisy qbits. The
| >> raw level of error must be less than about 10^-4 for one even to dream
| >> of error correction.
| >Wrong again.
|
| Interesting argument. I work in quantum computing. What is the basis for
| your statement?
+---------------
Doug is probably thinking of classical error correction, where the *channel*
error rate can be arbitrarily close to 50% and still get arbitrarily good
reliability... as long as you have enough redundancy (that is, your code
rate or "good-put" is low enough). Even with only moderately-heavy redundancy,
channel error rates of (say) ~40% are "no problem" (e.g., some codes used
in space probes can tolerate *less* than 0 dB signal-to-noise!).
But in classical error correction, *only* the channel itself is presumed
to be subject to error. The encoder & decoder elements -- and the arithmetic
done in them -- are themselves presumed to be error-free.
So I'm guessing that what Bill sees as the problem is that in a quantum
computer if you assume "noisy" qubits you must also assume that *all*
parts of the error correction system are equally noisy, since to preserve
superposition your error-correction arithmetic must itself also be a
quantum computation.
That vastly complicates things, and while I don't know myself that the
threshold of usability is as bad as 1e-4 (what's that in terms of Eb/N0,
about +9dB or so? -- I don't have my tables handy), I'm sure that it's
*way* worse than the -1.6dB of the Shannon Limit for a classical binary
symmetric channel.
-Rob
=====
Rob Warnock, 41L-955 [EMAIL PROTECTED]
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: XOR versur MOD
Date: 26 Jun 2000 10:02:51 GMT
Richard Outerbridge <[EMAIL PROTECTED]> wrote:
[f(x, y) = -(x + y)]
> Would this perhaps be a better disjoint combiner with XOR than ADD?
I suspect that this has very similar properties to addition, and doesn't
offer much in the way of advantage.
A brief experiment investigating XOR-differential properties of addition
and your combiner show that there's very little to choose from. I
suspect that they have extremely similar nonlinearity properties too,
and that hence it's not worth the additional complexity.
-- [mdw]
------------------------------
From: Gerard Tel <[EMAIL PROTECTED]>
Subject: Re: DES and questions
Date: Mon, 26 Jun 2000 12:01:24 +0200
The Meet in the Middle attack on 2DES was suggested twenty years
ago, but the time-memory product is still pretty challenging!!
Is there evidence or proof that it has ever actually been successfully
carried out?
(I appreciate to receive email reply in addition to a posting in
this group. I might miss something because of the large volume
in the group.)
Scott Fluhrer wrote:
>
> rick2 <[EMAIL PROTECTED]> wrote in message news:rb-29667B.16575825062000@news...
> > would be worth it. So, not very brilliant, but what about 2-DES?
>
> It turns out there's a meet-in-the-middle attack that will, with O(2**M)
> memory and a couple known plaintext/ciphertext pairs, break it in
> O(2**(112-M)) time, for M<=56.
Gerard Tel
http://www.cs.uu.nl/~gerard/
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: DES 64 bit OFB test vectors
Date: 26 Jun 2000 10:04:14 GMT
Jack Spencer <[EMAIL PROTECTED]> wrote:
> > I don't have any to hand, but maybe this will help:
> >
> > key 0123456789abcdef
> > IV 0f1e2d3c4b5a6978
> >
> > First 256 bytes of output are
>
> Thanks, I suppose these can be considered OFB vectors
> with plaintext =0x0000000000000000 .
Yep.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: TEA-wmlscript question
Date: 26 Jun 2000 10:13:14 GMT
dexMilano <[EMAIL PROTECTED]> wrote:
> I love you guy.
Shh! I told you: not in public!
> Just a question: How can I calculate a golden number (which is the
> theory)? Have you some reference on the web.
The `Golden number' \phi keeps cropping up in all sorts of interesting
places in mathematics. \phi is the ratio between the sides of a
rectangle such that, when a square of side equal to the rectangle's
longest side is added, the resulting rectangle is similar to the
original. It appears in the study of the Fibonacci sequence. \phi^2 =
\phi + 1; 1/\phi = \phi - 1. \phi has the continued fraction 1 + 1/(1 +
1(1 + 1/...)).
That should be enough to let you calculate it. ;-)
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Variability of chaining modes of block ciphers
Date: 26 Jun 2000 10:16:20 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> The method of chaining I described was implemented in my
> algorithm WEAK3-EX. I personally don't like the common CBC,
> since all the chaining values are known to the analyst.
This doesn't matter because the cipher resists key-recovery attacks.
The chaining mode is there to hide the block structure, *not* to provide
resistance to cryptanalysis. Indeed, the more `unobtrusive' the
chaining mode is to analysing the cipher the more confident we can be in
asserting that its use doesn't weaken the underlying cipher.
> (Often a plain IV is used. Using a secret IV in this case
> renders only the chaining value of the first block unknown
> to him.)
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Variability of chaining modes of block ciphers
Date: 26 Jun 2000 10:22:19 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Scott Fluhrer wrote:
>
> > Depends on the mode. If we're talking to some variant of CBC or
> > CFB, it won't help at all (as long as the message is at least two
> > blocks long) -- the attacker selects some block other than the
> > first.
>
> That is the reason why I personally don't like CBC. (See one of my
> follow-ups in response to Tim Tyler.) Such discussions are among what
> I intended to elicit with my original post.
A long, long time ago, I used to think this too. Note that PCBC is
transparent to known-plaintext attacks.
> You are distorting the discussion context. We are discussing the
> possibilities to obtain some improvements upon a given cipher with
> some chaining modes, not discussing using two or more ciphers.
I think that Scott is trying to say that if you're not happy with your
cipher's security, you're best off preprocessing with another cipher
rather than playing with fancy chaining modes.
> > You rarely get precise estimates of the computer power available to
> > the opponent. If nothing else, opponents tend to stay around for a
> > while, and the computer power available tends to rise unpredictably
> > over time.
>
> We were discussing whether the situation I mentioned can happen at
> all, not how frequent it can exist.
I suspect that it can't exist. Indeed, I suspect that, if we know our
adversary's capabilities that accurately, we probably don't need
cryptography at all, because we can determine a communication channel
which is already secure against him.
> There are also possible situations where one is 'powerless' in
> security and one could just as well give up encryption, namely if the
> opponent is (almost) omnipotent.
Quite so.
-- [mdw]
------------------------------
Subject: Re: On a notation issue of Feistel ciphers
From: tomstd <[EMAIL PROTECTED]>
Date: Mon, 26 Jun 2000 04:11:37 -0700
With three words you have an unbalanced feistel cipher. They
are not particularly usefull for encryption (but good as hash
functions). Check this out.
A = A + F(C)
B = B + F(A)
C = C + F(B)
Looks good because the previously modified word is going through
the F function the avalanche will be high... but let's look at
decryption.
C = C - F(B)
B = B - F(A)
A = A - F(C)
Now it's all backwards the previous word is not the input so the
avalanche is much less.
Tom
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Subject: Re: RPK
From: tomstd <[EMAIL PROTECTED]>
Date: Mon, 26 Jun 2000 04:12:33 -0700
[EMAIL PROTECTED] wrote:
>This public key cryptographic system seems to fit audio and
video
>application very well.
>Does anyone know about "real" applications that use it ?
>Does anyone work on trying to break it ? ( Just to know how
robust this
>system is and how reasonnable it is to use it).
>Thank you
why do you suggest it is suited for music?
Tom
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: Gerard Tel <[EMAIL PROTECTED]>
Subject: Key agreement in GSM phones
Date: Mon, 26 Jun 2000 13:18:24 +0200
Two questions on GSM protection, left after reading Biryukov/Shamir/
Wagner's account on breaking the A5/1 stream cipher:
1. What protocol is used by the two parties to agree on the
64 bit keys used?
2. Is the encryption used ONLY on the ether link (between base and
mobile) or is the data also encrypted during transportation over
the fiber network?
Gerard Tel
http://www.cs.uu.nl/~gerard/
------------------------------
Date: Mon, 26 Jun 2000 13:42:02 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Algo's with no easy attacks?
matt wrote:
> [I want the perfect cipher]
Every cipher might be attacked. A n bit message might be encrypted
in (2**n)! ways, the m bit key you choose selects just one of these
gigantic mass of possibilities can only be a very small fraction,
unless 2**m ~ (2*n)! of course.
And a block cipher works only with a fixed n at a time. That is the
reason why using the block cipher without any feedback mechanism is
a very bad idea, because if the same block appears twice or even
more often, no matter how good the block cipher is, the result does
always contain this structure again.
The target is therefore to design ciphers in a way that the
attacker has to collect more resources than he or she might ever
get.
I think the best thing one may do is using a secure block cipher
such as Twofish in CBC mode.
------------------------------
Date: Mon, 26 Jun 2000 13:49:28 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Quantum computing
"Douglas A. Gwyn" wrote:
>
> Bill Unruh wrote:
> > We have no idea at all of what is involved with building a quantum
> > computer with an internal memory of more than say 10 bits.
>
> Wrong.
Hmm looks like your family name is "DeNiro" ? ;-)
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk,comp.security.pgp.discuss
Subject: Re: Idea or 3DES
Date: Mon, 26 Jun 2000 07:57:13 -0400
Lucks from Fast Software Encryption in 1998 explained that :
- about 2^108 steps are sufficient to break triple DES ...
- when one concentrates on the number of single DES operations & assumes the
other operations to be much faster, 2^90 steps are sufficient ...
IDEA on the other hand needs 2^128 steps ...
therefore,
- IDEA should be considered extremely more secure than triple DES ...
- exactly, from 2^38 to 2^20 steps more secure ...
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>,
> jungle <[EMAIL PROTECTED]> wrote:
> > IDEA ...
> >
> > [EMAIL PROTECTED] wrote:
> > >
> > > Of the two ciphers IDEA and triple DES, what provides the best
> security? I
> > > read somewhere that DES had been broken.
>
> FWIW, I disagree with Jungle. My paper PGP DH vs PGP RSA
> (http://www.scramdisk.clara.net/pgpfaq.html) explains why.
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Has anyone got / read: "The CRC Handbook of Combinatorial Designs"
Date: Mon, 26 Jun 2000 13:01:52 +0100
(Details at: http://www.crcpress.com/index.htm?catalog/LM0659)
The audience includes "Cryptographers" - anyone read it? Any
comments?
--
Sam Simpson
http://www.scramdisk.clara.net/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
------------------------------
** 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
******************************
