Cryptography-Digest Digest #949, Volume #12 Wed, 18 Oct 00 07:13:01 EDT
Contents:
Re: x509 (Bryan Olson)
Re: Works the md5 hash also for large datafiles (4GB) ? (Paul Schlyter)
srp-1.6.0 released (Thomas Wu)
Re: algo to generate permutations ([EMAIL PROTECTED])
Re: A question about DES (Bryan Olson)
Re: Stolen Enigma Machine Recovered ([EMAIL PROTECTED])
Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom (Frode Weierud)
Re: SALT + stream cipher (Runu Knips)
Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom ("Sam Simpson")
Re: Works the md5 hash also for large datafiles (4GB) ? ("Sam Simpson")
Comments wanted on NIST Rng Tests ([EMAIL PROTECTED])
Comments wanted on NIST Rng Tests ([EMAIL PROTECTED])
Re: How insecure is this... (Thomas Pornin)
Re: Counting one bits is used how? (Rob Warnock)
Re: On block encryption processing with intermediate permutations (Mok-Kong Shen)
Re: Comments wanted on NIST Rng Tests (Mok-Kong Shen)
----------------------------------------------------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: x509
Date: Wed, 18 Oct 2000 08:07:57 GMT
Antonio Merlo wrote:
> Does anybody know why it is included algorithmIdentifier
> on the certificate date if it is present on data signature?
> Currently this information is duplicated on all
> certificates and I don't know why?
[That is, why does the identifier of the signing algorithm
appear both inside and outside the data under the
signature?]
I've wondered about that. If anyone knows of some attack
defeated by identifying the signing algorithm inside the
signed message, please tell.
For now my theory is that whether the identifier is inside
or outside the signed data does not matter. I've several
times observed an insidious phenomenon when a committee
considers a choice that should be arbitrary: without a
persuasive argument on either side, they cannot make up
their collective mind. Thus I suspect the identifier
appears both places not only despite the fact that either
one would be fine, but _because_ either one would be fine.
Or perhaps it's intended as a convenience feature, or I
could be overlooking something. I wait to be corrected.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Works the md5 hash also for large datafiles (4GB) ?
Date: 18 Oct 2000 09:04:43 +0200
In article <[EMAIL PROTECTED]>, John Myre <[EMAIL PROTECTED]> wrote:
> Paul Schlyter wrote:
> <snip>
>> No - the md5 algorithm is designed for files or other data structures
>> of any size greater than zero, including extremely large sizes.
> <snip>
>
> Actually, isn't the algorithm well defined even for zero input?
> I think any number of bits works, up to 2^64 - 1.
You're probably right -- one can skip the call to MD5_Update()
completely.
> (Not that I'd trust an implementation to get it right without
> checking; and few implementations allow input other than sequences
> of 8-bit bytes.)
WHAT? Most MD5 implementations I've seen so far allow input of any
length....
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: srp-1.6.0 released
Date: 18 Oct 2000 01:47:56 -0700
Version 1.6.0 of the SRP distribution has been released. This latest
release brings the SRP library into full conformance with RFC 2945
and adds safe parameter checking on the client side, in addition to
bugfixes and portability enhancements.
Clients using existing versions of the distribution are strongly
encouraged to upgrade, as these legacy clients allowed potentially
unsafe parameters to be used in the protocol.
The SRP distribution is an Open Source implementation of SRP, a strong
password authentication protocol designed to resist active and passive
attacks against passwords, even when the passwords are of low entropy.
SRP offers mutual authentication and session key exchange, which can
be leveraged to provide data integrity and confidentiality.
The SRP distribution includes complete C and Java library support,
along with secure Telnet (RFC 2944) and FTP support. 128-bit session
encryption support is included, along with a set of password management
utilities.
http://srp.stanford.edu/
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: algo to generate permutations
Date: Wed, 18 Oct 2000 08:22:27 GMT
In article <[EMAIL PROTECTED]>,
Richard Heathfield <[EMAIL PROTECTED]> wrote:
> for the input aaa, I get six outputs - i.e. the first 'a'
> is considered to be different from the second 'a' and the third 'a'.
I just took a stab at generating only distinct arrangements,
http://burtleburtle.net/bob/c/anagram.c
It places all occurences of one letter, then all occurences of the
next, and so forth. It's bigger and slower than pure permutations,
although it only does work proportional to the number of distinct
arrangements. It's still not lexicographic order.
- Bob Jenkins
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: A question about DES
Date: Wed, 18 Oct 2000 08:38:15 GMT
Massimo wrote:
> I'm an italian computer science student and I'm a beginner in
cryptography.
> I've the following question: what's the reason 'cause, in last DES
step,
> they applied the inverse of the initial permutation to the 64 bit
block
> instead of a different kind of permutation ?
Why the initial and final permutations at all is a mystery.
They serve no end.
Given an initial permutation, it's inverse is used as the
final permutation so that the same hardware circuitry can
both encrypt and decrypt. The only difference between the
operations is the direction of rotation of the key
registers, and consequently the reversal of the order of the
round keys.
So can using the inverse of the initial permutation be
clever even though both are pointless?
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Stolen Enigma Machine Recovered
Date: Wed, 18 Oct 2000 08:51:52 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Jim wrote:
> > The Enigma cipher machine which was stolen from the museum
> > at Bletchley Park has turned up.
> >
> > It was sent by post to the television 'personality'
> > Jeremy Paxman.
>
> ... but without the reflector and 3 of the 4 rotors [*].
> Curiouser and curiouser.
>
> Apparently the parcel had sat in the Newsnight offices for about a
week
> (IIRC) before being opened.
>
> [*] which for some reason were called "coding wheels" by Christine
Large
> (head of BP), and Paxman.
In the Daily Telegraph report it says:
===QUOTE===
The device, which was posted in a wooden box with a leather handle and
wrapped in three layers of packing and bubble wrapping, has yet to be
authenticated by Bletchley Park. It was sent without its three main
rotors, the key enciphering component, and the Bletchley Park Trust was
told these would only be handed over in return for �25,000
compensation. The rare, four-rotor version of the wartime machine used
by German military intelligence is worth �100,000 intact but much less
without its rotors.
Christine Large, the trust's chief executive, said that the "new owner"
had contacted her yesterday to give his instructions for a handover of
�25,000, which he claims was paid for the machine, in exchange for the
rotors.
===END QUOTE===
Chris
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Frode Weierud)
Crossposted-To: talk.politics.crypto
Subject: Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom
Date: 18 Oct 2000 09:04:31 GMT
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] (John Savard) writes:
>There's even the chance that removing the rotors reduced the Enigma's
>weight enough to make returning it in secret somehow easier - either
>by making it easier to carry, or because the thief was afraid postal
>authorities had been given its weight to watch for it with.
I doubt very much it is a question about reduced weight, but it is
indeed a serious reduction in the machine's value. In reality they
have only got half a machine back, or perhaps even less. The Abwehr or
G-machine rotors are of a very special design and no other Enigma rotors
can take their place.
I know of several people who have Enigma machines without rotors and
they have not had any great success in selling their machines even at
a relatively low price. A machine without rotors is of no great interest.
So I expect we will hear from the "Master" again. He probably is still
in business and want to recover his ransom. Or perhaps he is a Puppet
Master?
For a review of news articles etc. you might wish to visit my Abwehr
Theft Web page at:
http://frode.home.cern.ch/frode/crypto/BPAbwehr/Abwehr_theft.html
Frode
--
Frode Weierud Phone : +41 22 7674794
CERN, SL, CH-1211 Geneva 23, Fax : +41 22 7679185
Switzerland E-mail : [EMAIL PROTECTED]
WWW : home.cern.ch/frode/
------------------------------
Date: Wed, 18 Oct 2000 11:17:19 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: SALT + stream cipher
Joseph Ashwood wrote:
> Now about Toms comment to use a hash, that's up to you, there are certainly
> at least two sides the argument. First, the hash cannot increase the entropy
> of the salt+passphrase, and since it can decrease it, it shouldn't be used.
The reason for using a hash before the initialization of RC4 is in the
properties of the RC4 initialization, not in the properties of the
hash itself. I.e. the RC4 initialization is not that good, therefore
you should (a) hash key and initialization vector and (b) discard the
first some douzen bytes of output of the cipher.
> The second side, and the (IMNSHO) more reasonable side is, even if the
> stream cipher is broken, if you used a hash the attacker cannot recover your
> passphrase, besides the likelihood of loss of entropy in a hash like SHA-1
> is trivial until you reach at least 80 characters, it's safe to disregard
> it, with SHA-256 it's around 128 characters.
Besides, you can use SHA-512 for hashing, which should offer quite
enough bits under all conditions.
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom
Date: Wed, 18 Oct 2000 09:03:24 +0100
Or maybe the "thief" is showing good faith by returning the unit and
will now be paid the 25,000 UKP for safe return of the remaining
items (e.g. the rotors!).
Quite amusing really: the device had sat unopened in the BBC until Mr
Paxman was next in the office.....
--
Sam Simpson
http://www.scramdisk.clara.net/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
John Savard <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Wed, 18 Oct 2000 01:25:23 +0100, Mathew Hendry
> <[EMAIL PROTECTED]> wrote, in part:
>
> >Three of the four rotors are missing. (Why steal only those?)
>
> Maybe the thief just had trouble cleaning his prints off of them?
>
> Or - since an early British newspaper article claimed that there
were
> suspicions one disgruntled member of a dissident faction among the
> staff at Bletchley had engineered the theft to discredit the
current
> management - perhaps the rotors will be delivered, one each, to
other
> media outlets for maximum publicity.
>
> There's even the chance that removing the rotors reduced the
Enigma's
> weight enough to make returning it in secret somehow easier -
either
> by making it easier to carry, or because the thief was afraid
postal
> authorities had been given its weight to watch for it with.
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Works the md5 hash also for large datafiles (4GB) ?
Date: Wed, 18 Oct 2000 09:17:20 +0100
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:8sht3j$pui$[EMAIL PROTECTED]...
<SNIP>
> Oops... sorry. At any rate who will use a 512-bit hash anyways?
>
> Tom
The same people that require AES with a 256-bit key - don't forget
that a 256-bit hash is "vulnerable" to some attacks in 2^128
operations (due to the birthday paradox). So, for a balanced system,
I guess it can make sense to use a 512-bit hash with a 256-bit block
cipher?
Rgds,
--
Sam Simpson
http://www.scramdisk.clara.net/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
------------------------------
From: [EMAIL PROTECTED]
Subject: Comments wanted on NIST Rng Tests
Date: Wed, 18 Oct 2000 09:26:52 GMT
Hi all,
A new version of the NIST Rng testing software has now been released
with fixes for the overlapping and non overlapping templates tests.
The code compiles on a Sun machine running Solaris and results obtained
for the test data provided by NIST matches those printed in the pdf
manual.
Have you got any views, comments on this test suite given by NIST? How
does it compare to DIEHARD? Is it likely to become a standard in testing
Rngs for cryptographic applications?
Brice.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: sci.crypt.random-numbers
Subject: Comments wanted on NIST Rng Tests
Date: Wed, 18 Oct 2000 09:26:31 GMT
Hi all,
A new version of the NIST Rng testing software has now been released
with fixes for the overlapping and non overlapping templates tests.
The code compiles on a Sun machine running Solaris and results obtained
for the test data provided by NIST matches those printed in the pdf
manual.
Have you got any views, comments on this test suite given by NIST? How
does it compare to DIEHARD? Is it likely to become a standard in testing
Rngs for cryptographic applications?
Brice.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: How insecure is this...
Date: 18 Oct 2000 09:40:03 GMT
According to <[EMAIL PROTECTED]>:
> There is no doubt that when using a symetric cipher, one should not
> use the standard ECB-mode, but something more elegant like CBC.
Not quite. CBC is good for two things:
-- "randomize" inputs to the cipher; this is because most encrypted
data will have some identical blocks, and you don't want to show this
equality between some blocks.
-- build a MAC, so you can detect tampering with your data.
However, for some applications you do not fear tampering, or you have
already another mechanism for that. And there are other ways to adress
randomization.
The problem with CBC is that, before encrypting one block, you need the
result of the preceeding block. This prevents efficient pipelining or
bitslice implementations. Depending on your application, CBC can slow
you down to an unacceptable rate.
--Thomas Pornin
------------------------------
From: [EMAIL PROTECTED] (Rob Warnock)
Subject: Re: Counting one bits is used how?
Date: 18 Oct 2000 10:23:35 GMT
David Wagner <[EMAIL PROTECTED]> wrote:
+---------------
| Rob Warnock wrote:
| >Well, yes, dot-products are used sometimes in GF math, but LFSRs are more
| >likely to use N-way parity, that is, "popcount(x)&1", in the feedback terms.
|
| Are you sure? I'd say that LFSRs are more likely to use popcount(r&t)&1,
| where r is the state of the shift register and t [is] the feedback taps.
+---------------
Hmmm... I think we're saying the same thing, actually. My "x" *is*
your "r&t" with the constant zeros compressed out, because I don't
[usually] consider the feedback taps to be a "variable" [once I've
chosen a polynomial], so the bits of my "x" are only those terms
that *are* fed back.
By the way, go look at some texts that actually show you the wiring
diagrams. There are basically two flavors: one that computes a single
parity of selected taps and feeds that in as the input (which is what
both of the above methods implement); and one which more directly maps
the notion of computing the "residue modulo the generator polynomial",
which takes the *output* of the register and feeds it back into multiple
places, each of them being an XOR between one of the intermediate stages
and the next. These compute the same sequence iff you use reciprocal
polynomials for the two. [That is, P(x)(mod G(x)) for one way of wiring,
and 1/P(x)(mod G(x)) for the other ... I think.]
While the first [input = parity(feedbacks)] is certainly simpler in
hardware, the second is, as I said, closer to the "modulo a generator
polynomial" notion *and* is easier to implement in software, oddly
enough.
-Rob
p.s. Exercise for the reader: Given a primitive polynomial over GF(2),
how do you implement in software a CRC-style checksum using that polynomial
such that you can feed multiple input bits into the checksum in a single
"round" (so to speak). Hint#1: If the polynomial is of degree "m+1", and
you want to input "k" data bits at a time, you're allowed to precompute
an "m"-bit wide table with "2^n" entries in it. Hint#2: If "integers"
in your software are at least "m" bits wide, a single "round" needs only
two shifts, two XORs, and one lookup in the table to correctly "shift in"
all "k" data bits.
Bonus question: Can you change one of the shifts into an AND?
If so, how, and what has to change? And when might you want to do that?
Or if not, why not?
=====
Rob Warnock, 31-2-510 [EMAIL PROTECTED]
Network Engineering http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Wed, 18 Oct 2000 12:55:37 +0200
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
>
> > I like to ask your favour to explain (excuse me, once again)
> > but in a radically simplified case, namely on a four round
> > DES (two cycles) with a single assumed random permutation
> > (not used as known information) and with (u,u) as the single
> > type of chosen plaintext.
>
> Why the special form (u, u)?
>
> If you want to do the specific exercise, you'll need to
> understand the attack, and then study the DES round function
> in excruciating detail. I'd suggest you look at linear
> cryptanalysis to decide how many sample texts to work with
> versus how much to guess-and-check.
>
> > Could you give the procedure in
> > such concrete details, in particular the choice of u (if
> > anything special) and the determination of the locations of
> > the siblings desired for processing and the method of
> > solutions of the equations involving these, so that one can
> > actually write a computer program to perform exactly the
> > attack and be able to deduce the key bits?
>
> I think my description is sufficiently precise to support the
> attack up to the point where it would DES specific in your
> example. At that point it will be up to you. Can you tell me
> the first step that is not clear to you?
Yes. You set up equations involving the 'siblings'. How
can get these from a bunch of blocks of ciphertexts?
Shall I try them randomly, assuming that these are the
right ones? That's the very first stumbling stone for
me, unfortunately.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Comments wanted on NIST Rng Tests
Date: Wed, 18 Oct 2000 13:07:12 +0200
[EMAIL PROTECTED] wrote:
>
> Have you got any views, comments on this test suite given by NIST? How
> does it compare to DIEHARD? Is it likely to become a standard in testing
> Rngs for cryptographic applications?
I have not used the suite but it seems to be based on lots
of careful work with knowledge of existing packages like
Diehard and hence can be expected to be superior to these.
To the last question, my estimate is yes (if not a standard
then so much employed that it will be defacto one).
M. K. Shen
------------------------------
** 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
******************************
