Cryptography-Digest Digest #301, Volume #12 Thu, 27 Jul 00 23:13:01 EDT
Contents:
Re: Crypto Export Controls ([EMAIL PROTECTED])
Re: R: CD destruction (Greg)
Re: Crypto jokes? (potentially OT) (Tim Tyler)
Re: The Purple Cipher (World War II) (John Savard)
Re: The Purple Cipher (World War II) (John Savard)
Re: Enigma (John Savard)
Re: "Symmetric" RSA encryption (David Hopwood)
Re: What is DES3mCBCMACi64pPKCS5? (David Hopwood)
Re: counter as IV? (David Hopwood)
Re: Selecting cipher - which one to use? (David Hopwood)
Re: Enigma (Jim Gillogly)
Re: What is DES3mCBCMACi64pPKCS5? (Paul Rubin)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Crypto Export Controls
Date: Thu, 27 Jul 2000 21:56:18 GMT
How do the export classification requests work? I'm guessing that even
with downloads (if there's a possibility that software will be
downloaded internationally from a US web site) one has to file such a
request.
Do you know if they're quick to file?
thanks.
>
> you may know this already ...
> ==============================
>
> U.S. companies can export ... without a license ... any encryption
product to
> any end user in the 15 nations of the European Union as well as
Australia,
> Norway, Czech Republic, Hungary, Poland, Japan, New Zealand and
Switzerland
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: R: CD destruction
Date: Thu, 27 Jul 2000 22:16:47 GMT
In article <8lpend$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Guy Macon) wrote:
> Greg wrote:
> >
> >> This may well be an unsound idea, but the last time I had to
> >> destroy a CD-R I just nuked it in the microwave.
> >
> >Well, if you don't have a solvent, a fire place lit already, or
> >a power tool, I guess a microwave would make a decent improvision
> >for when the ninja clad swat team is jumping through your door.
> >
> >Toilets just won't cut it for CDs...
> >
> >Microwaves are really cheap and abundant these days. But I would
> >recommend a Microwave sitting next to your PC on an uninterruptable
> >power supply - in case the swat team cut the power to your house
> >before making entry.
> >
> >Just a thought...
> >
>
> Or you could just use encryption and be safe even if you aren't home
> when they show up with the battering ram.
Oh, ya, that's right...
--
Craig: Well what will you do?
William: I will invade England and defeat the English on their own
ground.
Craig: Invade? That's impossible.
William: Why? Why is that impossible? You're so concerned with
squabbling for the scraps from Longshank's table that
you've missed your God-given right to something better.
There is a difference between us.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Crypto jokes? (potentially OT)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 27 Jul 2000 22:42:24 GMT
Steve Meyer <[EMAIL PROTECTED]> wrote:
: [...] book "The Evolution of Secrecy From Mary, Queen
: of Scotts to Quantum Cryptography" by Singh, S., Double Day,
: New York, 1999 [...]
Is this what "The Code Book" is called in some foreign land? ;-)
: There is no corraboration in book (no references or detailed
: description of discovery steps) of claim that public key cryptography
: was invented by classified crypography establishment.
Well, it's a popular book.
: My attempt at making a joke is that Feyerabend's
: (and Lakatos' and Kuhn's) theory of incommensurability makes it
: extremely unlikely that there was secret discovery by classified
: establishment [...]
Surely this is widely accepted now.
: Final answer to this question will need to wait for future when historians
: can study the "by then" unclassified documents.
Many of the details were unclassified in 1997 - that's how we know about
it today. Some documents also appear to have been unclassified - see the
quote from Ellis, 1987 on p.292, for example.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ VIPAR GAMMA GUPPY.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The Purple Cipher (World War II)
Date: Fri, 28 Jul 2000 01:12:08 GMT
On Thu, 27 Jul 2000 12:24:06 GMT, [EMAIL PROTECTED] (Charles Blair)
wrote, in part:
> I am curious about the comparison between purple and enigma. Were
>the techniques for breaking similar? Were the projects done completely
>independently of one another? Is it possible to say which break was
>intellectually more difficult?
The Purple breaks - if you include the one for CORAL - were probably
more difficult.
Purple was one-way through, so the classical isomorph method used for
Hebern rotor machines, rather than the modification known as 'the
method of batons' used on the Enigma, was useful against it; this
method is general, and doesn't depend on the relationships between
different rotor alphabets.
The projects were independent: the Americans and the British, at the
beginning, didn't know what each other was doing.
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: The Purple Cipher (World War II)
Date: Fri, 28 Jul 2000 01:15:45 GMT
On Wed, 26 Jul 2000 15:49:29 -0700, Charles Petersen
<[EMAIL PROTECTED]> wrote, in part:
>From what I can
>tell there are 4 banks in the main system and just one bank of one
>switch in the six letter system.
Only three banks in the main system. The sixth wire on one of the
stepping switches was used to control switch movement.
Machine Cryptography and Modern Cryptanalysis by Cipher A. Deavours
and Louis Kruh - expensive and now out of print - was the source I
used for most of the information on PURPLE on my web page.
Decrypted Secrets by Bauer from Springer-Verlag might have a bit of
information.
Apparently, the complete wirings for PURPLE are in one of the
declassified documents in the National Archives - there's a long list
of them on the NSA site, under "Project Opendoor".
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: Enigma
Date: Fri, 28 Jul 2000 01:18:21 GMT
On 27 Jul 2000 19:07:02 GMT, [EMAIL PROTECTED] (JPeschel)
wrote, in part:
>You can find Enigma source code and executables, as well
>as Enigma links on the "Historical" page of my web site.
>You'll also find Jim Gillogly's paper describing his ciphertext-
>only attack on Enigma.
That reminds me: does he have a web site? I recently changed a mention
of David Wagner into a link. (I still add a few little things here and
there to my web pages.)
John Savard (teneerf <-)
Now Available! The Secret of the Web's Most Overused Style of Frames!
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
Date: Fri, 28 Jul 2000 12:41:13 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: "Symmetric" RSA encryption
=====BEGIN PGP SIGNED MESSAGE=====
John Myre wrote:
[protocol where a trusted party generates an RSA modulus and gives
(n, e) to Alice, (n, d) to Bob.]
> Decrypting a message means you have verified the signature (assuming
> the message has some verifiable structure, of course).
You would have to be careful that the padding method/redundancy function
doesn't allow an attack. Using PSS-R padding should work (see [PSS-R] and
"EMSR3" from [P1363aD4]).
OTOH, I don't see that any efficiency gain outweighs the security
problems introduced by using a trusted party. (Note that even if you
have a party trusted by everyone, it will be a single point of attack.)
> Given randomly selected e's, could some number of pairs of
> people use the same n? (Assuming the factors of n are
> never learned [directly] by any adversary.)
No, because if there are mutually untrusting pairs, then one pair could
conspire to learn the factors of n. (It works from a technical point of
view if the trust relationships are such that everyone trusts at least
one person from each pair, but that's probably very unrealistic.)
[PSS-R] Mihir Bellare, Phillip Rogaway,
"The Exact Security of Digital Signatures: How to Sign with RSA
and Rabin"
http://www-cse.ucsd.edu/users/mihir/papers/exactsigs.html
[P1363aD4] IEEE P1363a draft version 4 (D4).
http://grouper.ieee.org/groups/1363/P1363a/index.html
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOYFxHzkCAxeYt5gVAQFLbggAmmxoerGzyDqQpAD2Lu0ZkTU48BLMik0B
OEFxKcYZNq6cswqllxRHvpaQKjuc2O+W33vuC/GQSLI9shQqHyBUU2c2wR9Aambs
e8HAFuKFQcwgMoC/BlfMU2NVu5ZDpd9nX0JGu94hOFyaLbwEKmOoWYgNKEDgyoJU
V4HF6HeRJxh3/C6BM3Zub/T6GNo6iA6BujH93YyvSyetDR9hV7ZuSAIz+CK8TU3Z
d0ek8nAFclWnGeltF1/8q/kw1AntLordvDRagXE18y73qCXAP1NMWvyntVvqPvxu
9tGzDqOQuAFwS6CXpDjyh7tzUUlcPuQfp7qCxboqBCihGrM8J4w6vw==
=drLa
=====END PGP SIGNATURE=====
------------------------------
Date: Fri, 28 Jul 2000 13:08:38 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: What is DES3mCBCMACi64pPKCS5?
=====BEGIN PGP SIGNED MESSAGE=====
Paul Rubin wrote:
> I'm using a cryptography module that supports an encryption mode
> called Mech_DES3mCBCMACi64pPKCS5. You give it a plaintext buffer and
> it pads it to a multiple of 8 bytes using PKCS5, encrypts it in 3DES
> CBC mode and adds a MAC. I understand about 3des/CBC and PKCS5 but
> am not sure of how the MAC is supposed to be computed, and I'm trying
> to code an interoperable implementation.
>
> Does anyone know if there's a standard way to do this?
U.S. National Institute of Standards and Technology,
NIST FIPS PUB 113, "Standard on Computer Data Authentication,"
U.S. Department of Commerce, May 1985.
http://www.itl.nist.gov/div897/pubs/fip113.htm
with DES replaced by 3DES (and preferably with independent 168-bit keys
for the cipher and MAC). *However*, if you use that standard, you should
prepend the plaintext length to the plaintext before encrypting and
MAC'ing, and check it on decryption.
A common variant is to encrypt the final CBC result again to give
the MAC, although that's not what FIPS 113 specifies.
Normally the MAC is applied to the ciphertext, but your module might
apply it to the plaintext (probably after performing the PKCS#5 padding).
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOYF3kjkCAxeYt5gVAQE7PQf/Vlr0FV+06sm5q1CKmEOrtlmTL++YXLI4
P8aPUjcFAgc55JBnFpGXZu4o2/z6sZzJGBOO0MatA7k4h8cGB3IlrD9eLYqgAyrm
nmNwLiHaJrIt1q5cvgwmw6ui8ODPM8jkTIYDgBOtDhlXyA/kUHflhoq0pgm+9uak
8/l8NmlQyrt5+LQJQYsqzNwM+kDDv0QbY32DDqvqjK4iz+I9iwhAHjEeulgmDrch
bTBExmYDNf4fClxDD81/WEopb5jpQ9nUgtOEILNWDj9Etf71UKyr/Ice2eDeEmXL
VTY6A/GVzFa8854wm+I3WrcC5ML//R1AsDeOrrfzPfQi5yAj8Tsd1w==
=3G6x
=====END PGP SIGNATURE=====
------------------------------
Date: Fri, 28 Jul 2000 14:25:21 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: counter as IV?
=====BEGIN PGP SIGNED MESSAGE=====
"Douglas A. Gwyn" wrote:
> This is somewhat related to the RC4 discussion thread,
> but I want to focus on one specific issue in this new thread.
>
> Consider the scheme:
> secret key K established
> counter N, init 0
> for each plaintext block Bi:
> encrypt Bi using key (K XOR N) in algorithm E
> increment N
>
> N replaces the usual random Initialization Vector and is used
> only to prevent a replay attack within the session. (A new
> secret key K is securely established for each session.)
Depending on the cipher, this is potentially vulnerable to
related-key attacks, and I would recommend against it. A related-
key attack is one in which the keys used for different messages
or blocks are unknown, but have a known relation to each other
(e.g. known XOR-differences for the scheme proposed above).
A number of ciphers that otherwise appear to be secure (e.g.
DESX, 3-Way, RC2, TEA), have been found to have security
weaknesses against this type of attack.
Another reason not to use related keys is that most (maybe all?)
of the formal models proposed to analyse the security of ciphers,
assume that keys are chosen randomly or pseudo-randomly. This arguably
isn't a problem with the models, since it is normally easy to avoid
related keys at the protocol level.
> Assume the encryption E is sufficiently secure against
> known-plaintext attack, for example Skipjack.
Note that SKIPJACK has a very simple key schedule (actually I
was quite surprised by this when it was published). I haven't
seen any analysis of its resistance to related-key attack, but
that key schedule doesn't inspire me with confidence.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOYGJcDkCAxeYt5gVAQFkqQf+Mm3woVYNCeygB3JPJMaOP6VxAe7Kvcri
8drxreFNmGUtp7XpwYwYoXEoTgqdrRLCSS3cjQAIRZ9xDBHPCrlCvft58HcW3UGF
A7ZsnPy4g0EvgDpDFAbyQM6dOPF39rHDS8B5RLockPa8VQ/DALNcttGVhQtywNTL
JhjTbMpApEhX+xzsjVR3NpJpjBNTpH6eAEtYjPP03XfG/Xjpk7DtjXZLcDPxPLJz
t85E9TfEmZjyC9i8y2qR34k6Dkt1AqZQIlMTnDiNx3NVzjfrBVLga/dIcUTLww6R
lg9y2WRiG4l74gPV0hvOMN05GEru98vHUfi5pIK9L37mv71ZedgLCA==
=rbq5
=====END PGP SIGNATURE=====
------------------------------
Date: Fri, 28 Jul 2000 14:28:56 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Selecting cipher - which one to use?
=====BEGIN PGP SIGNED MESSAGE=====
Mark Wooding wrote:
> 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.
Blowfish and CAST-128 have almost identical structures; the difference
is in the S-boxes. CAST-128 has S-boxes that are fixed (hence known
to a cryptanalyst) and designed to have "good" properties, whereas
Blowfish has key-dependent, pseudo-random S-boxes. I prefer the
key-dependent approach, because 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.
OTOH, the CAST-128 designers know what they're doing, and there's really
not much to choose between the two ciphers.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOYGKXDkCAxeYt5gVAQG+OQgAsV7Bk7FHAQCO30esGYUSgsT89E9UAwl4
vvQFzev407HPcuCukqZWkYbWpawaaGEjPgE+jeWPGIrp7C5NImLDlxAc+6BKR8fv
i8uYuD5l/R+RJLtOknIPv0smMp5EoVVch0vh6YXFjl0MELBVdArGBkli4pol2rqo
T011EIGrXsrQlZhdb/wEEaZKkvz8HSSfmUtDIjF1t5wNkm+wa+LWpojVhqMXabbZ
D3WUp95XETbQsqdNYpGIOOOZtZJz0QG+op/XfyoSxc6aw1++jQ4I4MM5BKPIGfwj
buMIUshZtu5Lzq7Rw4vIDC3Ek2gynqiwyQleozgxS/uKxVfE7ntU/A==
=/6c+
=====END PGP SIGNATURE=====
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Enigma
Date: Fri, 28 Jul 2000 02:27:49 +0000
John Savard wrote:
>
> On 27 Jul 2000 19:07:02 GMT, [EMAIL PROTECTED] (JPeschel)
> wrote, in part:
>
> >You can find Enigma source code and executables, as well
> >as Enigma links on the "Historical" page of my web site.
> >You'll also find Jim Gillogly's paper describing his ciphertext-
> >only attack on Enigma.
>
> That reminds me: does he have a web site? I recently changed a mention
> of David Wagner into a link. (I still add a few little things here and
> there to my web pages.)
No, not at present. I'll let you know.
--
Jim Gillogly
Sterday, 5 Wedmath S.R. 2000, 02:27
12.19.7.7.9, 10 Muluc 12 Xul, Fifth Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: What is DES3mCBCMACi64pPKCS5?
Date: 28 Jul 2000 02:27:41 GMT
In article <[EMAIL PROTECTED]>,
David Hopwood <[EMAIL PROTECTED]> wrote:
> U.S. National Institute of Standards and Technology,
> NIST FIPS PUB 113, "Standard on Computer Data Authentication,"
> U.S. Department of Commerce, May 1985.
> http://www.itl.nist.gov/div897/pubs/fip113.htm
>
>with DES replaced by 3DES (and preferably with independent 168-bit keys
>for the cipher and MAC). *However*, if you use that standard, you should
>prepend the plaintext length to the plaintext before encrypting and
>MAC'ing, and check it on decryption.
Thanks, I also found a description of CBC-MAC in FIPS pub 81, which
describes the standard DES chaining modes. Why do you need to prepend
the length? Deleting blocks would make the MAC come out wrong, as far
as I can see.
>Normally the MAC is applied to the ciphertext, but your module might
>apply it to the plaintext (probably after performing the PKCS#5 padding).
Aha, this is the part I was missing. Attaching a CBC MAC of the
plaintext to a ciphertext that was encrypted in CBC mode with the same
key is insecure because of CBC mode's error recovery property:
changing a block of the ciphertext will result in a new ciphertext
with a valid MAC, that decrypts to a wrong plaintext (two blocks
changed). Applying the MAC to the ciphertext would appear to fix this
(any possible problems?) but of course it means the whole message has
to be encrypted twice.
So the following sounds reasonable, based on FIPS 81 and 113:
- Take plaintext message and pad with PKCS5
- Encrypt the padded plaintext in CBC mode with a random IV.
Ciphertext is the IV followed by the CBC output.
- Take the ciphertext and encrypt it *again*, in CBC mode with IV=0.
The last block of the output is the MAC. Discard the rest of the output.
I guess I'm going to have to experiment with the module to figure out
exactly what it's doing. Unfortunately I can't do that today, because
I've lost one of the cables and will have to find it or buy another one
when the stores open tomorrow. Sigh.
Someone else said the mode is signature-only, i.e. there's no cipher
output. I hope that's incorrect. I'd like to be able to get an encrypted
and authenticated ciphertext from a plaintext in a single module operation.
Paul
------------------------------
** 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
******************************
