Cryptography-Digest Digest #827, Volume #9 Sun, 4 Jul 99 00:13:06 EDT
Contents:
Re: OTP is it really ugly to use or not? (Jim Dunnett)
Re: MP3 Piracy Prevention is Impossible (Wim Lewis)
Re: Can Anyone Help Me Crack A Simple Code? ("Douglas A. Gwyn")
Re: RSA or DIFFIE-HELLMANN ("Douglas A. Gwyn")
Re: MP3 Piracy Prevention is Impossible ("Douglas A. Gwyn")
Re: Can Anyone Help Me Crack A Simple Code? (wtshaw)
Re: Kryptos article ("Douglas A. Gwyn")
Re: MP3 Piracy Prevention is Impossible (wtshaw)
Something the bit-twiddlers might like (wtshaw)
RSA Padding (S.T.L.)
Ciphers based on HASH functions ([EMAIL PROTECTED])
Re: Can Anyone Help Me Crack A Simple Code? (Jerry Coffin)
Re: Quantum Computers ("rosi")
Re: [OT] alt.security.scramdisk spamming (Unimportant)
Re: A Thought or a Quoater ("rosi")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Jim Dunnett)
Subject: Re: OTP is it really ugly to use or not?
Date: Sat, 03 Jul 1999 19:15:18 GMT
Reply-To: Jim Dunnett
Mok-Kong Shen wrote:
>
> Given a keystream K and n plausible messages M_1, M_2, .... M_n
> and one real message M_r. If we XOR all of them together to form
> the ciphertext C, what chance has the analyst to find M_r, even
> if K is not ideally random as required by the definition of OTP?
It doesn't have to be ideally random, just sufficiently
unpredictable!
--
Regards, Jim. | EATING OUT:
amadeus%netcomuk.co.uk | The Edinburgh Dining Guide
dynastic%cwcom.net | Information on the capital's finest food
nordland%lineone.net |
| http://www.spidacom.co.uk/EDG/
Pgp key: pgpkeys.mit.edu:11371
------------------------------
From: [EMAIL PROTECTED] (Wim Lewis)
Subject: Re: MP3 Piracy Prevention is Impossible
Date: 3 Jul 1999 21:40:59 GMT
In article <7lavm0$mar$[EMAIL PROTECTED]>,
Vernon Schryver <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>John Savard <[EMAIL PROTECTED]> wrote:
>>Ah, but what *can* be done is this:
>>
>>Make it impossible for mobile digital players to play MP3.
>>
>>Instead, all they will be able to play is a format that has to be
>>signed by an authorized music company...and they will only use the
>>plaintext internally.
>
>Perhaps I don't understand, because I'm not among those who walk around
>with big or little boom boxes. However, an MP3 player that uses the
>plaintext only internally doesn't sound very entertaining (pun intended).
>
>Never mind getting fancy and probing the insides of an MP3 player for the
>bit stream before the DAC, or using any of the other holes that *must* be
I think you are missing the point. The idea isn't that this will make it
hard for someone to make copies of a copyrighted work. But since the
copy won't be correctly signed, it can only be played on hacked players ---
so you won't be able to make any money selling pirate copies. (Unless,
of course, someone else is making money selling hacked players...)
--
Wim Lewis * [EMAIL PROTECTED] * Seattle, WA, USA
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Can Anyone Help Me Crack A Simple Code?
Date: Sat, 03 Jul 1999 21:46:54 GMT
Jerry Coffin wrote:
> So far, in your case, the output we've got is basically 6 bits.
He has actually provided us with slightly more than 6 bits of
information, but it's still a drop in the bucket compared with
the missing information. For example, we don't know what date/
times go with the six 10-digit numbers for which he got green
lights in his experiment.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: RSA or DIFFIE-HELLMANN
Date: Sat, 03 Jul 1999 21:39:41 GMT
[EMAIL PROTECTED] wrote:
> Does unregulated speech become regulated because later software
> enables a machine to act upon it?
According to the US constitution, it's irrelevant whether or not
software gets somehow involved -- this is not an area over which
our government (at any level) has jurisdiction.
Of course, that doesn't stop people involved in the government
from trying to exceed their lawful authority, which is the actual
problem.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: MP3 Piracy Prevention is Impossible
Date: Sat, 03 Jul 1999 21:57:21 GMT
Wim Lewis wrote:
> I think you are missing the point. The idea isn't that this will make it
> hard for someone to make copies of a copyrighted work. But since the
> copy won't be correctly signed, it can only be played on hacked players ---
> so you won't be able to make any money selling pirate copies. (Unless,
> of course, someone else is making money selling hacked players...)
Not so -- once he has the digital "plaintext", he can reformat it as
CD, DAT, .WAV file, or whatever.
About the only *sensible* approach to cryptologic protection against
piracy would be to embed a *serial number* steganographic watermark,
using one of the methods designed to be hard to eradicate without
ruining the quality of the plaintext, combined with an effective law
enforcement effort of monitoring suspicious plaintexts and tracing
the serial numbers back to the original purchaser, who would have to
have been subject to a license agreement not to redistribute. But
even with such a technological solution, the thieves (that's what
pirates are) would undoubtedly outwit the enforcement effort.
The other approach that comes to mind is to give each consumer his
own private key, which would be embedded in such a watermark, but
that requires manufacturing on a custom basis, which doesn't fit in
with our established mass-marketing distribution systems.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Can Anyone Help Me Crack A Simple Code?
Date: Sat, 03 Jul 1999 18:11:56 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Jerry Coffin) wrote:
..
>
.....
>
> Those may remain uncracked for a LONG time -- 97 characters is a VERY
> small amount of output to try to work with. Even so, that output
> probably represents on the order of 300 bits or so. So far, in your
> case, the output we've got is basically 6 bits.
>
The factor to convert characters to bits is log 26 / log 2, or 1.415/0.301
= 4.7.
97 char X 4.7 char/bit = 456 bits.
--
Rest sometimes allows you to find new things to worry about but should give you the
patience to do something about them.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Kryptos article
Date: Sat, 03 Jul 1999 22:22:59 GMT
Jim Gillogly wrote:
> Someone on the ABC chat board about Kryptos reports an "almost"
> involving a "key" of FRANCISSCOTT and a plaintext that appears
> that it will be the first bit of the Star Spangled Banner, but I
> can't follow the explanation ...
Not only that, but Belil's further efforts are strongly reminiscent
of a Baconian's methods, i.e. very complex and hard to independently
reproduce method(s), resulting in more gibberish than sense.
By the way, has part 3 turned out to be just a double transposition?
There was some indication of that in some of the postings I saw.
It would seem more likely than a triple.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: MP3 Piracy Prevention is Impossible
Date: Sat, 03 Jul 1999 18:20:32 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
>
> The other approach that comes to mind is to give each consumer his
> own private key, which would be embedded in such a watermark, but
> that requires manufacturing on a custom basis, which doesn't fit in
> with our established mass-marketing distribution systems.
I don't like watermarks for philosophical and practical technical reasons,
but consider that packets are sent on an individual basis on the internet,
hardly broadcast to everyone at once. Personalized product that would be
only so available is really the same as encryption, so why no do these
things at that level in the first place.
A stegnographicly attached identifier is not trick for a customed work,
one that lives within the accepted variables in a particular creation.
The way to detect such a thing is to compare two differently marked works,
which could be modified or removed once understood.
--
Rest sometimes allows you to find new things to worry about but should give you the
patience to do something about them.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Something the bit-twiddlers might like
Date: Sat, 03 Jul 1999 18:30:04 -0600
I defined a Strength-Length scale based on a solvable number of
characters, 26-27 being the base and the value the exponent of which the
power need be raised to get the number of characters. 27 characters
equates to 81 trits, 38 digits, and 128 bits.
Such values are probably not significant at much more or less than two
significant figures, but roughly 128 bits is surely easy to remember as
1.0 S-L. Square the 128 to get binary 16Kbits for 2.0 S-L, and the square
root of 128, 11 bits is for 0.5 S-L.
--
Rest sometimes allows you to find new things to worry about but should give you the
patience to do something about them.
------------------------------
From: [EMAIL PROTECTED] (S.T.L.)
Subject: RSA Padding
Date: 04 Jul 1999 01:01:09 GMT
I have a question about padding messages that are being encrypted with RSA. I'm
taking ASCII and making it into a seqence of 3-digit numbers, which I
concatenate together and encrypt _directly_ with RSA. (I.E. No symmetric
algorithms involved.) I don't pad messages with my current system, but I'd
like to be able to. So, my question is whether what I have in mind is okay
(will protect messages more than no padding):
In the stream of 3-digit numbers (which take values from 0 to 255), I want to
insert a random number between 256 and 999 inclusive every, say, fifth block of
3-digit numbers. Assuming I have a decent source of random numbers, is this
enough? I don't want to expand messages any more than necessary. When
decryption time comes, I simply throw out any numbers above 255, removing all
trace of the padding. (Heck, I can pad at random intervals if necessary).
Thanks for your time.
-*---*-------
S.T.L. ===> [EMAIL PROTECTED] <=== BLOCK RELEASED! 2^3021377 - 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 3379 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, and People for the Ethical Treatment of Digital Tierran Organisms
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 #9: Entropy Never Decreases In A Closed System.
------------------------------
From: [EMAIL PROTECTED]
Subject: Ciphers based on HASH functions
Date: Sun, 04 Jul 1999 00:57:09 GMT
There has been some research into creating block ciphers using hash
functions, however I think there was some concern as to how secure they
are due to the fact that hash functions were designed with different
properties in mind. My question is, would a block cipher based on
HMAC's be better? A HMAC is designed to withstand around using a key,
so wouldn't that make a better S-Box than a regular hash function?
Just an idea.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Can Anyone Help Me Crack A Simple Code?
Date: Sat, 3 Jul 1999 19:10:30 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> The factor to convert characters to bits is log 26 / log 2, or 1.415/0.301
> = 4.7.
>
> 97 char X 4.7 char/bit = 456 bits.
Sort of true -- however, some characters are used so rarely in reality
that especially in a message as short as 97 characters, they probably
don't count at all. In addition, some are almost always used in
particular combinations, reducing the information density still
further (e.g. 'q' is essentially always followed by "u", so the "u"
carries no real information at all). Whether that ends up reducing
the actual information density to 3 bits per character, or leaves it
at (say) 3.5 or even at 4.7 probably doesn't matter a whole lot.
We might decide that capitalization matters a lot in this case, and
increase the estimate to 5.7 bits/char, giving ~553 bits of
information total. Given the meta-encipherment that's presumably
involved here, where misspellings, capitalization, etc., may mean a
lot, this may even be somewhat accurate.
However, regardless of the exact number, we're talking about many
times more information than he provided. Despite this, we've still
got so little as to render decipherment extremely difficult at best.
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: Quantum Computers
Date: Sat, 3 Jul 1999 22:48:12 -0400
Dear Greg,
I posted one earlier and am hopeful if I (and we the readers) can
benefit more with what you have behind your assertion. I can totally
understand, I believe, if what I see from what you posted so far is all
I can get. I shall still be quite satisfied. (BTW, your mention of your
brother's word and work is already perhaps more than what I should
expect)
Thank you very, very much for bring up this wonderful topic and
attracted so many, surprisingly many, fabulous posts. I would,
personally thank Anti-Spam, David Molnar. Ed Yang (just to mention
a few) for their enlightening and entertaining posts. I also wish your
brother great success (not just in obtaining funding) in his important
work, be the result going one way or the other. Please give him my
best regards (when he is the least busy if that ever happens).
I redundantly say that I have very shallow math background. I can
not really say much on the topic. What I have (wasting my brain cells)
are intuition. I have thought about the issue(s) in a different manner
(and forgive me for not boring anybody with anything more than the
pretty cryptic words here). I could not do anything directly (of course
due to lack of knowledge etc.) I did the thinking in a round about-way.
What I came to, using whatever simple logic I can apply, is something
quite against intuition if QC can break all cryptosystems. Such 'de-
tuition' not only applies to the situations with symmetric ones but also
'asymmetric' ones. I think we can arrive at something very weird, not
like the random walk by Feller which to me goes with intuition very
well (just my belief and do not think I can put it down formally). I think
many people would like to see how this finally turns out.
I daringly desctibed, in my earlier posts when dealing with
coNP?=NP and such, what my intuition is in a very sketchy and
informal fashion. Let me here be brazen for a moment that my
cryptographic ideas MAY be immune to QC. Let me add 'one' more
word: Not my implementation, but the approach/direction may point
to an 'asymmetric' cryptosystem that is immune to QC. If some one
wants to burn me or ridicule me, it is fine. I have been before any way
and am immune.
I hope mine is not read as an ad for my ideas or as a claim how
much I advanced cryptography. I ain't no saint. I did it for my own
interest.
Lastly, just a reminder (quite redundant but may help some people
in a special sense I hope): Shor's is a 'randomized' algorithm, which
says those with 'cycles' and the like can be practicallly (or more precisely
in our interest "_CRYPTOGRAPHICALLY_") solved with a poly bound
(hastily adding here: if QC works, for not wanting inconclusive marathon
with annoyed people. And by works I mean ...)
I sincerely thank you, Greg, and all those who are sincerely involved
in the discussion. I do not think there is much we can get out of this. It
is a pity may be. But what we can get is the best we can: TRUTH.
--- (My Signature)
Greg Ofiesh wrote in message <7lgg7m$mt1$[EMAIL PROTECTED]>...
>In article <[EMAIL PROTECTED]>,
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>> Greg Ofiesh wrote:
>> > Let us begin with the following assertion that I think you will all
[snip]
>
>Are you familiar with the "difficulties" in building a QC? My brother
>was telling me that he would have (back then)built one given the right
>funding and people. When I asked him how much, it was on the order of
>hundreds of millions, and in less than a year.
>
>The problem he stated was the extreme ineffeciencies the QC would
>exhibit due to the fact that there is no software and that could take a
>decade to develop (just the OS and a useful application).
>
>Now back up 15 years ago, what is to say that the government has not
>already accomplished all this? And if you want to tell me that I am
>wrong, please give me the details. I would love my brother to get into
>this forum, but he is too busy. I have to almost stand in line to get
>a phone call to him. But I will certainly pass on anything you have to
>counter with.
>
>And can you give me directions to the QC literature?
>
>And, finally, I stated not to call me a kook because only losers have
>no life that they spend it responding in the extreme negative. That is
>"why not".
>
>
>Sent via Deja.com http://www.deja.com/
>Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Unimportant)
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss,alt.security.scramdisk
Subject: Re: [OT] alt.security.scramdisk spamming
Reply-To: [EMAIL PROTECTED]
Date: Sun, 04 Jul 1999 03:46:17 GMT
BULLSHIT ! ! ! ! ! !
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: A Thought or a Quoater
Date: Sat, 3 Jul 1999 23:21:32 -0400
Key Secure & NP-hard vs NP-complete (for practical purposes)
(The discussion here does not concern efficiency. Security is the prime)
(Therefore, when reading this, try to forget about efficiency for a bit)
Definition
The definition of a one-way trapdoor here is almost the same
as the _conventional_ version. However, here it is not confined
to 'single route'.
More precisely, for some trapdoor information T, there is a
function f and its corresponding inverse MAPPING m such that
for any x in the domain of f, it is 'easy' to compute y=f(x)
and C={c[i]=m(T,y): c[j]=x, for some j in [1, n]} where n=|C|,
but it is 'hard' to
1. find an m and T, and
2, find an m' (m' != m) and/or a T' (T' != T) such
that x=m'(y) or x=m'(T', y) is 'easy'.
In addition, for any y' not in the range of f (if such a y' does
exist and is applicable), it is 'easy' to determine so (with m-T).
f and m-T form a one-way trapdoor (pair).
IMPORTANT:
In the above definition, it is not required that this c[j] be
directly recognizable, either to the entity possessing m and T
or to one who does not.
Obvious: It is possible that f(x)!=f(z) iff x!=z, but at the same
time, there are many f' != f such that f'(w) all equal y for
different w's in the domain of f. AND f' shares some 'important
characteristics' with f as to be 'deceptive'. (Sorry this sounds
quite cryptic).
It is important to note that it can be 'hard' to get any or
all of the c[i], and at least it is 'hard' to get c[j], without
the knowledge of m-T. In addition, it can even be 'hard', as the
_convention_ goes, to find a z (z!=x), such that f(z)=f(x), i.e.
going ONE-WAY and 'not against the traffic'.
For our 'obvious purpose' (i.e. invertibility) here, one-routeness
is never really a concern. We allow bzillion routes, or in other
words, g's and z's (without constraints on z's) such that g(z)=y,
where z!=x or g is not functionally 'equivalent' to m-T.
The usefulness of such a definition and of an 'entity' by such a
definition should be obvious, knowing that there EXIST one-way
functions (by my definition of one-way which was given sketchily
and informally in my previous post, and hinted here as well. After
all, a function is a function; a function that is not invertible
is a not-invertible function). One may love a conjecture, but we
really do not need one.
I am quite loose with any implication or explication of the notions
of 'secure', 'broken', etc., and I am only interested in the
'practical sense of secure' for now.
The best assurance we can get, as it stands now, is a one-way trapdoor,
one the reverting of which is as hard as solving the subset sum problem. We
do not know if we can achieve this, but it is, IMO, worth trying.
However, according to my Argument concerning coNP=NP, if the problem
is complete, we can guarantee that we can _PURPOSELY_ put in a 'hardest'
of all (being considered) instances and theoretically as many of those as
we would like. Furthermore, unless one knowingly possesses an algorithm
for the 'hardest' of the instances at hand, one will fail to 'practically'
solve the instances, and even one possesses such an algorithm but does not
know he does, he either fails to 'practically' sovle the instances or
'almost always' spends more, or much, much more resources. All said, it is
of course under the assumption that the 'hardest' instances are poly-bound
and are of low enough order. (Again that within context, 'to solve' is to
solve in low-order poly).
Practically, it could be the case that certain 'instances' can be easy.
But that depends on the definition of an instance. Again by my Argument,
and with a little 'tweak', an easy 'instance' can, IMO, be made into 'one'
that is the hardest of all instances considered. Under the auspices of this,
we can focus on the security of the key rather than that of the ciphertext
blocks.
If we have keys whose security is truly based on the complexity of
an NP-complete problem (or better :)), i.e. the computational complexity
of breaking them is at least that of the worst case scenario of an NP-
complete problem, we have achieved our goal of 'key secure', no matter
how vulnerable the ciphertext blocks are.
Of course, this does not mean we love to leave the ciphertext open for
attacks. Once we have a 'key secure' scheme, we then may be able to focus
on inproving the complexity associated with direct attacks on ciphertext.
If we limit our ambitions and apply this key secure concept only to
certain security challenges, we can achieve, I think, something important.
Needless to say that the complexity of a problem complete in 'that'
sense is defined not by the weakest point, but rather the strongest of
all under consideration (for a particular security case/instance). Such
security may be easily 'scalable'. Also, it may not be necessary that a
'key secure' scheme is definitely to produce weak ciphertext.
Once again, I do not have a solution. The solution may be in those
in whom God trusts.
Thank you very much.
--- (My Signature)
P.S.
Doubt if God trusts any who trusts only others.
------------------------------
** 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
******************************
