Cryptography-Digest Digest #848, Volume #9 Thu, 8 Jul 99 07:13:03 EDT
Contents:
Re: optimizations (for feedback PRNGs...) (S.T.L.)
Re: Impossible to decrypt files encrypted with attached program - encrypt.exe [0/1]
(S.T.L.)
Re: Impossible to decrypt files encrypted with attached program - encrypt.exe [0/1]
([EMAIL PROTECTED])
Re: MP3 Security Requirements? (Scott Nelson)
Re: MP3 Piracy Prevention is Impossible ([EMAIL PROTECTED])
Re: MP3 Piracy Prevention is Impossible (Scott Nelson)
Re: optimizations (for feedback PRNGs...) (Terje Mathisen)
Re: Can Anyone Help Me Crack A Simple Code? (Paul Schlyter)
Re: Is it possible to combine brute-force and ciphertext-only in an attack? (Bo Lin)
Re: Summary of 2 threads on legal ways of exporting strong crypto (Mok-Kong Shen)
Re: Summary of 2 threads on legal ways of exporting strong crypto ("Douglas A. Gwyn")
Re: Summary of 2 threads on legal ways of exporting strong crypto (Mok-Kong Shen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (S.T.L.)
Subject: Re: optimizations (for feedback PRNGs...)
Date: 08 Jul 1999 04:57:50 GMT
<<To the best of my knowledge the code has to work>>
So, could one export PGP code missing a crucial "A=0" (in relevant C speak, of
course) somewhere?
Moo-Cow-ID: 75 Moo-Cow-Message: skills!
-*---*-------
S.T.L. ===> [EMAIL PROTECTED] <=== BLOCK RELEASED! 2^6972593 - 1 IS PRIME!
Quotations: http://quote.cjb.net Main website: http://137.tsx.org MOO!
"Xihribz! Peymwsiz xihribz! Qssetv cse bqy qiftrz!" e^(i*Pi)+1=0 F00FC7C8
E-mail block is gone. It will return if I'm bombed again. I don't care, it's
an easy fix. Address is correct as is. The courtesy of giving correct E-mail
addresses makes up for having to delete junk which gets through anyway. Join
the Great Internet Mersenne Prime Search at http://entropia.com/ips/ Now my
.sig is shorter and contains 3395 bits of entropy up to the next line's end:
-*---*-------
Card-holding member of the Dark Legion of Cantorians, the Holy Order of the
Catenary, the Great SRian Conspiracy, the Triple-Sigma Club, the Union of
Quantum Mechanics, the Polycarbonate Syndicate, the Roll-Your-Own Crypto
Alliance, People for the Ethical Treatment of Digital Tierran Organisms, and
the Organization for the Advocation of Two-Letter Acronyms (OATLA)
Avid watcher of "World's Most Terrifying Causality Violations", "When Kaons
Decay: World's Most Amazing CP Symmetry Breaking Caught On [Magnetic] Tape",
"World's Scariest Warp Accidents", "World's Most Energetic Cosmic Rays", and
"When Tidal Forces Attack: Caught on Tape"
Patiently awaiting the launch of Gravity Probe B and the discovery of M39
Physics Commandment #13: The Electromagnetic Force Is Carried By Photons.
------------------------------
From: [EMAIL PROTECTED] (S.T.L.)
Subject: Re: Impossible to decrypt files encrypted with attached program - encrypt.exe
[0/1]
Date: 08 Jul 1999 04:43:41 GMT
<<Fortunately, there's nno attached program. If there were, you would have not
only broken the usa.net terms of service by posting binaries to a text
newsgroup, but also US federal law.>>
Note that the goofball had a two-part message, namely 0/1 and 1/1. Rest assured
that you will find said binary in part 1/1. I don't know what kind of file it
is (AOL lets me ignore such crap), but I know it's there. Fire away at this
goofball.
Moo-Cow-ID: 35 Moo-Cow-Message: Weasel.
-*---*-------
S.T.L. ===> [EMAIL PROTECTED] <=== BLOCK RELEASED! 2^6972593 - 1 IS PRIME!
Quotations: http://quote.cjb.net Main website: http://137.tsx.org MOO!
"Xihribz! Peymwsiz xihribz! Qssetv cse bqy qiftrz!" e^(i*Pi)+1=0 F00FC7C8
E-mail block is gone. It will return if I'm bombed again. I don't care, it's
an easy fix. Address is correct as is. The courtesy of giving correct E-mail
addresses makes up for having to delete junk which gets through anyway. Join
the Great Internet Mersenne Prime Search at http://entropia.com/ips/ Now my
.sig is shorter and contains 3395 bits of entropy up to the next line's end:
-*---*-------
Card-holding member of the Dark Legion of Cantorians, the Holy Order of the
Catenary, the Great SRian Conspiracy, the Triple-Sigma Club, the Union of
Quantum Mechanics, the Polycarbonate Syndicate, the Roll-Your-Own Crypto
Alliance, People for the Ethical Treatment of Digital Tierran Organisms, and
the Organization for the Advocation of Two-Letter Acronyms (OATLA)
Avid watcher of "World's Most Terrifying Causality Violations", "When Kaons
Decay: World's Most Amazing CP Symmetry Breaking Caught On [Magnetic] Tape",
"World's Scariest Warp Accidents", "World's Most Energetic Cosmic Rays", and
"When Tidal Forces Attack: Caught on Tape"
Patiently awaiting the launch of Gravity Probe B and the discovery of M39
Physics Commandment #13: The Electromagnetic Force Is Carried By Photons.
------------------------------
Date: Wed, 07 Jul 1999 12:53:53 -0400
From: [EMAIL PROTECTED]
Subject: Re: Impossible to decrypt files encrypted with attached program - encrypt.exe
[0/1]
Bob wrote:
>
> Can anyone decrypt files encrypted with the attached program?
Yes.
Can you afford my rates?
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: MP3 Security Requirements?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 08 Jul 1999 06:21:03 GMT
On Wed, 07 Jul 1999 13:51:25 -0400, Thierry Moreau
<[EMAIL PROTECTED]> wrote:
>Francois Grieu wrote:
>> [EMAIL PROTECTED] wrote:
>> > Watermarking of MP3 recorded music is kind of useless.
>>
>> Can you explain why you think this ?
>
>Basically, it's the difference between what cryptography/IT security
>might do in textbook versus real-life imperatives like common sense and
>money (the cost of suing someone).
>
>> I feel it could be usefull
>> to watermark the music with the ID of the rightfull owner(s)
>> of rights and the person the song was sold to, so that
>> - it's harder for producer X to illegaly resell a song owned by
>> producer Y, ...
>
>If producer Y is small, he doesn't have money for a lawyer. If producer
>X is small, it's not worth suing him. Otherwise, the evidence of a
>counterfeit sale can be achieved with means less expensive than
>technical evidence (e.g. ordinary witnesses of the producer X's offer is
>cheaper than expert witness of watermark facts and theory ...).
>
Why not watermark with "sensitive" information about the buyer.
(I.e. his name, credit card number and expiration date.)
Or better still, watermark with a serial number and provide a
site where you can upload a song and retrieve the sensitive
information associated with the serial number. That way you
don't even have to reveal how the water mark is concealed.
And for the ultra paranoid, water mark the song more than once,
and release the remaining marks after a random number of days
have past. Then the buyer can never really be sure all the
marks are gone.
>
>Suppose customer A is a teenager but an adult B paid her MP3 download
>with my credit card (A doesn't have a credit card and B doesn't want A
>to train himself in e-shop lifting by necessity). Who is ever going to
>sue who? There is no authentication for the purpose of copyright
>enforcement. If there was an economic incentive for this MP3 client
>account authentication, it would be a great business opportunity, so
>please tell me if I'm wrong.
>
Well, stolen credit cards are a problem, but at least the credit
card company will have some incentive to track down the thief.
Presumably it is large enough and has enough at stake to really
go after these people. Especially if they're posting the number
to the internet.
Scott Nelson
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: MP3 Piracy Prevention is Impossible
Date: 8 Jul 1999 03:12:31 -0400
Tenexus <[EMAIL PROTECTED]> wrote:
> On 30 Jun 1999 18:18:52 -0400, [EMAIL PROTECTED] wrote:
> What would happen /w digital watermarking schemes, if one were to
> purchase mutliple copies of a work and combine them? I assume these
> different works would contain different signatures, would they not?
> Consequently, if I were to digitally average multiple copies of a
> song, could I not eventually degrade these watermarks to a useless
> state? Or, am I missing something?
Heck, one could always take line_out and run it to a cassette recorder ...
but as for the watermark, if it is degraded (invalid) then the file won't
play on systems that only play files with a valid watermark/signature
(e.g. if players are built only to handle watermarked files, removing the
watermark makes them unplayable) (of course, you can play it on other
"players" -- but the record labels seem to be exerting a lot of pressure
to get "compatibility" with their systems to make that more difficult)
(only properly registered music may be playable ... giving the record
labels even more control over music distribution even by bands that would
want to freely distribute)
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: MP3 Piracy Prevention is Impossible
Reply-To: [EMAIL PROTECTED]
Date: Thu, 08 Jul 1999 06:07:54 GMT
On Thu, 08 Jul 1999 00:37:13 GMT, [EMAIL PROTECTED] (Tenexus)
wrote:
>What would happen /w digital watermarking schemes, if one were to
>purchase mutliple copies of a work and combine them? I assume these
>different works would contain different signatures, would they not?
>Consequently, if I were to digitally average multiple copies of a
>song, could I not eventually degrade these watermarks to a useless
>state? Or, am I missing something?
>
It depends a lot on the scheme.
Suppose the watermark is hidden in the playback rate -
%99.99 speed vs %100 each second. Averaging the two
songs would result in a mishmash. This particular method
can also be circumvented, but in theory a watermark can be
constructed such that in order to remove it, it's necessary
to virtually remove the song too.
Of course there's a big difference between theory and practice,
and I've yet to hear of any watermarking schemes even remotely
close to the ideal.
Scott Nelson
------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Subject: Re: optimizations (for feedback PRNGs...)
Date: Thu, 08 Jul 1999 10:19:06 +0200
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>,
> Terje Mathisen <[EMAIL PROTECTED]> wrote:
> > This can be handled at very nearly the same speed with a simple unroll
> > by 4 or 8 loop, followed with a single iteration to handle the
> > (possibly) wrapping case.
>
> But will deciding which routine to use be faster then just unrolling it
> completely?
>
> > Much simpler is to just replace the increment operation with either a
> > table lookup, or with code like this:
> >
> > x++;
> > int32 temp = (int32) x - N; // Will be negative unless no wrapping
> > needed!
> > temp >>= 31; // Turn temp into an all 1 or all 0 mask
> > x &= temp; // Wraps values >= N into 0
> >
>
> That could work nicely.
>
> The code is at
> http://mypage.goplay.com/tomstdenis/prng.html
OK, I took a look at that:
/* step the RNG and return a 32-bit value */
unsigned long arng::step()
{
unsigned long temp;
/* update */
temp = (state[x] += state[y]);
/* clock */
x = (x < 54) ? ++x : 0;
y = (y < 54) ? ++y : 0;
return temp;
}
This could be implemented directly in Pentium+ asm like this:
mov ebx,[x] ; Get X index
mov ecx,[y] ; Get Y index
; A one-cycle AGI stall here unless you can leave X and
; Y in registers all the time!
mov eax,[ebx] ; Get state[x]
mov edx,[ecx] ; and state[y]
add eax,edx ; Add
mov ecx,nextIndex[ecx*4]
mov [ebx],eax
mov ebx,nextIndex[ebx*4]
mov [y],edx
mov [x],ebx
which is ten perfectly paired instructions, using a total of 6 cycles.
A good compiler should be able to generate something very close to that:
sx = state[x];
sy = state{y];
sx += sy;
y = nextIndex[y];
state[x] = sx;
x = nextIndex[x];
return sx;
Terje
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Can Anyone Help Me Crack A Simple Code?
Date: 8 Jul 1999 09:46:51 +0200
In article <[EMAIL PROTECTED]>,
S.T.L. <[EMAIL PROTECTED]> wrote:
> <<The human eye can distinguish around 100,000 colors of visible light.>>
>
> I've actually heard figures of a few million, but less than 16 million
> and more than 100,000. (It was in connection with someone saying how
> 24bit color monitors are already overkill, and 32bit color is insane.)
This depends on how you define "different color".
Suppose you have a red color with known spectral distribution. Next,
suppose you make it brighter by a factor of 2, and the brightness
increase is the same over all wavelengths: any wavelength will become
twice as bright as earlier. Will this then be a new color, or will
it just be a brighter variety of the same color?
If you by "color" include "brightness", then we can definitely see
more than 100,000 "colors", but perhaps not 16 million, as you say
above. But then you'll get another problem: suppose you have a green
chair, and you illuminate it more strongly -- then the chair will
have changed color, since the green now is brighter.
If you, on the other hand, consider "color" as something separate
from "brightness", then the human eye cannot see more than 100,000
colors -- I've seen a figure that it can distinguish "only" some
30,000 - 40,000 colors. By this definition, the green chair will
retain its color, no matter how much it's illuminated (if we assume
we illuminate it with white light of course).
A color monitor, or TV, must of course be able to reproduce different
brightnesses as well as different colors. And the industry often
lumps toghether all possible combinations into one figure, calling
this "the number of possible colors", arriving at a figure of e.g.
16 million. Which is confusing if you consider that the human eye
can only distinguish some 30,000-40,000 different colors, and if
you forget that this 16-million-figure includes not only different
colors but different brightnesses as well.
But if you instead consider 40,000 different colors which each can
be viewed at, say, 400 different brightness levels, then you'll
end up with 16 million if you multiply these two numbers.
However, despite this "16-million-different-colors" figure often
quoted for video monitors, there are a large number of colors these
monitors are unable to reproduce. For instance all the pure spectral
(monochromatic) colors, or very saturated purple colors.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Bo Lin <[EMAIL PROTECTED]>
Subject: Re: Is it possible to combine brute-force and ciphertext-only in an attack?
Date: Thu, 08 Jul 1999 09:38:42 +0100
Morgan wrote:
> In theory, though, if you have a totally random stream, how do you
> know when you've come up with the correct key?
Shannon's famous paper, "Communication Theory of Secrecy Systems", defines
the unity distance N = H(K)/D.
The equation tells us two things. One is that if the number of possible keys
is as large as the number of plaintexts then the cipher is theoretical
unbreakable, such as the one-time pad. The other is that if the D approaches
0, i.e. the plaintext is truly random then the N approaches infinitive. As a
result, a cryptanalyst can not determine the key of a trival cipher no matter
how many ciphertexts he/she receives.
There are many aplications of encrypting a random number.
> Still thinking....
>
Some classical papers are helpful because their authors have/had been
thinking for a quite long time.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Summary of 2 threads on legal ways of exporting strong crypto
Date: Thu, 08 Jul 1999 11:32:55 +0200
[EMAIL PROTECTED] wrote:
>
> > Very detailed descriptions which one could translate one-to-one
> > to codes have already been done. If I don't err, RSA has recently
> > published a RFC on BSAFE just in that way. Someone conjectured
> > that there RSA has a mechanism for automatically converting that to
> > C and reciprocally.
>
> Exactly the point. The fact that true translation can be mechanized
> does not detract tahat a true translation is an expression of ideas, and
> thus protected speech.
Unfortunately the said conjecture has not be verified. It seems
quite unlikely that it is possible (at least for the near future)
to have a software that can convert between an ARBITRARY program
code and its faithful (useful) natural language description.
M. K. Shen
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Summary of 2 threads on legal ways of exporting strong crypto
Date: Thu, 08 Jul 1999 09:40:42 GMT
Mok-Kong Shen wrote:
> ... It seems
> quite unlikely that it is possible (at least for the near future)
> to have a software that can convert between an ARBITRARY program
> code and its faithful (useful) natural language description.
It's not very hard to convert, say, C source code to a *correct*
English procedural description. But, as perhaps with Scott19u,
the *meaning* and *reason* behind the source code may not be
evident, even to a human skilled in the programming language.
However, this seems to have little to do with the realities of
crypto export control. The simple fact is, the US Executive
keeps imposing rules of their own devising, and the people let
them get away with it. So no matter what you do to try to
export something the Administration doesn't want exported, it
might be blocked by arbitrary fiat for which there is no
effective appeal.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Summary of 2 threads on legal ways of exporting strong crypto
Date: Thu, 08 Jul 1999 11:27:13 +0200
Isaac wrote:
>
> First, mechanical translation or not, such an RFC doesn't quite meet
> any of the definitions of software as described in EAR. It's arguably
> not source code, and definitely not object or executable code. I'm
> not even sure that the government could argue that the RFC's primary
> purpose was to become source code. What applicable EAR restrictions
> are left for this RFC?
>
> Secondly, it would seem easier to make the first amendment argument
> for this RFC than it would be for ordinary source code. The
> heightened expressiveness would seem to make "purely functional"
> arguments quite silly, while the functionality is yet another step
> removed from executable code. I'd guess that the argument isn't
> so easy that all judges would find the desired conclusion inescapable,
> but it works for me. Of course my opinion is not the most objective;
> I found the "purely functional" argument silly when applied to source
> code anyway.
That the approach is legal is in my humble view beyond question,
given the experience and knowledge potential available at RSA.
As I said, this is very inconvenient for the author, there being no
software for automatically converting an ARBITRARY program in
C or other programming languages to natural language descriptions
(at least as far as availability in the public is concerned).
For the reader, who has to convert the natural language descriptions
into code and, moreover, debug the program, the inconvenience is even
higher. Anyone can see how inconvenient that is by doing an excercise
on a toy algorithm.
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
******************************
