Cryptography-Digest Digest #476, Volume #9 Wed, 28 Apr 99 07:13:04 EDT
Contents:
Re: DH keys in PGP (Tom McCune)
Re: Dynamic Key Schedule ([EMAIL PROTECTED])
Re: Thought question: why do public ciphers use only simple ops like shift and XOR?
([EMAIL PROTECTED])
Re: break this code (Nathan Kennedy)
Craptology (Lars Ramkilde Knudsen)
Re: Digital Watermarks? (Stefan Katzenbeisser)
Re: Thought question: why do public ciphers use only simple ops like shift and XOR?
(Terry Ritter)
the Sieve of Eratosthenes w/o Multiplication or Division? ("Robert Sitton")
Re: Easy identity-proof (NOT Fiat-Shamir) (Christian Geuer-Pollmann)
Re: Craptology (David A Molnar)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Tom McCune)
Subject: Re: DH keys in PGP
Date: Thu, 22 Apr 1999 10:58:21 GMT
=====BEGIN PGP SIGNED MESSAGE=====
In article <7flugl$9ek$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
wrote:
>How do DH keys work in PGP? I though it was a
>key-agreement algorithm?
PGP uses the "ElGamal variant," of DH. Except for using a paired DSS key
for the signature, it is used in the same manner as RSA keys. I'd be very
surprised if you don't know this process, but just in case I'll put in a
plug for my PGP Questions & Answers:
http://www.borg.com/~tmccune/PGPpage2.htm#128bit
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.0.2
Comment: Tom McCune's PGP Page: http://www.borg.com/~tmccune/PGP.htm
iQEVAwUBNx8AymR4bNCQMh9JAQHz8gf+ObafNX9i+FWovUhyBljrUeYNuGL9UOEE
+QpBDLUAwOFngmTQW+a64uPj0qy4T2ve7s+WWGFVHmkFX0Og5LG+epCxYxQhT6um
L8Vy2FMDjp7yCPwJrAvj2dPvkdHBG8Ku/loTkdfy0kh/rF1HlM2cDg2EgIu/iJYX
IrLDYB1eLoG2sa4TUugvRWQ21hRBlsWfFZLb8mYR9Dad6JBb0WgSmtpneu7Hnpxa
aYapFHBsP+lSp1fSWaC572qj+HWATgtUqekH4e8e1fp2Zy/lXapHkLgXIA48X3rm
mSrQtlf8OwtFDmpyA1YJ4zojX2P9xYGU4iHoxSbPwaibBUGItbmVQw==
=zHgD
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Dynamic Key Schedule
Date: Thu, 22 Apr 1999 10:51:12 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
> It's pointless to propose a new key schedule unless you can show
> concretely that there's something wrong with the old key schedule.
> These attacks that the new schedule makes difficult--were they easy
> with the old one? Can you demonstrate how to break the cipher if it
> uses the old key schedule? That's a much more interesting topic to
> write a paper about--if you can.
>
The idea of the new key schedule is pretty much like a dynamic
s-box which proceses the keys and not the plaintext text register.
The goal is to enhance resistance against diff. analysis by allowing
any one of the bits in the subkey (key broken into parts) to effect
any one of the bits in the plaintext.
Take TEA and XTEA-1 [1] for example, I just modified the same
simple cipher to give it a big improvement (I think) in security.
The only problem is that it is slower, but can be sped up quite
a bit with tables...
Thanks for the feedback,
Tom
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.0.2i
iQA/AwUBNx79z/IPgV4W6pz7EQLRFgCdGLUxWFJ9Q9pPU0XDQcb7tM2r3IMAni98
eriJ9fPq7C0O32pIl+U/xmWW
=Fk8i
=====END PGP SIGNATURE=====
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Thought question: why do public ciphers use only simple ops like shift
and XOR?
Date: Wed, 28 Apr 1999 05:18:00 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Jerry Coffin) wrote:
> In article <7g0u3r$j1h$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> says...
>
> [ ... ]
>
> > Let us design two possible future worlds and then pick the one
> > that is more secure:
> >
> > In the first the AES is used for almost all encryption.
> >
> > In the second world we define a set of several interesting
> > ciphers, preferably ciphers that are different in some fundamental
> > ways. We put in there the AES, some more ciphers that have been
> > extensively analyzed, some ciphers that follow different design
> > methodologies (for example variable ciphers such as Frog, ciphers
> > designed specifically for making analysis very difficult, ciphers
> > using novel primitives or structures, etc.). Now add to all
> > encrypted data or make implicit in all security applications the
> > following information: the subset of the ciphers that must be used
> > and at which "depth", i.e. how many ciphers out of this subset are
> > cascaded in series. Finally extend the secret key with a
> > sufficient number of bits that define the sequence of the ciphers.
> > (I don't want to discuss here how the individual ciphers' keys are
> > defined - I know it is not optimal but as a first approximation
> > let us suppose all individual keys are identical.) Now observe
> > that if you want to use the AES, you just define a subset that
> > includes only the AES and a depth of one. But you can also include
> > the entire set and a depth of one hundred.
>
> The first is more secure, or at least more dependably secure. The
> problem is, when you combine two algorithms, you're basically
> designing a new cypher. If you're lucky, it'll combine the strengths
> of both the base cyphers, while negating some of the weaknesses of
> each.
>
> Unfortunately, in cryptology luck tends to be of the bad kind -- you
> might combine two cyphers that end up negating each other's good
> points, and nearly eliminating each other strengths.
It is possible that the combination of several independently
designed ciphers is weaker than each one of them, but it is also
highly unlikely. It is also possible to break a 3DES encryption by
guessing the correct key on the first try, but again this is very
unlikely. Unless someone finds a proof for a cipher's security the
best we can do is estimate probabilities. Cascading ciphers does
increase security in this sense. Schneier discusses this method in
chapter 15.7 of the second edition of Applied Cryptography. There
are also two papers by Maurer discussing the combination of
block ciphers and of stream ciphers.
> [...]
Dianelos wrote:
> > In fact, the original set of ciphers need not be fixed. Allow
> > anybody to add his or her code to the lot in a public Internet
> > server in an environment where everybody can "Amazon-like" comment
> > on all present ciphers, where the experts' opinion is expressively
> > stated and where statistics are held about which products include
> > which ciphers in their "standard" set of ciphers.
>
> This gets worse and worse. Rather than having a small set of
> primitives that you _might_ be able to study in detail, you're now
> combining an unknown number of primitives in completely unknown ways.
> There's simply no way that anybody can keep up with all the possible
> combinations and figure out which of them produce dangerously poorly
> encrypted output.
Exactly right. You see the point is that if you use a set of eight
ciphers, you cascade 50 executions of them and you keep the
sequence secret you end up with about 2^150 _different_ ciphers.
Also observe that the attacker will not know which of these ciphers
is used. No possible adversary will be able to analyze any
significant subset of this monstrous number of ciphers in order to
mount an attack if, incredibly, a weak combination was found and
also if, incredibly, this precise combination was used by
somebody.
BTW I allow any cipher to be included in the Internet server as a
matter of practicality. After all, all known ciphers are published
somewhere and by having them all in one place my email program
will be able to decrypt anything. Surely the experts would
recommend which sub-sets of these ciphers should be used in
practice.
> [...]
Dianelos wrote:
> > One can ask if all this is really necessary.
>
> One _should_ start by asking whether it's really useful. Since the
> answer is "only rarely, if ever", it's pointless to deal with costs,
> necessity, etc.
On the contrary, such a scheme would be useful in almost all cases
where speed in not an issue. There are many important cases where
this is the case, such as email or financial transactions.
[...]
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Nathan Kennedy <[EMAIL PROTECTED]>
Subject: Re: break this code
Date: Wed, 28 Apr 1999 15:57:37 +0800
> I am hesitant to ask too many (amature) questions as most of the
> postings are about some pretty heavyweight stuff. So I just sit back
> and try to understand as best I can.
> Believe it or not, one of my favorite things is to take an encrypted
> (cypher) and try to decrypt it. Most of the time it is from a program
> that I use or have came across on the net. While the data may or may
> not be of interest to me, the method of encryption is.
But if the algorithm is not disclosed, it's not cryptography, and it's
barely cryptanalysis. It's more a puzzle or a reverse-engineering
exercise. If you can crack a unique cipher given only the ciphertext, and
not given the algorithm, then it's not real cryptography at all. Even the
most mundane system whitens the output enough to make blind
reverse-engineering dull and difficult. If you really could keep the
algorithm secret, even a very poor system could survive much more analysis
than the same system unveiled, because the flaws are hidden, not because
they aren't there. In the real world, security by obscurity doesn't really
work, CERTAINLY not a large scale, because it ceases to be obscure.
> For example I recently took a database that was encrypted and
> converted each of the encrypted characters into a number (In VB5 using
> the asc() function) then I compared the numbers in various ways,
> looking for obvious patterns, adding & subtracting, even multiplying
> the character equilivant codes and much to my surprise a particular
> number kept coming up so I took this number (key) and using a little
> trial and error was able to decrypt the text to its original state. I
> have done this on several occasions using different methods and even a
> little luck. Correct me if I am wrong, but I believe you call this
> differential comparison.
Differential cryptanalysis? No. This is finding a congruence in a simple
cipher. ANY CIPHER that has ANY obvious patterns that can turn up by blind
adding, subtracting, multiplying, whatever, is WORTHLESS, and can probably
be cracked in seconds unaided by simple programs. REAL ciphers have KEYS
and generally either have some nonlinear iterated function (i.e. Feistel
ciphers) operating on a block, or a state array that generates a stream.
> Most recently I have ran across a cypher that has me baffeled as it is
> encrypted in 8 character (byte ?) blocks, and if a character within a
> particular block of the cypher is changed that block is "garbled" in
> the output. There is more but I will save it for later.
That's probably because you came across a real block cipher that does at
least SOMETHING right, and no amount of simple doodling with the ciphertext
will turn up patterns.
> If there are no objections I would like to ask questions as they come
> to mind. Hopefully I will have learned the correct terminology so I
> can better phrase my questions so that they make sense. Just remember
> that I am an amature and I may ask what to many might be "dumb"
> questions, though I am very skilled in many things, unfortunately
> cryptography is not one of them (hopefully that will change).
There's mixed response in sci.crypt to that kind of thing. The best
resource for you at this point would be to search out the excellent
resources on the Web and in print on the subject. Consult the FAQ and
search engines for those.
> P.S. If one or many of you would like to coach an amature like me
> through what looks to be a rough road ahead, please feel free to
> e-mail me any time. I will appreciate it VERY much.
Feel free to e-mail me questions, don't count on an prompt, or any, answer,
though.
Nate
------------------------------
From: Lars Ramkilde Knudsen <[EMAIL PROTECTED]>
Subject: Craptology
Date: Wed, 28 Apr 1999 11:07:40 +0200
Hi,
Second issue of the Journal of Craptology is out.
Also, an "Editor's Note" has been added to the two issues.
http://www.ii.uib.no/~larsr/crap.html
/Lars
------------------------------
From: Stefan Katzenbeisser <[EMAIL PROTECTED]>
Subject: Re: Digital Watermarks?
Date: Wed, 28 Apr 1999 09:12:36 +0200
Fiji wrote:
>
> Where can I get some information about
> companies/products dealing with
> digital watermarks? I am hoping for some
> feedback from users who have used
> said products.
>
> thanks,
> -Fiji
You might have a look at
http://www.cl.cam.ac.uk/~fapp2/watermarking/products.html
You can find an extensive list of watermarking tools
there. On
http://www.cl.cam.ac.uk/~fapp2/watermarking/
you will also find some tools which can be used to
estimate the strength of watermarks. As you will see,
most of the watermarking systems are quite vulnerable...
Regards,
Stefan.
--
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Stefan Katzenbeisser
| e-mail: [EMAIL PROTECTED]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Thought question: why do public ciphers use only simple ops like shift
and XOR?
Date: Wed, 28 Apr 1999 07:28:10 GMT
On Tue, 27 Apr 1999 22:15:30 -0600, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (Jerry Coffin) wrote:
>[...]
>The most fundamental problem with the idea as-presented is that all
>the forms of encryption use the same key. That means that if any
>_one_ of the forms of encryption used is broken, the enemy can recover
>the key and decrypt the message.
One recent "presentation" of this idea was in another thread:
>From: [EMAIL PROTECTED] (Terry Ritter)
>Newsgroups: alt.security.pgp,sci.crypt
>Subject: Re: Announce - ScramDisk v2.02h
>Date: Fri, 02 Apr 1999 19:03:38 GMT
>Lines: 58
>Message-ID: <[EMAIL PROTECTED]>
>
>[...]
>For some years I have been promoting the idea of using multiple
>ciphers, but my argument is different:
>
>[...]
>5. One of the facts of ciphering life is that we cannot prove the
>strength of any cipher. Even NIST review and group-cryptanalysis does
>not give us proven strength in a cipher, so any cipher we select might
>be already broken, and we would not know. We cannot change this, but
>we can greatly improve our odds as a user, by multi-ciphering under
>different ciphers. Doing this means an Opponent must break *all* of
>those ciphers -- not just one -- to expose our data. I like the idea
>of having three layers of different cipher, each with its own key.
Note those last 5 words.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Robert Sitton" <[EMAIL PROTECTED]>
Subject: the Sieve of Eratosthenes w/o Multiplication or Division?
Date: Wed, 28 Apr 1999 09:31:52 GMT
A few months ago I found a fast Sieve, but I did not download the code or
make note of its location. Can you point me to or send me the source for a
Sieve w/o multiplication or division (or exponential operators)? If you
can, I thank you in advance.
Rob
------------------------------
Date: Wed, 28 Apr 1999 09:52:57 +0200
From: Christian Geuer-Pollmann <[EMAIL PROTECTED]>
Subject: Re: Easy identity-proof (NOT Fiat-Shamir)
Hi, Bryan
> > I need a system used for authentication. Systems like Fiat-Shamir have a
> > balance in the computation power: The proof is a little bit hard, the
> > verification is easier. For my project, I need a system with an easy
> > proof and a harder verification. The proof must be done on a very lousy
> > hardware (less computing power than a smartcard and much faster like 1/2
> > second).
> >
> > Do there exist such systems / protocols?
>
> First, if you can assume prover and verifier share a secret,
> then you can use fast symmetric crypographic primatives.
> If you need public key but can do expensive pre-computation that
> doesn't count toward the 1/2 second, then El Gamal variants (such
> as DSA as Pual Rubin pointed out) can serve.
I do not have enough computing power for calculating a cryptographic hash
funktion:
I thought about a system with a master-key. Each wireless device has a unique
serialnumber and a secret value, which is calculated
secret-key = Hash(serialnumber, master-key)
The terminal gets the serialnumber and re-calculates the secret-key using the
master-key.
----
To authenticate the terminal, I planned a easily storing a challenge &
response- value-pair at the wireless device. The challenge(N) is a incremental
counter. The terminal must authenticate itself (e.g. for getting write access
to the wireless device) calculating response(N), which is easily compared by
the wireless device with the stored one.After that, the terminal calculates
the next response(N+1) and sends it to the wireless device, too. This response
is stored for authenticating the next terminal.
An attacker can listen to communications and thereafter authenticate himself,
using response(N+1). But then, he has to upload the response(N+2), which
cannot be calculated (he has no master key), so random garbage is upped. The
next correct terminal can't get access to the wireless device, because the
real
response(N+2) doesn't match with the random garbage, upped by the attacker.
The wireless device is disabled and can be detected.
The authentication of the terminal can be done using only one compare
operation (good - no need for computing power on my wireless device).
----
To authenticate the wireless device, I thougt about a challenge & response
system, but there is not enough computing power to calculate a cryptographic
hash funktion.
The memory is very limited (EVERYTHING in this pretty bad system is limited :
energy - computing power - memory - size of the wireless device ;-( )
Christian
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Craptology
Date: 28 Apr 1999 09:22:09 GMT
Lars Ramkilde Knudsen <[EMAIL PROTECTED]> wrote:
> Hi,
> Second issue of the Journal of Craptology is out.
> Also, an "Editor's Note" has been added to the two issues.
> http://www.ii.uib.no/~larsr/crap.html
Wow. A paper with "hosepipe" as one of the keywords. Truly crap!
-David
------------------------------
** 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
******************************
