Cryptography-Digest Digest #683, Volume #12 Fri, 15 Sep 00 00:13:00 EDT
Contents:
Re: "Secrets and Lies" at 50% off (Tom St Denis)
Timing Attack against key schedule? (Tom St Denis)
Re: "Secrets and Lies" at 50% off (Tom St Denis)
Decrypt an Adobe serial number? ([EMAIL PROTECTED])
Re: "Secrets and Lies" at 50% off (Christopher Biggs)
Re: "Secrets and Lies" at 50% off (Ornie Makly)
Re: "Secrets and Lies" at 50% off (Jim Gillogly)
Re: Police want help cracking code to find Enigma machine ("root@localhost "
<[EMAIL PROTECTED]>)
Re: RSA Patent -- Were they entitled to it? ("root@localhost "
<[EMAIL PROTECTED]>)
Re: RSA Patent. ("root@localhost " <[EMAIL PROTECTED]>)
Lossless compression defeats watermarks (Matthew Skala)
Re: Announcement ("Douglas A. Gwyn")
Re: Intel's 1.13 MHZ chip ("Douglas A. Gwyn")
Re: Intel's 1.13 MHZ chip ("Douglas A. Gwyn")
Re: SDMI Crypto Challenge ("Douglas A. Gwyn")
Re: 20 suggestions for cryptographic algorithm designers (David Hopwood)
Re: [Q] Design criteria for sboxes in Tiger/192 ? ("Douglas A. Gwyn")
Re: Recent crypto text ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: comp.security,comp.security.misc
Subject: Re: "Secrets and Lies" at 50% off
Date: Fri, 15 Sep 2000 01:00:35 GMT
In article <8prqqe$n65$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Bill Unruh) wrote:
> In <8prii3$sla$[EMAIL PROTECTED]> Tom St Denis <[EMAIL PROTECTED]>
writes:
>
> ]In article <[EMAIL PROTECTED]>,
> ] Bruce Schneier <[EMAIL PROTECTED]> wrote:
> ]> This is the cheapest I've seen the book. I know what the publisher
> ]> sells the book for, and FatBrain is losing money on every sale. I
> ]> have no idea if this is a temporary promotion, or how long it will
> ]> last. But I figured I should get the word out:
> ]>
> ]> http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?
theisbn=0471253111
>
> ]I know you are well intentioned but for the same reason I don't like
> ]other spammers, I would suggest that you don't do this.
>
> ]If you want to talk about your book by all means go ahead, but you
> ]really are spamming this group.
>
> ?? Spamming? He is not cross posting to thousands of groups. You can
> ignore the post. I think what you object to is the commercialisation,
> not the spamming.
> (and you have now had the message he sent out repeated in at least
two
> posts-- yours and mine.)
Well at the least he should say why I would want to buy the book.
Vanity is not enough...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Timing Attack against key schedule?
Date: Fri, 15 Sep 2000 01:03:56 GMT
I just noticed in TC6a that I have a GF multiply in the key schedule
which is stricly timing dependant on the hamming weight of the fixed
multiplicand.
Has anyone explored the idea of a key setup attack? It would be mainly
theoretical but interesting none-the-less.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: comp.security,comp.security.misc
Subject: Re: "Secrets and Lies" at 50% off
Date: Fri, 15 Sep 2000 01:02:47 GMT
In article <[EMAIL PROTECTED]>,
Jim Gillogly <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> > If I was a MS engineer posting about a new MS WALLET software (for
> > example) would you regard the post with the same respect?
>
> Certainly not. However, if you were Adi Shamir or Jim Reeds or
> Doug Gwyn posting about your new cryptanalysis book, or Frode
> Weierud or Tony Sale or David Hamer posting about your new Enigma
> book, or Ron Rivest or Don Coppersmith or Eli Biham posting about
> your new crypto algorithm design book I wouldn't be snippy about
> your not posting more detail about why I ought to buy the book.
> In particular, I didn't complain when Alfred Menezes kept telling
> us a new chapter of HAC was being posted for free, even though I
> already had the hard copy.
See a "Free chapter" is something diff. They are providing a resource
to the community. Although they are selling HAC I can goto the site
and read the entire text for free. I can't do that with Schneier's new
book (although he probably wants to so I don't hold that against him).
By your own volution spamming is ok if the right people do it? That's
kinda stupid.
> By the way, the 50% off is right, but the $4 shipping + $1 CA tax
> bumped the price up to where I only got 1/3 off. Oh, well. Beats
> Amazon or my local Borders anyway.
So what?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Decrypt an Adobe serial number?
Date: Fri, 15 Sep 2000 01:25:05 GMT
I have copies of a set of Adobe Pagemaker floppy disks but no originals
with serial number. Is the SN encrypted on the #1 install disk? If
so, how can I extract?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Crossposted-To: comp.security,comp.security.misc
Subject: Re: "Secrets and Lies" at 50% off
From: Christopher Biggs <[EMAIL PROTECTED]>
Date: Fri, 15 Sep 2000 01:40:54 GMT
Tom St Denis <[EMAIL PROTECTED]> moved upon the face of the 'Net and spake thusly:
> By your own volution spamming is ok if the right people do it? That's
> kinda stupid.
sed -e '/^/IMHO /' <<EOT
Mr. Schneier's post was not spam.
Spam is *mass* posting of *off-topic* material.
I think that (and Joel Furr's "Advertising on Usenet" howto document
at http://www.danger.com/ concurs) a small number of on-topic
announcements are OK, provided they are not explicitly forbidden by
the group charter.
EOT
--
| Christopher Biggs email:[EMAIL PROTECTED] | Linux: The choice of a GNU |
| Stallion Technologies, Queensland, Australia | Generation. |
| VoiceNet +61-7-3270-4266 Fax +61-7-3270-4245 | Mates dont let mates do DOS |
\________Send mail with "Subject: sendpgpkey" for my PGP public key. ________/
------------------------------
From: [EMAIL PROTECTED] (Ornie Makly)
Crossposted-To: comp.security,comp.security.misc
Subject: Re: "Secrets and Lies" at 50% off
Date: Fri, 15 Sep 2000 01:46:16 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
>Well at the least he should say why I would want to buy the book.
He did that back on August 7. The message ID is
<[EMAIL PROTECTED]>
This URL should take you straight to it. Watch out for word-wrap:
http://x52.deja.com/threadmsg_ct.xp?AN=655426930.1&mhitnum=0&CONTEXT=968982183.296747036
--
"Ornie Makly" is actually 5374 269801 <[EMAIL PROTECTED]>.
01234 56789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Crossposted-To: comp.security,comp.security.misc
Subject: Re: "Secrets and Lies" at 50% off
Date: Fri, 15 Sep 2000 01:55:59 +0000
Tom St Denis wrote:
> By your own volution spamming is ok if the right people do it? That's
> kinda stupid.
It wasn't spamming -- your complaint is actually that it's a commercial
advertisement. Different newsgroups have different standards for
commercials, and I don't now remember what the preference is in this one.
If you want to know more about what spam is and how it's measured, try
news.admin.net-abuse.usenet and learn about Breidbart indices and stuff.
I'm done with this one -- you get another free flame as far as I'm
concerned.
--
Jim Gillogly
Sterday, 24 Halimath S.R. 2000, 01:52
12.19.7.9.18, 7 Edznab 1 Chen, Ninth Lord of Night
------------------------------
From: "root@localhost <spamthis>" <[EMAIL PROTECTED]>
Subject: Re: Police want help cracking code to find Enigma machine
Date: Thu, 14 Sep 2000 22:07:01 -0400
"Douglas A. Gwyn" wrote:
>
> Anders Thulin wrote:
> > Considering that the text of the letter reads like some Korean
> > stereo equipment manuals do, ...
>
> Actually no, it has the characteristics of a cover text for a
> steganographic message. Unfortunately for us, the exact geometry
> on the text in the letter is probably important for decoding it.
>
> The interesting question is, why would there be a hidden message
> when the overt one seems to be sufficient?
Well it seems to be gone... Was the machine really stolen on April 1st?
-m-
--
If children don't know why their grandparents did what they
did, shall those children know what is worth preserving and what
should change?
http://www.cryptography.org/getpgp.htm
------------------------------
From: "root@localhost <spamthis>" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: RSA Patent -- Were they entitled to it?
Date: Thu, 14 Sep 2000 22:10:53 -0400
[EMAIL PROTECTED] wrote:
>
> If your work never sees the light of day, you might as well have
> never done it.
Unless your motivation for doing it has little or nothing to do with
money or fame. In that case there may be any number of other reasons
someone may do ground breaking work and never get the medal, as it
were.
>
> George
--
If children don't know why their grandparents did what they
did, shall those children know what is worth preserving and what
should change?
http://www.cryptography.org/getpgp.htm
------------------------------
From: "root@localhost <spamthis>" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: RSA Patent.
Date: Thu, 14 Sep 2000 22:14:11 -0400
Mark Wooding wrote:
>
> ajd <[EMAIL PROTECTED]> wrote:
>
> > I hear that the patent for the RSA encryption algorithm expires at the
> > end of this month.
>
> Update: RSA Security Inc. has upset party schedules all across the
> world by releasing the RSA algorithm into the public domain two weeks
> early -- that's *today*.
>
> Press release at <http://www.rsasecurity.com/news/pr/000906-1.html>.
>
> -- [mdw]
What was the point? Public relations? Something seems odd here...
--
If children don't know why their grandparents did what they
did, shall those children know what is worth preserving and what
should change?
http://www.cryptography.org/getpgp.htm
------------------------------
From: [EMAIL PROTECTED] (Matthew Skala)
Subject: Lossless compression defeats watermarks
Date: 14 Sep 2000 19:33:03 -0700
It seems to me that this should be obvious, but my impression is that most
people don't quite realize it, so I'd just like to point it out:
If a watermarking scheme works perfectly (in the sense of being
inmperceptible by humans) and a lossy compression scheme works perfectly
(in the sense of maximizing compression without harming perceptual
quality) then compressing and decompressing a signal will have the effect
of removing the watermark.
Lossy compression works by separating the information in signal into the
part humans can perceive, and the part they can't. Then it only transmits
the perceptible information and throws out the rest.
Watermarking works by throwing out some information from the signal and
replacing it with a watermark. The information so affected is supposed to
be information that humans cannot perceive.
Thus, the watermark will necessarily be in the part of the signal that is
thrown out by the lossy compression.
Going in the other direction, if you have a watermarking scheme that
survives lossy compression, then that implies some deficiency in either
the watermarking scheme or the lossy compression or both: either the
watermark is altering the perceptible part of the signal, or the lossy
compression is transmitting some imperceptible information.
The success of watermarking schemes, in a world of lossy compression,
depends upon either the user's willingness to accept signal degradation,
or the deficiencies of the lossy compression at removing spurious data.
--
Matthew Skala
[EMAIL PROTECTED] I'm recording the boycott industry!
http://www.islandnet.com/~mskala/
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Announcement
Date: Thu, 14 Sep 2000 23:32:20 -0400
Dido Sevilla wrote:
> Does anyone know what the heck this person is talking about?
Well, I *tried* to follow his technical description, which he
says is supposed to be intelligible to a "layman", but it is
difficult to understand his use of certain technical terms.
For example, right off the bat he says:
> Build two (compact) sets X and Y.
Finite compact sets are uninteresting, and infinite ones are
not buildable. So maybe "compact" is English, not topology.
Next he says:
> For simplicity, let X, following MH, be superinc in such a
> way that the subset sum of X allows 'noise' constructed by
> elements from Y. ...
MH is probably Merkle and Hellman who in 1978 proposed a
cryptosystem based on superincreasing knapsacks. (I think
that is his "superinc".) A superincreasing set means a set
of integers such that each member exceeds the sum of all
preceeding members. The "subset sum" problem does exist and
is the problem of selecting members of a given set of
integers that add up to a given total; it can be thought of
as a 0-1 integer-programming problem and is NP-complete (the
"NPc" in rosi's description). We know this better under the
name "knapsack problem". There are algorithms for solving
such problems, including some co-developed by Odlyzko (using
LLL lattice-basis reduction, a very useful piece of technology).
I don't know what he meant by "noise".
Continuing:
> Build an arbitrary mapping from the subset sums of X to certain
> subset sums of Y, such that the elements from Y contributing
> to the overall subset sum (of elements from both X and Y) can
> be 'peeled off' as the (multiple of) elements from X are
> identified and extracted (due to the superinc property of
> the elements in X).
"The subset sums of X" means the set of sums of all possible
subsets of X, which would in general have fewer than 2^N
members where N is the size of X. The peeling-off is seen
in an example:
X = { 1, 2, 5, 9, 20 } (superincreasing)
Subset sum = 26
20 <= 26 so 20 in sum, remainder = 26 - 20 = 6
9 > 6 so 9 not in sum
5 <= 6 so 5 in sum, remainder = 6 - 5 = 1
2 > 1 so 2 not in sum
1 <= 1 so 1 in sum, remainder = 1 - 1 = 0, done.
The binary code for that subset is 10101 (1 means
member in sum, 0 means member not in sum).
I don't understand how Y is supposed to get combined into this.
rosi also said:
> the underlying problem (of one of the most secure modes) is to:
> Find all m >= 0 _valid_ subset sum(s) --- given a set
> 'of high density'.
"Density" presumably refers to: the size of the set divided by
the number of bits in the largest member of the set. "High
density" would then probably mean a density beyond that for
which existing algorithms are effective. I don't know what
his criterion for "validity" might be.
I couldn't figure out from rosi's description how he expects
to turn all that into a practical cryptoalgorithm.
I think it might have been more briefly described as simply
"find a suitable hard knapsack problem".
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Intel's 1.13 MHZ chip
Date: Thu, 14 Sep 2000 23:40:58 -0400
Mok-Kong Shen wrote:
> That the PC-chips become very fast have two implications.
> First, it is possible to use lots of them to obtain rather
> cheap supercomputing power (for appropriate programs) that
> was not possible previously. (Whether supercomputers are
> to be superceded by clusters in the near future is debatable.
> But that's not the point here.) Second, because of that, the
> export bans of supercomputers to the unfriendly nations are
> no longer very effective. (I read somewhere, though, that
> the export bans as such were at no time absolutely effective
> as a matter of fact.)
The bans were based on the notion that good supercomputers
made it easier to design nuclear weapons etc., which was
very likely true at one time.
Loosely coupled toy computers like PCs were never real
competitors for true supercomputers, because the latter
gained synergy from tight coupling and extremely high I/O
bandwidth. However, for certain classes of problems,
namely those for which parallel computation can proceed
for quite a ways without any communication between
processing nodes, loosely coupled arrays can be effective.
At BRL, early on we acquired an array of high-end Silicon
Graphics multiprocessors for distributed ray-tracing
applications; each ray (pixel) required considerable
computation that did not involve knowing anything about
other rays (pixels), so the interprocessor communication
costs were relatively unimportant in that application.
But for a massive finite-element model, computations at
one "node" percolate to other nodes, so distributing such
a computation would be a mistake; a real supercomputer is
desired.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Intel's 1.13 MHZ chip
Date: Thu, 14 Sep 2000 23:49:10 -0400
Jerry Coffin wrote:
> Then again, I'm convinced that the NSA buying as many Crays and such
> as it did was largely for the same reason. They undoubtedly found
> reasonable uses for them afterwards, but I think the original
> purchases were done because DIRNSA wanted things to show off to the
> other generals when they came through on tours.
> ... I strongly suspect a lot of the
> REAL reason they cancelled the orders was that Cray IV's were enough
> smaller than they just didn't LOOK so impressive anymore...
You have just accused important government officials of squandering
their agency's limited resources in a most irresponsible manner.
Do you have evidence for that accusation? How many generals "came
through on tours", and why would DIRNSA think it important to show
them big computers instead of good intelligence production?
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: SDMI Crypto Challenge
Date: Thu, 14 Sep 2000 23:52:23 -0400
Jim Gillogly wrote:
> ... I don't know
> whether they're planning to make the algorithms and/or source code
> available, or whether it's another of these bogus CYA "Here's some
> content, can you read it?" challenges. In any case, they're allowing
> only three weeks, so I'm guessing they aren't hoping for real information.
Quite often, such things are done so the purveyor can then assure
their customers that nobody was able to break their stuff, i.e.
false feeling of security used as a marketing tool.
------------------------------
Date: Fri, 15 Sep 2000 03:34:58 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: 20 suggestions for cryptographic algorithm designers
=====BEGIN PGP SIGNED MESSAGE=====
"D. J. Bernstein" wrote:
> David Hopwood <[EMAIL PROTECTED]> wrote:
> > If there is a completely arbitrary choice of byte order, use big-endian.
>
> No. Little-endian is much more widely supported than big-endian, and is
> universally supported by new processors.
In the sense that new processors typically support switchable byte order,
yes. It is the operating system that determines how that switch is set,
though.
Note that it's typically only possible to take advantage of the algorithm
byte order matching the processor byte order, when you have word-aligned
data. Potentially unaligned data generally needs to be accessed as bytes
(assuming that a byte is an octet), and converted to integers using shifts
and ors, in which case the byte order of the processor is irrelevant.
My recommendation to select big-endian byte order when there is an
arbitrary choice was not based on efficiency; I don't think that the
cost of byte order conversion is a significant concern for most
applications. Where it is a concern (perhaps for very fast stream ciphers,
for example), it is easy to define two variants of the cipher, and mark
which byte order has been used with the ciphertext. New and recent
processors usually have an instruction that swaps the byte order of a
word in one primitive operation, in which case the conversion cost (in
and out of an algorithm) would be *at most* half a cycle per byte.
The arguments in favour of big-endian are:
+ Big-endian matches the combination of
- the digit ordering used in the Arabic-based number system,
- mathematical notation where sequences are written left-to-right.
E.g. the base 10 big-endian representation of 1234 is the sequence
[1, 2, 3, 4], as opposed to [4, 3, 2, 1]. This means that people
used to modern mathematical notation (which is based on Indo-European
languages and the Arabic number system), generally find big-endian
order more natural.
+ As a consequence of the previous point, hex dumps can be read
independently of the size of elements. For example,
Big-endian:
01234567 89ABCDEF // 32-bit words
0123 4567 89AB CDEF // 16-bit words
01 23 45 67 89 AB CD EF // octets
Little-endian:
67452301 EFCDAB89 // 32-bit words
2301 6745 AB89 EFCD // 16-bit words
01 23 45 67 89 AB CD EF // octets
Also note the inconsistency involved in using little-endian order
when octets are still written in hex with the most significant
nybble first.
+ Internet protocols almost universally use big-endian conventions.
+ Almost all standards commonly used to specify representations for
cryptographic objects, e.g. P1363, OpenPGP, ASN.1-based standards, etc.
use big-endian conventions.
+ As pointed out in [1], little-endian architectures and protocols are
often not entirely consistently little-endian, whereas big-endian
designs tend to be consistently big-endian.
and for little-endian:
+ Little-endian order has a slightly more elegant expression for the
value of a number in terms of its elements:
x = Sigma[i = 0..k-1](base^i * x_i)
instead of
x = Sigma[i = 0..k-1](base^i * x_{k-1-i})
OTOH it's quite easy to use this convention for bit numbering (i.e.
the least significant bit is bit 0) even with big-endian byte order,
and IME that does not lead to confusion.
+ The most widespread personal computer architecture uses a little-endian
processor family (x86).
IMHO the arguments for big-endian order are more compelling. Note that
the main argument in [1] was for a single order to be chosen and used
consistently. If there is any candidate for a consistent byte order, at
least in Internet applications, then it is big-endian.
[1] Danny Cohen,
"On Holy Wars, and a Plea for Peace,"
IEN 137, 1 April 1980.
ftp://ftp.isi.edu/in-notes/ien/ien-137.txt.3
- --
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
iQEVAwUBOcGKFTkCAxeYt5gVAQGTcwgAmxJ5kbe0AoHH1I7a2YQbus0t07Pqx3D3
jWTYpiyq3Ft2uIVmhtUG23mBORAx0/Z65mip7W+21VMnPfQGxleaWN7ka0VVg3yF
MEGin833JMBjKzbITRSRuEMntbqBjGNVi/fwhxIor2vQMH8sSRZbCMEU9iXQAVKn
AqgPQHzfm4M+95T6PtkltXMqwleZpjxOPLQHjzL4/CjrrJdz4L00b0jdPPDuR1of
sap1WO0hgreZhvvEw5y0WvHtybYn+ecnbJGLna6GyJa1DU2vtSsNKUC4LoIORREQ
ulhTNp+MNRHHWjHYxNBuGXdJ2YQ45ZueSqCN0ylLcqwXVUcOs+XFqA==
=H0c3
=====END PGP SIGNATURE=====
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: [Q] Design criteria for sboxes in Tiger/192 ?
Date: Fri, 15 Sep 2000 00:02:58 -0400
Tim Tyler wrote:
> I was talking about the criteria for the selection of the DES s-boxes
> which - AFAIK - were subsequently made public.
Yes, eventually they were, after much of their structure had
been discovered by public researchers.
Not all of the analysis technology has been divulged, although
gradually it is being rediscovered by public researchers. My
best guess is that when the 50-year mark arrives, it might be
safe to declassify the DES development archives, which would
turn up some interesting history but, by then, no undiscovered
technology.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Recent crypto text
Date: Fri, 15 Sep 2000 00:07:03 -0400
David A Molnar wrote:
> coverage of NTRU and Arithmetica will be neat.
Be sure to check out the author's Web site, which has errata
including one about its coverage of Arithmetica.
------------------------------
** 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
******************************
