Cryptography-Digest Digest #75, Volume #11 Tue, 8 Feb 00 19:13:01 EST
Contents:
Re: permission to do crypto research (Lance Purple)
Re: permission to do crypto research (Troed)
Re: Strip Security ("Steven G. Tyler")
Re: Seeking Information on FRACTAL CRYPTOGRAPHY (Tim Tyler)
Re: Latin Squares (was Re: Reversibly combining two bytes?) (Tim Tyler)
Re: Compression cannot prevent plaintext recognition (was Re: is signing a
signature with RSA risky?) (Terje Mathisen)
Re: Latin Squares (was Re: Reversibly combining two bytes?) (Terry Ritter)
Re: permission to do crypto research (David Wagner)
Re: Using Gray Codes to help crack DES (David Wagner)
Re: DVD crypt Q (David Wagner)
Re: NIST, AES at RSA conference (David Wagner)
New standart for encryption software. ("finecrypt")
Re: Latin Squares (was Re: Reversibly combining two bytes?) ("r.e.s.")
Re: Using Gray Codes to help crack DES ([EMAIL PROTECTED])
Re: permission to do crypto research (Xcott Craver)
Re: How secure is this method? What about this? (Xcott Craver)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Lance Purple)
Crossposted-To: talk.politics.crypto,misc.int-property,misc.legal.computi
Subject: Re: permission to do crypto research
Date: 8 Feb 2000 21:26:13 GMT
lcs Mixmaster Remailer <[EMAIL PROTECTED]> wrote:
[ does deCSS have any uses other than piracy? ]
>BTW, one of the arguments in favor of this view advanced by the plaintiffs
>was the fact that DeCSS is available on Windows, where there are already
>many DVD-playing programs available. Why else would it be designed to
>run on that architecture, other than for piracy, they asked? The claim
>that DeCSS exists only to allow Linux users to watch movies was demolished
>(in the judge's eyes) by this observation! Anyone care to comment?
It could be used to write software players on Windows or Linux that
ignore region-lockout codes. IMHO, the industry has no legitimate
purpose trying to mandate this "feature", and since they refused to
license the CSS technology without it, I hope they lose the case on
similar arguments to _Sony vs Universal_ or _Activision vs Sega_ .
--
,--------------------------------------------,
| Lance Purple (lpurple at netcom dot com) |
'--------------------------------------------'
------------------------------
From: [EMAIL PROTECTED] (Troed)
Crossposted-To: talk.politics.crypto,misc.int-property,misc.legal.computi
Subject: Re: permission to do crypto research
Reply-To: [EMAIL PROTECTED]
Date: Tue, 08 Feb 2000 21:45:38 GMT
lcs Mixmaster Remailer <[EMAIL PROTECTED]> wrote:
>BTW, one of the arguments in favor of this view advanced by the plaintiffs
>was the fact that DeCSS is available on Windows, where there are already
>many DVD-playing programs available. Why else would it be designed to
>run on that architecture, other than for piracy, they asked? The claim
>that DeCSS exists only to allow Linux users to watch movies was demolished
>(in the judge's eyes) by this observation! Anyone care to comment?
At the time of writing, there was no UDF filesystem available for
Linux - now there is, and now players are appearing for Linux.
This is all well known information, why don't you read up a bit on
your facts?
www.opendvd.org
... or a nice little link like
http://www2.linuxjournal.com/articles/currents/016.html
___/
_/
------------------------------
From: "Steven G. Tyler" <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.palmtops.pilot,alt.comp.sys.palmtops.pilot,comp.sys.handhelds
Subject: Re: Strip Security
Date: Tue, 08 Feb 2000 16:54:18 -0500
karl malbrain wrote:
> Brian Keener <[EMAIL PROTECTED]> wrote...
> > If max password size is 12 characters, then you've got more possible
> > combinations. However, you might only have a password that's 4 characters
> > long, out of a possible maximum of 12. But, anyone trying to guess your
> > password won't know if you used all twelve digits or not.
>
> No. If you mean the PIN is now 12 digits long instead of 4, and all PINS are
> issued, anyone trying to guess your PIN would have to try to guess out of
> 10^12 possibilities, leading ZEROES not-with-standing. Karl M
Actually, Brian correctly stated the meaning of my comment.
I believe this discussion started with a question about the security
level of Strip, a Palm app that stores encrypted information. Though the
question itself was whether you could extract the password from the app
itself, the current discussion is about how difficult it would be to
find the password by brute force, by sequentially selecting all possible
combinations until you get a "hit."
Strip requires you to select a password, but does *not* require any
particular password length, nor does it auto-assign a password of fixed
length. Therefore, even though a would-be cracker might actually be
facing a password of only 4 digits, s/he has to assume it may be longer,
up to the maximum permitted. Therefore, the 'security' of a 4-digit
password thus must take into account the possibility of a longer
password.
--
Steve on Cattail Creek (Steven G. Tyler, Esq.) <[EMAIL PROTECTED]>
The Computer Counselor -- Technology Consulting for the Law Office
Webmaster, Troop 339, BAC, BSA (http://members.aol.com/troop339)
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Seeking Information on FRACTAL CRYPTOGRAPHY
Reply-To: [EMAIL PROTECTED]
Date: Tue, 8 Feb 2000 21:59:30 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: John Savard wrote:
[Chaos?]
:> The main reason for the bad rep is essentially that a function can be
:> nonlinear without really scrambling its input thoroughly; that will be
:> enough to obtain chaotic behavior without being enough to produce a
:> cryptosecure pseudorandom generator.
: I suppose that it could nonetheless be of value to investigate
: whether a process based on chaos theory may be profitably
: employed as a 'component' of an encryption 'system'. Chaos encryptions
: apparently don't belong to the mainstream of cryptology today. [...]
"Chaos" seems to have a pretty broad definition. Fundamental to it
appears to be a sensitive dependence on initial conditions.
The way - for example - if you make a slight change to the initial state
of the system, the subsequent evolutions rapidly becomes unrecognisable.
This is rather reminiscent of the way that if you make a slight change to
the key, or the plaintext, the resulting cyphertext is unrecognisable.
Mainstream cryptography is saturated with chaos and chaotic behaviour,
born of iterated non-linear functions.
However there are few references to "chaos theory" - perhaps because this
is widely considered the pop-science deviant offspring of nonlinear
systems theory, run by those who exploited the mathematics by marketing
its pretty pictures to the public.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
The sad thing about bashing Windows is that it's all true.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Latin Squares (was Re: Reversibly combining two bytes?)
Reply-To: [EMAIL PROTECTED]
Date: Tue, 8 Feb 2000 22:05:20 GMT
r.e.s. <[EMAIL PROTECTED]> wrote:
: "Tim Tyler" <[EMAIL PROTECTED]> wrote ...
: : r.e.s. <[EMAIL PROTECTED]> wrote:
: : : "Tim Tyler" <[EMAIL PROTECTED]> wrote ...
: : : : : [If...] then we can reduce any Latin Square of
: : : : : order N to three arrays of N entries, which means that the internal
: : : : : state of a square of order N is bounded by 3N, not by N^2. (Right?)
: : : :
: : : : The information content is smaller than this perhaps might suggest -
: : : : since each array entry is itself constrained.
: : : :
: : : : N! x N! x N! - for the Latin Square - compared to N^(N^2) for the
: : : : totally random table. ^^^^^^^
: :
: : : But the table can't be totally random if it's to be a workable
: : : combiner. [...]
: :
: : Indeed not. Only a tiny fraction of these would be valid Latin squares.
: You missed my point.
I don't /think/ so.
: Your number N^(N^2) was said to be for a "totally random table".
: I was pointing out that it's not to a totally random table that
: one would want to make a comparison.
Yes, I understood what you were saying.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
The second mouse gets the cheese.
------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Subject: Re: Compression cannot prevent plaintext recognition (was Re: is signing a
signature with RSA risky?)
Date: Tue, 08 Feb 2000 23:26:03 +0100
John Savard wrote:
> Compression can make plaintext recognition more difficult.
>
> That is all that can be legitimately claimed for it, and it is enough
> to make compression worth doing for an additional reason, and enough
> to motivate carefully tailoring compression to its intended
> application - getting rid of headers and the like.
>
> To prevent plaintext recognition, I would suggest, after compression,
> a pre-encryption step having these characteristics:
>
> - it involves transposing bytes within (large chunks of) the message,
>
> - it has a larger key than that of the "real" encryption
>
> - it is not computationally intensive
>
> - it produces unbiased output
Would it be possible to simply use something like pkzip on the input
data, split the result into <block-size> (128 bits?) and then reverse
the order of the blocks, before encrypting them using chaining?
This would at least get rid of the known zip header, making a search for
known plaintext harder, right?
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] (Terry Ritter)
Subject: Re: Latin Squares (was Re: Reversibly combining two bytes?)
Date: Tue, 08 Feb 2000 22:40:49 GMT
On 7 Feb 2000 21:31:44 GMT, in <[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] (Michael Wojcik) wrote:
>[...]
>We should also return to the question of changing squares during
>encoding, as Terry Ritter suggested in another post. Generating a
>new square is relatively expensive, but perhaps not prohibitive with
>this method.
A few simple 256-element random-like permutations (shuffling by a
keyed confusion-sequence) are surely fast enough in human terms, even
for message keying. But there really is a great deal more dangerous
"structure" in Latin squares constructed from a few permutations than
is likely to be present in schemes which must store an entire table.
>If we're using square-combining in a block cypher, we
>might advance to a new square on every block. With a stream cypher,
>we might generate a new square after every so many bytes (how many
>is an interesting question), or we might do so dynamically based on,
>say, the key or plaintext (with the decoder examining output plain-
>text to decide when to regenerate).
One might have at least two combining levels, plus a multiplicity of
squares (say, 16) in at least one level. The confusion sequence then
selects among the 16 possible squares for that level on a
character-by-character basis. Since the selection process is never
exposed, it should be hard for an opponent to identify which
characters are taken from which square.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Crossposted-To: talk.politics.crypto,misc.int-property,misc.legal.computi
Subject: Re: permission to do crypto research
Date: 8 Feb 2000 14:50:40 -0800
In article <[EMAIL PROTECTED]>,
lcs Mixmaster Remailer <[EMAIL PROTECTED]> wrote:
> What about large-scale piracy in another sense: rather than one guy who
> makes 25,000 copies, we have 25,000 people who make one copy?
Maybe someday, but certainly not today. As you say, the bandwidth
requirements are too large for DeCSS-inspired piracy to be a problem in
the next few years (possibly even longer).
Of course, five or ten years down the road, all bets are off. But the
high-tech business changes so fast that it's hard for me to see how any
discussion looking five to ten years ahead would be anything but premature
speculation at this point.
Remember, the industry claimed in their legal briefs that the DVD CCA
"is suffering and will continue to suffer immediate and irreparable harm",
unless the truth is immediately banned. (They also said, for instance,
that DeCSS "will likely mean the end of this California business".)
Even if we offer them the benefit of the doubt here, these types of statements
appear thoroughly insupportable. It seems clear that all available technical
evidence points to the conclusion that this is a blatant misrepresentation
of the facts. Any immediate harm that might be caused by DeCSS appears to
be minimal.
I wouldn't be surprised if the DVD industry would like these inconvenient
facts to just disappear quietly. After all, these discoveries highlight
the shoddy workmanship found in the DVD security architecture, and show just
what a lemon their vaunted CSS is. But as scientists, we still need to face
the facts, no matter how unpleasant they may be. Until the DVD industry
recognizes this, there is little hope for improvements in DVD security.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Using Gray Codes to help crack DES
Date: 8 Feb 2000 14:56:54 -0800
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
> By cycling through the 56-bit DES keys in Gray code order, one can
> ensure that one has to do only *one* set of 16 XORs to proceed from
> one key being tried to the next key to test.
Yes, this elegant idea was proposed and discussed a few years back, and
(if I remember correctly) provides significant performance gains for
software-based DES keysearch software.
Nice re-discovery!
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Crossposted-To: rec.video.dvd.tech
Subject: Re: DVD crypt Q
Date: 8 Feb 2000 15:00:57 -0800
Yes. By the way, budding sci.crypt cryptanalysts studying how to
make and break stream ciphers and looking for easy ciphers to try
their hand on might stand to learn some valuable lessons from CSS.
Take a look at CSS sometime when you get a chance, and you will see
that it is a textbook example of a LFSR-based cipher susceptible
to a trivial divide-and-conquer attack. Finding the attack(s) for
yourself is an educational (and relatively easy) exercise. Enjoy!
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: NIST, AES at RSA conference
Date: 8 Feb 2000 15:05:33 -0800
In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
> Fine, then help create that proof.
Believe me, I've tried. :-) And failed.
It seems to be quite a difficult problem (to say the least).
That's why I expressed such surprise -- and interest -- when you
said you had such a proof.
------------------------------
From: "finecrypt" <[EMAIL PROTECTED]>
Subject: New standart for encryption software.
Date: Wed, 9 Feb 2000 01:54:07 +0300
FineCrypt 1.2
First and sole program, which you can test with test vectors. Also new
advanced key managment (patented by Crypto Systems, Inc), grafical file
statistics feature, etc., etc...
http://www.finecrypt.com/fcinst.exe
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Latin Squares (was Re: Reversibly combining two bytes?)
Date: Tue, 8 Feb 2000 15:22:28 -0800
"Tony T. Warnock" <[EMAIL PROTECTED]> wrote ...
: All combiners will have to be Latin squares.
The Latin Square combiners appear to be a subset of all
possible combiners, corresponding to "balanced" rows &
columns in the table; so a combiner that's an Lsquare
might be *better* than one that's not, in some context,
but not all combiners need be Lsquares, as far as I can
see in common usage of the term. (But it does seem that
to be a combiner it must allow for later recovery of the
message -- resulting in N!^N possible NxN combiners.)
To take the most extreme example:
If row corresponds to enciphering-symbol and column
corresponds to message-symbol, then for an alphabet of
4 symbols even the square
0123
0123
0123
0123
yields a combiner -- but not a good one, since a given message
symbol will result in an output independent of enciphering
symbol. Whether less-extreme non-balanced (i.e. non-Lsquare)
combiners are ever desirable -- that would seem to be another
question.
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Using Gray Codes to help crack DES
Date: 8 Feb 2000 23:24:52 GMT
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
> By cycling through the 56-bit DES keys in Gray code order, one can
> ensure that one has to do only *one* set of 16 XORs to proceed from
> one key being tried to the next key to test.
another way:
count = count + 1
greycode = count ^ (count >> 1)
Keith
http://www.cix.co.uk/~klockstone
------------------------
'Unwise a grave for Arthur'
-- The Black Book of Carmarthen
------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Crossposted-To: talk.politics.crypto,misc.int-property,misc.legal.computi
Subject: Re: permission to do crypto research
Date: 8 Feb 2000 23:35:26 GMT
lcs Mixmaster Remailer <[EMAIL PROTECTED]> wrote:
>
>Given the inevitability of increases in bandwidth and storage, isn't
>it reasonable to view DeCSS as a piracy tool?
Given massive increases in bitrate and storage capacity,
it's also possible to imagine DeCSS becoming irrelevant as
a piracy tool.
You'll just be able to take the digital output of your
future DVD player, that would normally hook up to your future
digital TV, plug it into your future computer and save the feed.
Why muck about with decryption software?
>BTW, one of the arguments in favor of this view advanced by the plaintiffs
>was the fact that DeCSS is available on Windows, where there are already
>many DVD-playing programs available. Why else would it be designed to
>run on that architecture, other than for piracy, they asked? The claim
>that DeCSS exists only to allow Linux users to watch movies was demolished
>(in the judge's eyes) by this observation! Anyone care to comment?
Sure: just because it now runs on Windows doesn't mean it wasn't
_intended_, by its creator, for watching DVDs on Linux.
Hackeroids have been bandying the code around, screaming "#&*%
the law, NYEAH NYEAH," like DeCSS was some kind of little cuban boy.
That doesn't mean that the code was intended as a hacking tool.
-Scott
------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Subject: Re: How secure is this method? What about this?
Date: 8 Feb 2000 23:46:12 GMT
Erik <[EMAIL PROTECTED]> wrote:
>
>1) Get a number from A, Na, from 1 to 32,
>2) Get a number from B, Nb, which is Na bits long.
>3) XOR the next Na bits of plaintext with Nb.
>and repeat
This is identical to just XORing all of the second stream with
the plaintext. Unless I'm reading you wrong.
What's the difference between, say:
1) XORing the first 17 bits of plaintext with 17 bits from B.
2) XORing the next 31 bits of plaintext with 31 more bits from B.
3) XORing the next 18 bits of plaintext with 18 more bits from B.
4) XORing the next 4 bits of plaintext with 4 more bits from B.
5) XORing the next 19 bits of plaintext with 19 more bits from B.
...
and
1) XOR all 1024 bits of plaintext with all 1024 bits from B.
Seems to me that the exact same XORs will be made with the
exact same bits from B. Hence, this is a stream cipher using
B as a pseudo-random number generator.
-Scott
------------------------------
** 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
******************************
