Cryptography-Digest Digest #690, Volume #12 Sat, 16 Sep 00 02:13:01 EDT
Contents:
Re: "Secrets and Lies" at 50% off (JPeschel)
Re: "Secrets and Lies" at 50% off (Tom St Denis)
Re: Music Industry Offers US$10K for cracking their encryption system (Mack)
Re: Intel's 1.13 MHZ chip ("Trevor L. Jackson, III")
Re: 20 suggestions for cryptographic algorithm designers ("Trevor L. Jackson, III")
Re: Lossless compression defeats watermarks (John Savard)
Re: 20 suggestions for cryptographic algorithm designers (Rob Warnock)
Re: Disappearing Email redux (Dan Kegel)
Re: 20 suggestions for cryptographic algorithm designers (David Hopwood)
Re: 20 suggestions for cryptographic algorithm designers (David Hopwood)
Re: "Secrets and Lies" at 50% off (John Savard)
Re: Lossless compression defeats watermarks (Matthew Skala)
Re: Intel's 1.13 MHZ chip (Jerry Coffin)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: "Secrets and Lies" at 50% off
Date: 16 Sep 2000 01:28:51 GMT
Tom St Denis [EMAIL PROTECTED] writes:
>In article <8pu4r4$2ie4$[EMAIL PROTECTED]>,
> "David C. Barber" <[EMAIL PROTECTED]> wrote:
>> I find Bruce's post to be On Topic for this group.
>
>If spamming about non-free cryptobooks is on topic all the power to him.
>
He is not spamming.
Whether a crypto book is free, or actually costs real money, as do most
things, is immaterial to the book's topicality.
No supper for you. Now go to your room.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: "Secrets and Lies" at 50% off
Date: Sat, 16 Sep 2000 02:44:35 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (JPeschel) wrote:
> Tom St Denis [EMAIL PROTECTED] writes:
>
> >In article <8pu4r4$2ie4$[EMAIL PROTECTED]>,
> > "David C. Barber" <[EMAIL PROTECTED]> wrote:
> >> I find Bruce's post to be On Topic for this group.
> >
> >If spamming about non-free cryptobooks is on topic all the power to
him.
> >
>
> He is not spamming.
>
> Whether a crypto book is free, or actually costs real money, as do
most
> things, is immaterial to the book's topicality.
>
> No supper for you. Now go to your room.
Bite me. SPAM is uncalled advertising. And since he doesn't support
the thread with anything intelligent it's pretty much spam.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Music Industry Offers US$10K for cracking their encryption system
Date: 16 Sep 2000 03:50:49 GMT
>http://www.msnbc.com/news/460310.asp?cp1=1
>
http://www.hackSDMI.org
But the idea is just an idea
for now. Their web site
is just a message saying
check back ...
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
Date: Sat, 16 Sep 2000 00:14:02 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Intel's 1.13 MHZ chip
Jerry Coffin wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
> [ ... ]
>
> > You have just accused important government officials of squandering
> > their agency's limited resources in a most irresponsible manner.
>
> Rather the contrary: as I said, I'm quite certain reasonable uses to
> justify the purchases were found after the fact. This happens both
> inside and outside of the government on an _extremely_ regular basis.
Especially in September (end of fiscal year).
------------------------------
Date: Sat, 16 Sep 2000 00:29:00 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: 20 suggestions for cryptographic algorithm designers
Paul Schlyter wrote:
> In article <[EMAIL PROTECTED]>,
> John Savard <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 14 Sep 2000 22:19:18 -0700, Roger Schlafly
> > <[EMAIL PROTECTED]> wrote, in part:
> >>"D. J. Bernstein" wrote:
> >>> No. Little-endian is much more widely supported than big-endian, and is
> >>> universally supported by new processors.
> >
> >> Really? I didn't think anyone used it but the Intel Pentium and
> >> DEC Alpha. Sparc, MIPS, etc are big-endian. I believe even some
> >> of the Intel processors can be wired to run big or little endian.
> >
> > The forthcoming IA-64 or Merced will have this.
> >
> > However, he is correct that little-endian is more widely used. Its
> > popularity derives from that of the PDP-11, which was the machine that
> > the early versions of UNIX ran on. So, in the 8-bit generation, the
> > 8080 and the 6502 were both little-endian, and only the 6800 was
> > big-endian.
> >
> > The PowerPC chip supports both byte orders, although it is big-endian
> > by default. But the number of people using the Sun Sparc or the MIPS
> > chip - if you don't count the people using MIPS chips in video games!
> > - and Mac computers - is indeed dwarfed by the people using the
> > Pentium.
> >
> > But that is irrelevant to the "suggestions", since the rationale for
> > big-endian is based on what goes on inside _people's_ heads, not
> > inside computers.
>
> Anyone who participates in the "holy war" of big-endian vs little-endian
> should read Gulliver's Travel's!
>
> There Gulliver did at one point encounter two people who were arguing
> about the proper way to crack an egg. The "little endians" claimed
> the egg should be cracked on the "little" end, while the "big
> endians" claimed the egg should be cracked on the "big" end.
>
> When Gulliver arrived there, these two people had been in war with
> one another over several generations about this issue. Somehow
> Gulliver managed to create peace between them (don't remember how -
> read the book if you want to know).
>
> And now, in our modern and supposedly enlightened society, there's
> again a "war" about endian-ness.
>
> We need a visit of a modern Gulliver!!!!!
>
> ====================================================================
>
> IMO endian-ness doesn't matter much. I've worked with both kinds of
> endian-ness and I find it easy enough to adapt. Little-endian is
> slightly more machine efficient, while big-endian is slightly easier
> for people to read -- but the difference is so small that it's no
> point in making any fuss about it.
>
> One way to avoid this issue completely is to return to word addressing
> in computers - then this issue would become moot. You *never* hear
> any discussion about the optimum "bit order within a byte": should the
> byte start with the least or the most significant bit?
You may not have heard that argument, but I certainly have. Consider serial
data formats. They're ordered at the bit level, so there's plenty of room for
dispute.
I will admit that the arguments tended to dwindle around the time that
single-chip UARTs appeared.
To fuel the flames, I'll offer the example of sampling the most independent
measure there is: time. Anyone who has tangled with a sextant knows that
recording the time has to be done in LE order even (perhaps especially) by
humans. This conflicts with the both the natural (written and spoken) forms of
time expressions and the ISO timestamp ordering which are both strongly BE.
But for this process BE is wrong and LE is right.
Sampling a clock register wider than the data path also has to be done in LE
order (actually a non-trivial sequence is needed to prevent undetected roll
over).
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Lossless compression defeats watermarks
Date: Sat, 16 Sep 2000 04:21:46 GMT
On Fri, 15 Sep 2000 12:55:29 -0500, Mike Rosing
<[EMAIL PROTECTED]> wrote, in part:
>If something is unique, then proof of ownership should be easy.
Yes; a watermark, unless it is used to activate some copy-inhibition
mechanism, isn't needed for Hollywood films or for, say, Miss November
1972; all these things are *matters of record*. For such things as
stock photo libraries, where one picture of the sunset in Tahiti looks
much like another, though, watermarking has a role.
The point is, though, that compression technology is not at the stage
where it will normally erase a watermark just because the watermark is
unobtrusive. The human visual processing system is far more complex
than any compression program.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Rob Warnock)
Subject: Re: 20 suggestions for cryptographic algorithm designers
Date: 16 Sep 2000 04:34:07 GMT
Paul Schlyter <[EMAIL PROTECTED]> wrote:
+---------------
| Anyone who participates in the "holy war" of big-endian vs little-endian
| should read Gulliver's Travel's!
+---------------
Alas! How quickly they forget! (*sigh*)
Actually, one should read Danny Choen's classic 1980 paper, "On Holy Wars
and a Plea for Peace", which was published in several venues (including
at least one glossy rag -- Datamation maybe?), and enshrined by the IETF
as IEN 137 <URL:http://www.op.net/docs/RFCs/ien-137>.
It was Cohen who first used the Gulliver's Travels "Endianness" wars to
describe the quivalent computer-related issue. See the Appendix to the
above-mentioned paper.
-Rob
=====
Rob Warnock, 41L-955 [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: Dan Kegel <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: alt.privacy,uk.legal
Subject: Re: Disappearing Email redux
Date: Fri, 15 Sep 2000 22:08:38 -0700
Tommy the Terrorist wrote:
>
> In article <[EMAIL PROTECTED]> Dan Kegel,
> [EMAIL PROTECTED] writes:
> >If you're worried about them holding keys for you, Disappearing Inc
> >will cheerfully sell you a keyserver appliance you can run at your
> >company. (The appliance can run without sending any data to outside
> >servers, and you should be able to run it on an isolated network if
> >you're paranoid.) That should take care of any worries about key
> >escrow and trusting third parties, shouldn't it?
>
> >All they guarantee is that the key is deleted from the servers
> >and the plugins securely, and that no software from Disappearing Inc.
> >makes plaintext copies of the key or the message.
>
> Your statement is interesting, and _might_ ameliorate the problems I
> suggested. I should point out, however, that I did not see either of the
> above points at the company Web site when I looked at it.
We haven't announced the appliance yet because it's not an official
product yet, but are very aware that some customers will need their
own keyservers, and want to satisfy that need.
> Even if a person has the server, it is still CRUCIAL and as yet
> unspecified that I can see either by you or on the Web site, is how the
> key is generated. Is there one key per message? One key per date? The
> source of randomicity --- is someone actually pressing buttons on that
> key server like in PGP to establish a random number, or does it use a
> "random" number generator?
Yes, each message is protected by its own key.
The message keys are generated by a good PRNG which is periodically reseeded
with entropy from a high quality source. I think it's up to snuff.
We plan to have a security audit done of the design at some point to
make sure it really is up to snuff.
> >Disappearing Inc's service is for use between parties that agree not
> >to archive mail. If you don't trust someone to not archive mail,
> >the Disappearing Inc. tool won't help you.
> >If you don't want a third party to archive your email, don't let them
> >get their hands on it.
>
> While this doesn't seem to relate directly to the above issues (I'm
> worried more about whether the KEYS are archived, intercepted, or
> regenerated) I still find such a statement to be rather notable in the
> context of the HTML-based interface...
To use the HTML interface, you have to have the email. You can't browse
the server to look for messages; there *aren't* any messages on the server...
So regardless of whether you have the plugin or not, if you have a
message sent from a user with the Disappearing Inc. plugin, you can
read the message. (I use Netscape on Linux to read my email, so I don't
have the plugin, but when people send me Disappearing emails, the messages
display just like regular HTML emails. It's amazing what you can do with
plain HTML.)
> P.S. Those keys deleted securely from the plugins...... how hard would
> it be for a program, say a Netscape plug-in, to (ahem) copy a diagnostic
> string from another plug-in I.E. YOUR PLUG-IN and (ahem) happen to upload
> that while sending its producer "useful diagnostic information" about
> what other plug-ins are running at a given moment? How many E-mails
> would that key unlock? I realize that PGP could be attacked (and
> probably is...) in similar ways but this plug-in idea just gives me the
> creeps, since it seems to put the information in a tightly constrained
> place and time with certain access of other code to it (I think... could
> be wrong)
We're no more vulnerable to that sort of attack than PGP, as you point out.
True security is hard to achieve; the only real way to do it is to lock
your computer up and disconnect it from the net.
The Disappearing Inc. system strikes a nice middle ground, I think, and is
easy to use while still meeting the customer's need to arrange for email
sent to friendly recipients to be securely erased after it expires,
without manual intervention.
- Dan
(one of the guys who wrote the Disappearing Inc. keyserver)
------------------------------
Date: Sat, 16 Sep 2000 04:38:24 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: 20 suggestions for cryptographic algorithm designers
=====BEGIN PGP SIGNED MESSAGE=====
Paul Schlyter wrote:
> In article <[EMAIL PROTECTED]>,
> John Savard <[EMAIL PROTECTED]> wrote:
[snip]
> > The PowerPC chip supports both byte orders, although it is big-endian
> > by default.
In particular, it can load and store 32-bit and 16-bit data in either
order with no performance penalty (as can UltraSparc). I expect this will
be the norm for new processors.
> > But the number of people using the Sun Sparc or the MIPS
> > chip - if you don't count the people using MIPS chips in video games!
> > - and Mac computers - is indeed dwarfed by the people using the
> > Pentium.
> >
> > But that is irrelevant to the "suggestions", since the rationale for
> > big-endian is based on what goes on inside _people's_ heads, not
> > inside computers.
Exactly, I'm glad someone gets the point.
> Anyone who participates in the "holy war" of big-endian vs little-endian
> should read Gulliver's Travel's!
As pointed out in the notes at the end of the IEN 137 document I cited,
the point that Swift was trying to make does not hold for byte order.
There are no interoperability issues involved either in which end an egg
is cracked at, or the religious differences between England and France
that Swift was satirising. In a network protocol or a cryptographic
algorithm, OTOH, byte order MUST be specified as part of the protocol/
algorithm. (The 'talk' protocol is an example of a failure to do this;
in that case byte order problems were visible to end-users, who needed
to use two separate programs at one point.) There are also benefits to
using the same byte order in different parts of a design (I assume we can
all agree on that?)
Given that consistency in byte order is desirable (even though it is not
strictly necessary), big-endian is the only choice that helps in achieving
that, because it is the choice that has been made for Internet protocols,
as well as some other standards relevant to cryptography. It also happens
to have some advantages arising from consistency with the Arabic number
system and conventions for written mathematical notation.
> And now, in our modern and supposedly enlightened society, there's
> again a "war" about endian-ness.
There is a minor disagreement as to what byte order to use for new designs,
when the choice is arbitrary. I would hardly call that a "war".
> ====================================================================
>
> IMO endian-ness doesn't matter much. I've worked with both kinds of
> endian-ness and I find it easy enough to adapt. Little-endian is
> slightly more machine efficient,
There is no significant difference in efficiency.
> while big-endian is slightly easier for people to read -- but the
> difference is so small that it's no point in making any fuss about it.
>
> One way to avoid this issue completely is to return to word addressing
> in computers - then this issue would become moot.
This would be a *really* bad idea. All recent networking protocols and
file formats are defined in terms of octet sequences, not word sequences.
Apart from the fact that it's far too late to change now, if they had
been defined in terms of word sequences, a lot of things would break
when the word size changed (or at least it would involve supporting
addressing using the old word size indefinitely). Also, addressing using
elements larger than an octet would introduce inefficiency in dealing
with arrays of small quantities [*], and word order would still be an
issue when dealing with integers larger than a word.
[*] Octet-based addressing already causes some efficiency when accessing
packed arrays of bits, but fortunately packed bit arrays are not used
often enough for this to make a significant performance difference.
Character-element and small integer arrays are used a lot, though.
> You *never* hear any discussion about the optimum "bit order within a
> byte": should the byte start with the least or the most significant bit?
A counterexample is the thread on bit order in the Tiger hash function,
that the "20 suggestions" article was a follow-up to. In any case,
regardless of the size that is chosen as primitive (e.g. 8 bits for
octet-based addressing), there is no way to avoid the issue of element
order for integers that are a different size to that.
=====
Since byte order is a minor side-issue compared to the other 19 and 2/3
suggestions I posted, I will clarify the offending suggestion as follows.
The old version was:
8. Number sequences and indexed variables starting with zero. If there is
a completely arbitrary choice of byte order, use big-endian. Don't use
inconsistent byte order in different parts of an algorithm (although
this needn't prevent using auxiliary functions like hashes, etc. that
internally use a different byte order to the algorithm being defined).
which becomes:
8. Number sequences and indexed variables starting with zero. If there is
a completely arbitrary choice of byte order (i.e. the cost of byte
order conversion, if necessary, would be negligable for the proposed
applications), use big-endian. Don't use inconsistent byte order in
different parts of an algorithm (although this needn't prevent using
auxiliary functions like hashes, etc. that internally use a different
byte order to the algorithm being defined), and make it clear in the
specification which order has been used.
- --
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
iQEVAwUBOcLNwDkCAxeYt5gVAQHyIwf/Wu/X3R46SBUyfisSbHVh8pvzdRX+zPnm
UmEKkZk561V3zIWtHq+676XWBc4yknmXyHqbnNkSh3tEyLxk5ZQIKiUYq9nVgZZo
ATRDXtdPBpgaDxepAeqyltLEILMWTUj/4V2PQg7dFX3cz5OdIqe19mExr0w6cleL
swHs5xpnBWF6Prqeq5O7K2DbeT9w1Bi6BNfmA8KmotxV09KYTm6/MGMX5cjgEDwv
DFrPRKgEkRpi7S7ol6VRW6SBv54OBhU9FLeQyMuftQUi/n7W/TMRE6+kc086iEnn
0L7Tvk/bUhXqspLr2u8DCP1ffBzSBoph4Tz3R4GxNNrDmOayW4WJxQ==
=nw0O
=====END PGP SIGNATURE=====
------------------------------
Date: Sat, 16 Sep 2000 04:39:32 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: 20 suggestions for cryptographic algorithm designers
=====BEGIN PGP SIGNED MESSAGE=====
Runu Knips wrote:
> David Hopwood wrote:
> > [big endian is better]
That isn't what I said.
> None of your arguments was worth anything. Little endian or
> big endian - it just doesn't matter. It has only to be clear
> which ordering should be used.
>
> Of course it would be better if all architectures would use
> the same ordering, no matter if big or little.
Which order is used by processor architectures is irrelevant
(as has already been pointed out, most new architectures have
equal support for both, although that may be constrained by the
operating system). I'm talking about the byte order used in
protocol and algorithm designs.
> We would get rid of all these problems with network messages and
> binary files. On the other hand, even experienced and good
> programmers would then start to write really ugly code which
> relies on the byte order.
>
> I prefer big endian for binary formats because one can
> read it better in binary dumps. I prefer little endian if
> I have to convert a stream of bytes into numbers because
> I can save the conversion step.
You've just said that code that relies on the byte order of the
processor is really ugly (and I agree, for code in a high-level
language). How is that consistent with then saying that you can
save the conversion step when both the processor order and the
stream order are little-endian? The code for byte order conversion
still has to be included in the source, if it is not to be "ugly,"
in order to support big-endian processors.
I also don't see any difference between a "binary format" and
a stream of numbers encoded as bytes. An encoded stream of numbers
*is* a binary format.
> But finally it doesn't matter, it is just a matter of taste.
If that point of view were followed, we would have roughly half of all
new protocol and algorithm designs big-endian, and half little-endian.
That situation is far from optimal.
- --
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
iQEVAwUBOcLNWzkCAxeYt5gVAQEObAgAiaUdFcZQgZwNOraLwhobMfsm6PJX4lcL
gQAvMJCkIC3n9/Au4ZTLhxYoHednZ+j1nA5GFsiDMTIKg7UVBNUBLyp79LZhnBO2
GJSIoVg5ofKeIcC+nkIYuAvI00aTm5Txrfdi1EfzYtEFbXUAdijnFAh3waD2qeA2
6TPMnS1ca+dYGpr4Drjedaa2fDvbJekm4YyGNH/bU3xKlG5Z5Aqsk+AIBD7NXUuI
apoN5Nl81+ozhfaq5ycZFxD0wEzk8jqwc+dD7CXGwdc2dJIevc706150GjZsj4T+
I8r87vH1gnMVxaJ/guOHJsWjQuD37KkFaj7KcDLtp527QNbFPNa6Rg==
=FBRi
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: comp.security.misc
Subject: Re: "Secrets and Lies" at 50% off
Date: Sat, 16 Sep 2000 04:48:18 GMT
On Thu, 14 Sep 2000 22:13:42 GMT, Tom St Denis <[EMAIL PROTECTED]>
wrote, in part:
>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.
>Just my two cents, and seriously no offence intended.
In a sense, you might have a point; he is flogging a book on which he
is making money. But very few people will agree with you that his post
didn't belong, because many people were going to buy this book, and
information on how to save money on it is therefore useful: it is very
different from wasting bandwith trying to push something hardly anyone
particularly wants.
However, many people will be very much tempted by your post to call
you bad names, and so on. Why?
Well: it appears obvious that your post is prompted by dismay at the
unfairness of a world where people like Bruce Schneier recieve respect
while people like David A. Scott recieve derision.
And as to how that looks to others - despite the fact that Mr. Scott's
two main points are valid in themselves (key dependent S-boxes are
good, and the larger the better; compression prior to encryption
deserves attention specifically related to encryption as an
application) - words appropriate to polite discussion fail me.
Hey, wait a minute: why does it look so bad, if Mr. Scott is famous
for advocating two _valid_ points? It isn't just a veneration of style
over substance, or respect accorded to markers of status like having a
book published.
The so-called "crypto gods" claim that the issues pursued by Mr. Scott
are minor ones. And their reasoning is valid for reasons people can
understand.
- An S-box with 65,536 or more entries limits the applicability of a
block cipher that requires it. Also, it is only as good as the key
schedule algorithm used to fill it.
- Conventional block ciphers, even without key-dependent S-boxes,
appear to approach security equivalent to the difficulty of cracking
them through brute-force search.
- Block ciphers are designed to resist known-plaintext attacks. Hence,
the importance of removing redundancy from plaintext to hamper the
task of the cryptanalyst is significantly reduced.
- Modern block ciphers have large enough keys that brute-force
searching is not practical, and so making it harder to unambiguously
identify plaintext by complicating the compression scheme seems to be
at best of marginal importance.
One can still try to raise these minor points as something that,
although of limited benefit, is worth doing because the effort
required is small, and because one can't be sure that one's ciphers
are really as strong as one thinks - so any extra precaution available
is worth considering.
But if you instead go around and loudly proclaim that everything that
isn't done your way is junk, people will make the expected response to
that. What on earth else could you possibly expect?
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Matthew Skala)
Subject: Re: Lossless compression defeats watermarks
Date: 15 Sep 2000 22:09:51 -0700
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
>The point is, though, that compression technology is not at the stage
>where it will normally erase a watermark just because the watermark is
>unobtrusive. The human visual processing system is far more complex
>than any compression program.
But by the same token, watermarking technology is not at the stage where
it can put its hidden information close enough to the perceptible part of
the signal to make it really difficult to remove. Since watermarking and
lossy compression technology both depend on the *same* body of scientific
knowledge of what parts of signals are and are not important, I never
except to see a large gap between the two technologies. I don't think
it's reasonable to suppose that watermarking will ever work much better
than it does now, which is to say, just barely.
--
Matthew Skala
[EMAIL PROTECTED] I'm recording the boycott industry!
http://www.islandnet.com/~mskala/
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Intel's 1.13 MHZ chip
Date: Fri, 15 Sep 2000 23:45:10 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
>
>
> Jerry Coffin wrote:
> >
> > I'm convinced that export bans never were effective at all. Call me
> > cynical if you will, but I've always been convinced that they were to
> > allow ignorant politicians say "ours are bigger than theirs", not to
> > protect national security at all.
>
> It apparently did reduce the flow in some measure, though.
...which is of little or no real relevance. ONE computer that ends
up in the wrong hands doing the wrong things is far more dangerous
that a 1000 computers that end up doing innocuous financial
calculations a bit faster than slower machines would have.
Anybody in a position to obtain something like weapons-grade
Plutonium to build nuclear weapons is unlikely to encounter
noticeable difficulty obtaining enough computing capability to make
use of it. If the point of the export ban is to prevent nuclear
proliferation, then it makes no sense unless it has at least some
reasonable likelihood of accomplishing that. As-is, it's much like
copy protection: it makes a big difference to legitimate users, but
virtually none to the claimed target.
> To gain impressiveness is in fact often a motivation of
> purchasing expensive exquisite things. (Ladies buy diamonds
> for that, though artificial diamonds would look almost as
> well.)
The last time I heard, manufactured diamonds had gotten to the point
that under normal circumstances there weren't distinguishable from
natural ones at all. The usual method of telling the difference
requires exposing the diamond to ultraviolet light.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
------------------------------
** 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
******************************
