Cryptography-Digest Digest #303, Volume #12 Fri, 28 Jul 00 08:13:00 EDT
Contents:
Re: Proving continued possession of a file ([EMAIL PROTECTED])
Re: IDEA Encryption (Runu Knips)
Re: 8 bit block ciphers (Runu Knips)
Re: RC5 Question (Runu Knips)
Security in Palm PDAs ("Manuel Pancorbo")
Re: Security in Palm PDAs ([EMAIL PROTECTED])
Re: Selecting cipher - which one to use? (Mark Wooding)
Re: How is the security of Outlook Express encryption ? (Tom Anderson)
Re: 8 bit block ciphers (Mark Wooding)
Skipjack [ was, 8 bit block ciphers ] (jungle)
Re: generating S-boxes (Tom Anderson)
Re: Selecting cipher - which one to use? (Sander Vesik)
Re: Security in Palm PDAs (Thomas Demuth)
Re: Skipjack [ was, 8 bit block ciphers ] (Mark Wooding)
Re: MD5 Expansion (Mark Wooding)
[Q] Serpent for 256/512 bit blocks ? (Runu Knips)
Re: IDEA Encryption (Raphael Phan Chung Wei)
Re: Enigma with Transpostion (German Mechanisation) (John Savard)
Re: Another PURPLE Question (John Savard)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Proving continued possession of a file
Date: Fri, 28 Jul 2000 08:04:04 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mark Wooding) wrote:
> A while ago, I was asked to come up with some mechanism
> whereby a server could ascertain whether a client, which
> had previously transferred a particular file to the server,
> still had a copy of that file itself. I finally came up
> with something plausible (yet utterly impractical)
> yesterday evening, and I thought I'd share it with the group.
I have found an algorithm that reduces Alice's memory
requirement to zero, and also allows anyone else to
verify that Bob has the file. Perhaps this would be of
interest.
This would be useful for distributed filesystems where a
large group of people on the Internet agree to hold copies
of each other's files. Each person should be able to verify
that each other person isn't cheating, and is truly storing
all the files they say they are storing. The algorithm is:
Alice and Bob both know the message M initially.
Alice generates:
p, q, c, k = randomly chosen
n = p * q
a = k * (M^(-1)) mod (p-1)(q-1)
b = c^k mod n
Alice publishes a signed file containing:
n, a, b, c
Alice and Bob's names, and the filename for M
Alice can then forget everything. Now Victor (or anyone
else) can verify that Bob truly has a copy of Alice's file.
Victor generates:
r = randomly chosen < n
d = c^r mod n
and gives d to Bob. Bob then calculates:
e = d^M mod n
and gives e to Victor. Finally, Victor checks that:
e^a mod n == b^r mod n
If they are equal, then Victor concludes that Bob truly has
Alice's file.
Obviously, there's no way to use the CRT trick here, since
Victor doesn't know the factors of n. Computation can be
made faster by splitting large messages into smaller pieces,
appending a note to each piece telling which piece it is,
and running the algorithm on each piece separately.
There is one further refinement. Suppose Alice gives the
file to many people, including Bob, so that it won't be lost
if one or two hard drives crash. And suppose the
distributed file system allows anyone to see those files.
Then the algorithm won't work. When Victor starts the
protocol with Bob, Bob can just go get the file from someone
else, complete the protocol, then delete his copy. That's
bad, because it means Alice's data isn't as safe as she
thought, because it wasn't stored in as many different
places as she thought.
To prevent this, Alice must generate a public-private key
pair. She publishes her public key, and could use the
private key for conventional signing. When she gives the
original message to Bob, she first appends his name to it,
then encrypts the entire file with her private key.
Anyone can still read it by decrypting with her public
key, but now Bob will find it impossible to reconstruct M
from copies that other people have. This prevents cheating.
It's interesting that it wouldn't be enough for Alice to
sign M the conventional way by encrypting a hash of it
with her private key. She actually has to encrypt the
entire file with her private key. This is the only
protocol I've ever seen that has that requirement.
LCB
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 28 Jul 2000 10:18:33 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: IDEA Encryption
George wrote:
> I'm new to this group, but I have read Applied Crypt. by Mr. Schneier. I was
> wanting to if there was a site I could go to that has a good cryptanalisysm
> of IDEA encryption. I have been told it is the strongest cipher to break,
> and I have been wanting to give it a shot myself.
Hey cool :) But the information that IDEA is the hardest to break is
surely
outdated. The hardest to break is maybe Serpent at the moment. IDEA has
some classes of weak keys, and works only on 64 bit blocks. Well, okay,
it
is still far from being broken :)
> Please let me know where I
> can find some information. I look forward to contributing my new ideas here
> and interacting with other users that take an interest in the field of
> crypto. :)
Sorry I have no link about IDEA. :-(
------------------------------
Date: Fri, 28 Jul 2000 10:34:00 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: 8 bit block ciphers
Mack wrote:
> >Mack wrote:
> > > I am looking into skipjack.
> > The following might help you.
>
> Thanks for the code post.
> Saved me some typing in that table :)
>
> This generally confirms (for me at least)
> that the idea I am working on is not
> That far out there.
>
> It seems that skipjack is simply using a
> 16-bit 4 round cipher to make a 16-bit
> lookup table.
>
> Which is similar to what I am doing with an
> 8 bit lookup table.
>
> What is the best current cryptanalysis of
> Skipjack?
>
> Does anyone know the criteria for the F table?
Skipjack is from the NSA, and is the first (and AFAIK only yet)
cipher which has ever been published by them ever (DES was from
IBM, by Feistel, Coppersmith etc, the NSA only confirmed that
DES is good). AFAIK it is without any known weaknesses.
------------------------------
Date: Fri, 28 Jul 2000 10:42:38 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: RC5 Question
"Douglas A. Gwyn" wrote:
>
> phil hunt wrote:
> > >#include <inttypes.h>
> > >typedef uint32_t u4;
> > Is this standard C/C++ now?
>
> It is part of the 1999 C standard, and has been found on
> many platforms (especially 64-bit ones) for several years.
Really ? I have access to an alpha machine with OSF1 4.0,
and it has no such header.
> One nice thing is that if <inttypes.h> is missing on your
> current system, it is not hard to provide your own. There
> is a free tailorable implementation at
> http://kbs.cs.tu-berlin.de/~jutta/c/q8/
Thank you for that link !
------------------------------
From: "Manuel Pancorbo" <[EMAIL PROTECTED]>
Subject: Security in Palm PDAs
Date: Thu, 27 Jul 2000 14:47:45 +0200
I'm user of PDA Palm computer (very popular in USA, isn't it?). You can hide
entries of your adressbook, notebook, etc and protect them with a password,
which can be a full phrase. The questions are,
* what is the encryption protocol used (hash algorithm, block cipher,...)?
* is it public, let's say, SHA1-3DES?
* how strong is it (number of key bits)?
* is out there a better encryption program that could substitute the
original?
Thanks in advance.
--
____________________________________________________________________
Manuel Pancorbo
[EMAIL PROTECTED]
"...
M�s vale aprender una sola l�nea de Ciencia
que postrarse cien veces en oraci�n. (Cor�n)
Pli valoras lerni ech nur unu linion de Scienco
ol preghe genui cent fojojn. (Korano)
..."
____________________________________________________________________
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Security in Palm PDAs
Date: Fri, 28 Jul 2000 09:24:25 GMT
Manuel Pancorbo wrote:
> I'm user of PDA Palm computer (very popular in USA, isn't it?). You can hide
> entries of your adressbook, notebook, etc and protect them with a password,
> which can be a full phrase. The questions are,
> * what is the encryption protocol used (hash algorithm, block cipher,...)?
> * is it public, let's say, SHA1-3DES?
> * how strong is it (number of key bits)?
> * is out there a better encryption program that could substitute the
> original?
i guess its not encrypted at all, or or maybe XOR...
== <EOF> ==
Disastry http://i.am/disastry/
http://disastry.dhs.org/pgp.htm <-- PGP half-Plugin for Netscape
http://disastry.dhs.org/pegwit <-- Pegwit - simple alternative for PGP
remove .NOSPAM.NET for email reply
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Selecting cipher - which one to use?
Date: 28 Jul 2000 09:26:59 GMT
David Hopwood <[EMAIL PROTECTED]> wrote:
> Blowfish and CAST-128 have almost identical structures; the difference
> is in the S-boxes.
There's another difference too, and that's in CAST's key-dependent
rotations, which do slow it down a fair bit compared to Blowfish.
> [...] it seems to me that random S-boxes of the size used in Blowfish
> protect sufficiently well against known attacks, and it is unknown
> attacks (which can't be specifically designed against) that are the
> greatest concern.
This I agree with completely.
> OTOH, the CAST-128 designers know what they're doing, and there's really
> not much to choose between the two ciphers.
Adams and Tavares are certainly extremely capable.
-- [mdw]
------------------------------
From: Tom Anderson <[EMAIL PROTECTED]>
Subject: Re: How is the security of Outlook Express encryption ?
Date: Fri, 28 Jul 2000 10:34:49 +0100
On Thu, 27 Jul 2000, CMan wrote:
> I ran one of those sniffer programs on my PC (Windows 98). I was
> surprised to see my very private user name and password go out of my
> machine IN THE CLEAR during every request for mail from my ISP. This
> of course is a problem with the protocol, not with Outlook. Makes you
> kind of wonder what else is going out on that network connection.
my version of outlook does at least support SSL-protected POP3 sessions;
if your mail server did too, you'd have very secure mail download. in
addition, POP3 does support the APOP authentication mechanism, which
doesn't send passwords over the network even without TLS, but it doesn't
seem to be used much.
none of which alters the fact that the mail itself crosses the internet
entirely unprotected.
tom
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: 8 bit block ciphers
Date: 28 Jul 2000 09:34:58 GMT
Runu Knips <[EMAIL PROTECTED]> wrote:
> (DES was from IBM, by Feistel, Coppersmith etc, the NSA only confirmed
> that DES is good).
According to Coppersmith, they also changed the S-boxes.
> AFAIK it [Skipjack -- mdw] is without any known weaknesses.
Its `security margin' is extremely low. Biham has a miss-in-the-middle
attack which find a key faster than exhaustive search in Skipjack
reduced by only one round.
Opinion is divided as to whether the low security margin is deliberate.
I believe that the family from which Skipjack comes has been carefully
analysed and the parameters which produced Skipjack were chosen
specifically to make the algorithm's strength commensurate with their
chosen key length of 80 bits, which also appears in the KEA, SHA and DSA
algorithms.
Others have expressed the opinion that Skipjack is weaker than it should
have been and that the NSA made an error.
Oh, by the way, I've not seen any reports that the published Skipjack
algorithm is actually interoperable with previously existing
implementations. Has this actually been verified?
-- [mdw]
------------------------------
From: jungle <[EMAIL PROTECTED]>
Subject: Skipjack [ was, 8 bit block ciphers ]
Date: Fri, 28 Jul 2000 05:50:50 -0400
the published v2 from May 1998 has TEST vectors included ...
it wouldn't be very difficult to verify identical results ...
Mark Wooding wrote:
>
> Runu Knips <[EMAIL PROTECTED]> wrote:
>
> > (DES was from IBM, by Feistel, Coppersmith etc, the NSA only confirmed
> > that DES is good).
>
> According to Coppersmith, they also changed the S-boxes.
>
> > AFAIK it [Skipjack -- mdw] is without any known weaknesses.
>
> Its `security margin' is extremely low. Biham has a miss-in-the-middle
> attack which find a key faster than exhaustive search in Skipjack
> reduced by only one round.
>
> Opinion is divided as to whether the low security margin is deliberate.
> I believe that the family from which Skipjack comes has been carefully
> analysed and the parameters which produced Skipjack were chosen
> specifically to make the algorithm's strength commensurate with their
> chosen key length of 80 bits, which also appears in the KEA, SHA and DSA
> algorithms.
>
> Others have expressed the opinion that Skipjack is weaker than it should
> have been and that the NSA made an error.
>
> Oh, by the way, I've not seen any reports that the published Skipjack
> algorithm is actually interoperable with previously existing
> implementations. Has this actually been verified?
the published v2 from May 1998 has TEST vectors included ...
it wouldn't be very difficult to verify identical results ...
------------------------------
From: Tom Anderson <[EMAIL PROTECTED]>
Subject: Re: generating S-boxes
Date: Fri, 28 Jul 2000 11:12:20 +0100
On 28 Jul 2000, Mack wrote:
> >i was wondering about how one generates S-boxes.
> >
> >i know a good S-box should have various properties, eg avalanche,
> >nonlinearity, etc. let's abstract these into a quality measure (call it
> >q), where 0 is rubbish (eg the identity permutation) and big values are
> >wonderful.
let me check if i've understood these ... let S be the s-box function, a,
b and c be inputs and x, y and z be outputs.
> The three usual criteria are the SAC,
if a and b differ by 1 bit, S(a) and S(b) differ by, on average, half
their bits. do we care more about the actual average (ie 3.9 bits is good,
2.4 is bad) or the deviation from the average (3.9+/-2.1 is bad, 2.4+/-0.2
is good)? or both? should this be weighted with some nonlinear function,
so that 2.4 is more better than 2.3 than 3.9 is better than 3.8?
> Nf (minimum hamming distance)
i don't fully understand this one; i should probably do some more reading!
i do know it's a measure of difference between the function and the most
similar affine boolean function, but i don't solidly get the details and
implications. i do know you can use a FWT to compute it, though!
> and Max Xor entry.
no idea what this is!
> When you are working with high SAC, high Nf,
> and low Max Xor entry it is rather difficult to get them all.
i feared as much.
> You could simply multiply SAC level and Nf then divide by Max Xor entry.
right; you might want to apply some sort of weighting (not multiplicative,
as we're multiplying and dividing the terms anyway; exponential?).
> >my main question is this: is there a transformation which can be applied
> >to a permutation (eg swapping two entries) that will lead to small changes
> >in q? if, so i imagine simulated annealing would be good at finding good
> >S-boxes.
>
> Yes swapping leads to small changes. Yes you can find fairly good
> S-boxes this way. I am experimenting with this.
cool. how is it going? are there transformations other than swaps that
might work?
tom
------------------------------
From: Sander Vesik <[EMAIL PROTECTED]>
Subject: Re: Selecting cipher - which one to use?
Date: 28 Jul 2000 10:17:26 GMT
Mark Wooding <[EMAIL PROTECTED]> wrote:
> Charles Blair <[EMAIL PROTECTED]> wrote:
>> Everybody in this thread seems against IDEA. However, it is an
>> essential component of PGP, at least version 2.6.x. Should PGP
>> users be worried?
> The problems with IDEA are:
> * It's slow. PGP users don't really have to care about this, unless
> they're encrypting really big things.
> * It's patented. However, Ascom Tech AG (the owners of the patent)
> will grant licences for noncommercial use. The PGP licence for the
> no-cost version requires noncommercial use anyway, so that's not a
> problem. This patent is the reason that GnuPG doesn't implement
> IDEA, however.
Indeed, they cannot implement IDEA due to the terms of the licence.
> * There are much better ciphers available now, such as all of the
> other ones which have been mentioned, in terms of both security
> margin and performance.
> Phil Zimmerman seems to get warm fuzzy feelings about different ciphers
> from me. He had one about IDEA, and he claims to have one about
> CAST128. While there's nothing really wrong about either of these from
> a security point of view, I get much warmer and fuzzier feelings about
> Blowfish and Serpent.
> -- [mdw]
--
Sander
FLW: "I can banish that demon"
------------------------------
From: Thomas Demuth <[EMAIL PROTECTED]>
Subject: Re: Security in Palm PDAs
Date: Fri, 28 Jul 2000 12:20:21 +0200
Hello!
Manuel Pancorbo wrote:
>
> I'm user of PDA Palm computer (very popular in USA, isn't it?). You can hide
> entries of your adressbook, notebook, etc and protect them with a password,
> which can be a full phrase. The questions are,
> * what is the encryption protocol used (hash algorithm, block cipher,...)?
There is no encryption at all, private entries are only hidden or masked
(OS 3.5 or above).
If you are looking into the files datebook.dat, etc. on your Mickeysoft
Windos PC you can see the entries in clear text.
Use the tool secret! (http://linkesoft.com/) instead. It uses real
encryption.
Greetings,
Thomas
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Skipjack [ was, 8 bit block ciphers ]
Date: 28 Jul 2000 10:49:46 GMT
jungle <[EMAIL PROTECTED]> wrote:
> the published v2 from May 1998 has TEST vectors included ...
> it wouldn't be very difficult to verify identical results ...
Indeed. But has anyone actually done this?
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: MD5 Expansion
Date: 28 Jul 2000 11:08:32 GMT
Daniel Leonard <[EMAIL PROTECTED]> wrote:
> Well, you could modify MD5 the same way RIPEMD128 was modified to give
> RIPEMD256, but that would be recoding it.
Not really, no. The RIPEMD hashes work by having two parallel
compression functions and combining the results. The double-width
versions just use the parallel functions without combining the results.
Since MD5 only has one compression function, you can't really break it
apart without halving the performance -- a sacrifice which the double-
width RIPEMD variants don't have to make.
-- [mdw]
------------------------------
Date: Fri, 28 Jul 2000 13:08:08 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: [Q] Serpent for 256/512 bit blocks ?
In the Serpent paper, the authors mention versions of Serpent for 512
and 256 bit
blocks (and also for 64 bit btw), which should also be specified, but I
can't find
any further information about this on the net, neither on the serpent
homepage nor
on those of the authors. Does anybody have information/links about that
? Thank
you.
------------------------------
Date: Fri, 28 Jul 2000 19:25:36 +0800
From: Raphael Phan Chung Wei <[EMAIL PROTECTED]>
Subject: Re: IDEA Encryption
try www.counterpane.com which has an online archive of papers
George wrote:
> I'm new to this group, but I have read Applied Crypt. by Mr. Schneier. I was
> wanting to if there was a site I could go to that has a good cryptanalisysm
> of IDEA encryption. I have been told it is the strongest cipher to break,
> and I have been wanting to give it a shot myself. Please let me know where I
> can find some information. I look forward to contributing my new ideas here
> and interacting with other users that take an interest in the field of
> crypto. :)
> --
> -George
> [EMAIL PROTECTED]
--
Raphael Phan
Faculty of Engineering
Cyberjaya Campus
Multimedia University
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Enigma with Transpostion (German Mechanisation)
Date: Fri, 28 Jul 2000 11:35:49 GMT
On Fri, 28 Jul 2000 05:02:15 +0000, Jim Gillogly <[EMAIL PROTECTED]> wrote,
in part:
>Do you feel equally outraged and dismissive toward the Allies for their
>reliance on the mechanisation combined with large mathematical possibilities
>represented by Typex and SIGABA? If not, why not?
An interesting question.
I suppose your point is that it is unfair to criticize people in
hindsight. But I could counter that as Typex and SIGABA weren't
broken, this shows their users knew what they were doing: but that
does, I suppose, make another point: transposition isn't really
required, a purely mechanized rotor machine can be made secure.
And wanting to fully mechanize communications isn't just a "cultural
bias"; the speed and efficiency of communications was an important
variable that helped to make the blitzkrieg originally possible.
But on the other hand, not only would transposition afterwards have
vitiated attacks on the Enigma, but the Americans could have benefited
from the same trick as well. Although Sigaba wasn't broken, it was
only used for communications between secure sites; the U.S. forces
largely relied upon strip ciphers and the M-94, essentially forms of
the Bazieres cylinder, which _were_ broken (and by an attack that went
beyond de Viaris that the Americans didn't expect). Since these
systems had one of the same weaknesses as the Enigma - no letter
became itself, allowing cribs to be aligned - transposing afterwards
would have helped.
But transposition doesn't just slow down communications because of the
time it takes. People, particularly under adverse conditions, make
*mistakes* when carrying out a transposition. Requiring
retransmissions. This fact does indeed tend to say that there was more
than "cultural bias" at work; our age must also not try to explain
everything in terms of its own blind spots.
John Savard (teneerf <-)
Now Available! The Secret of the Web's Most Overused Style of Frames!
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Another PURPLE Question
Date: Fri, 28 Jul 2000 11:38:46 GMT
On Fri, 28 Jul 2000 01:05:08 -0700, Charles Petersen
<[EMAIL PROTECTED]> wrote, in part:
>However, decryping is being a real bitch.
>In the real machine simply typing in the cipher text with the same
>settigns would decode it. I don't understand how that works at all.
>With the Enigma it's rather obvious why it would work, with the SIGABA
>it just sends it back the other way. But the PURPLE doesn't appear to
>do either of these things.
No, the PURPLE did just "send it back the other way", because it isn't
made like the Enigma. (Constructing the permutations so as to be
somehow symmetrical wouldn't help, unless you still had a
'deciphering' switch to reverse the carry order of the switch
steppings.) Of course, that means you need to have tables of inverses
of all the 75 permutations of 20 characters in the machine plus the 25
permutations of 6 characters.
The PURPLE did have a plugboard a bit like that of the Enigma.
John Savard (teneerf <-)
Now Available! The Secret of the Web's Most Overused Style of Frames!
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
** 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
******************************
