Cryptography-Digest Digest #187, Volume #9 Thu, 4 Mar 99 23:13:05 EST
Contents:
Re: Encrypting Images Using Fractals (gary huntress)
Re: New high-security 56-bit DES: Less-DES ([EMAIL PROTECTED])
Think you're good at cracking code? Crack This! (Warkior)
Re: Another extension to CipherSaber ([EMAIL PROTECTED])
Re: Unicity of English, was Re: New high-security 56-bit DES: Less-DES
([EMAIL PROTECTED])
Re: Common meaning misconception in IT, was Re: Unicity of English, was Re: New
high-security 56-bit DES: Less-DES (Peter Pearson)
Re: Scramdisk - paranoia (David Sternlight)
Re: Doing It Right: The Next Chip Controversy (Gordon Burditt)
Re: Another extension to CipherSaber (Paul Rubin)
----------------------------------------------------------------------------
Date: Thu, 04 Mar 1999 20:28:31 -0500
From: gary huntress <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Encrypting Images Using Fractals
yes, I ran into that....but I found that if the encryption matrix was full rank,
then there was no problem. The stable "uninteresting" areas of the fractal
didn't have full rank, and did not result in an invertable encryption matrix,
and so I moved to a new region of the fractal image (with different key
parameters)
Gary
Coen Visser wrote:
> [EMAIL PROTECTED] (wtshaw) writes:
>
> >> Fractals and encryption is a fascinating topic! Is there active
> >> research in this area?
>
> >> Gary Huntress
> >> [EMAIL PROTECTED]
>
> >Since you are doing it, I guess there is. Make it actually work in code
> >if you can, and, as simply as you can, before trying to write the
> >ultimate; something generic might be scaled up.
>
> >I've seen fractals come up before, mainly requests for info.
>
> The problem with using chaotic systems (and fractals) for encryption is that
> they have many stable points/area's with regular behaviour. So not just
> any chaotic system can be turned into an encryption system.
>
> Regards,
>
> Coen Visser
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: New high-security 56-bit DES: Less-DES
Date: Thu, 04 Mar 1999 22:20:12 GMT
wtshaw wrote:
> Welsh speaks of unicity or unicity point, pp. 116-118. I believe that I
> saw unicity point used somewhere in sci.crypt in the related discussions
> yesterday .
"Unicity point" is also from Shannon. It's not interchangeable
with "unicity distance", which is the amount of intercepted
text needed to reach the unicity point.
As I understand it, the word "unicity" is derived by turning
the adjective "unique" into a noun. Under normal English
conventions it should therefore refer to the state or property
of being unique.
--Bryan
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Warkior <[EMAIL PROTECTED]>
Subject: Think you're good at cracking code? Crack This!
Date: Fri, 05 Mar 1999 01:42:52 GMT
Enigma Device analysis needed.
Hey, I've recently created a scrambling/encryption routine similar to the
WWII Enigma device (at least what I understand of it) and need some people to
check it out, comment on it's "crackability", give me any suggestions, ...
The BASIC code for it and a sample scrambled file is found at:
http://www.geocities.com/SiliconValley/Chip/8355/games.html
If you tell me what you think I'd appreciate it. Thanx
Here's the general rundown of how it works. 1. The user enters an
encryption phrase. 2. This phrase, no matter what length, is converted into
numbers (1-96) for each letter. 3. The value of each letter of the document
to be scrambled (each having been given the value of 1-96 depending on the
letter) is added to the value of the first value of the encryption phrase.
Then to the second, then to the third, and so on until the end of the
encryption code is reached. 4. Any values over 96 are scrolled around back
to 1. ie. n = 126 n = n - 96 therefore n = 30 5. The new values of the
encryption code are then used for the next letter in the document.
WarkenSoft Productions
http://www.bigfoot.com/~WarkenSoft
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Another extension to CipherSaber
Date: Fri, 05 Mar 1999 01:00:32 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Paul Rubin) wrote:
> In article <[EMAIL PROTECTED]>,
> Anonymous <[EMAIL PROTECTED]> wrote:
> >In December 1998 I built myself a CipherSaber-1 program as per the specs
> >on the CipherSaber site (http://ciphersaber.gurus.com). One of the
> >suggested non-standard improvements on that website was to add a variable
> >number of mixing rounds in the RC4 key initialization phase, so I threw
> >this in as an option.
>
> This doesn't seem too useful; it has about the same effect on the
> RC4 internal state as doing a single key initialization and then
> running the cipher for a while and discarding some output.
Increasing the number of initialization rounds does have about the same
effect as discarding the equivalent number of cipher bytes, tho the key is
mixed in more in the former. It seemed to me that initializing with only 256
operations was a design defect in RC4 and simpley increasing the number was a
more natural way to correct that defect. Also it is simpler to impliment.
Since a major goal of CipherSaber is ease implimentation by novice
programmers the added complexity is significant. I have a bunch of e-mail
from aspiring CipherKnights to prove it.
There is no reason to do both, which the original poster seems to suggest.
>
> >Another improvement I implemented consists of a second number, which I
> >call the "discard count." It is a 32-bit value that specifies how many
> >cipher bytes to discard before beginning to encipher/decipher. I suppose
> >this number is a "key" of sorts as well. It would seem to make the
> >searchable keyspace larger by a factor of 2^32, assuming you were choosing
> >"discard counts" that used the full span from 0 to 2^32-1.
>
> Discarding some output is considered important to RC4's security, but
> making the amount variable complicates things a bit without having any
> concrete benefit that I can easily see. Normally one just throws away
> 256 bytes, which is enough to stir the internal table once.
In http://ciphersaber.gurus.com/cryptanalysis.html I try to show that ASCII
keys are a class of strong RC4 keys that make discarding initial bytes less
necessary. I presented Ciphersaber 2 as an option for those who were still
concerned. Making the number of rounds variable allows the feature to be used
as a simple key strecher. I suppose there should be a default number of
rounds.
>
> >Intuitively I cannot see that this weakens CipherSaber in any way.
> >Comments? Thoughts?
>
> The main thing I think CipherSaber needs is to produce printable
> output for convenient emailing, by coding the output as ascii
> characters. Simplest would be to just produce hexadecimal output,
> though this doubles the size of the output. A bit nicer would be to
> use a 64-character set (like PGP ascii armor) to encode 6 bits/char.
> Even fancier is to use 83(?) chars to encode 4 bytes in 5 chars.
>
Several people in this thread have suggested hex. Since CipherSaber strives
for maximal simplicity, I think hex (with whitespace ignored) should be the
default standard for CipherSaber ascii armour. People can agree on other
standards if they wish.
> Re security, I'd propose increasing the length of the initialization
> vector from 10 bytes to maybe 20.
If you have a good source of randomness, 80 bits is enough to make collisions
very unlikely. If you don't, 160 bits won't help.
>
> I have a C program called Pcrypt that I think predates CipherSaber
> that had about the same motivation; I'll email it on request to US
> addresses (it's one file, about 300 lines). But I think a better
> language for CipherSaber implementation would be Javascript. Then you
> could type your message into a text area field in a web form, your
> password into a password box, and click "encrypt" or "decrypt" and the
> encryption or decryption would happen in client side Javascript with
> the (ascii) output appearing in another text area field or a new
> window. Then you could paste the output into your mailer. That way
> anyone with a Javascript web browser (even a WebTV) could run
> Ciphersaber without having to install any other languages.
>
I like the idea of a Javascript implimentation with hex armour. It would make
a nice addition to chat clients.
Arnold Reinhold
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Unicity of English, was Re: New high-security 56-bit DES: Less-DES
Date: Fri, 05 Mar 1999 02:32:42 GMT
[EMAIL PROTECTED] wrote:
> Bryan Olson wrote:
> > [EMAIL PROTECTED] wrote:
> > > I have been saying often enough that independence is shown
> > > simply by looking at the two formulas. I said so even in the same quoted
> > > message.
>
> Bryan:
>
> You can find my quote above in the sci.crypt archives, at the same place
> where I corrected Shannon's misprinted equation [...]
Why do you follow a quote of yourself and omit what I wrote
in between? At issue was your claim "I said so even in the
same quoted message". What you snipped was my observation
that your claim was false.
[...]
> Again, just looking at the two (correct) equations should convince anyone
> versed in high-school math that they are independent. If you are still not
> convinced, I cannot help further.
I'm not asking for your help; I'm pointing out your error.
On page 661 of Shannon's CTOSS we read,
If M is the message, K the key, and E the enciphered
message, or cryptogram, we have
E = f(M,K)
that is E is a function of M and K.
So instead of just looking at the equations, we should
study the paper and understand them. Knowing that E is a
function of M and K, we don't expect H_E(M) and H_E(K) to
be independent.
> > > BO> Shannon say that the unicity point has been reached when the
> > > BO> key equivocation drops negligibly far from zero.
> >
> > Yes.
>
> which is false as a definition because it is not causal.
I didn't present it as a definition. It follows from the
definition.
> But, I am very happy that now and then you are dropping the wrong denomination
> "distance" and using "unicity point" as above -- in your own words. Again, as
> "you have been saying all along" ;-)
Actually they're Shannon's words, and yes I've used them for
quite a while.
> > > which is however at odds with your own new "old" words above.
> >
> > Why? H_E(K) is zero at the unicity point and H_E(M) is zero at
> > or before the unicity point. Why do you think that's inconsistent?
>
> Read above.
The above was an irrelevant consideration of what makes a proper
definition. Again, H_E(K) is zero at the unicity point and H_E(M)
is zero at or before the unicity point.
> > > Indeed, message
> > > equivocation is what defines the unicity condition (even to Shannon), not
> > > zero key equivocation -- because message equivocation can be zero before
> > > key equivocation is zero.
> >
> > In your own paper, you've noted that Shannon defines unicity distance
> > on page 693 of his "Communication Theory of Secrecy Systems".
>
> But I did not say he defined it in words I could use -- in fact, I revisited
> the words, for good reasons as I explained.
The inability to use Shannon's words has lead to a serious
honesty problem in your paper. You claim,
| Shannon [Sha49] defined "unicity distance" (hereafter, "n")
| as the least amount of plaintext which can be uniquely
| deciphered from the corresponding ciphertext -- given
| unbounded resources by the attacker.
Nowhere in the paper does Shannon's actual definition appear.
> However, the basic idea is the
> same -- hence I call it "revisitation" and not "revision". I am not revising
> Shannon's concept -- it is still the same basic idea. See below.
As people have tried to point out to you, your definition is
not equivalent, or even very close, to Shannon's.
> > It will be seen from Fig. 7 that the equivocation curves approach
> > zero rather sharply.
>
> This passage is correct but becomes misleading when used with the next
> sentence, since he meant key and message equivocation curves (yes, BOTH
> curves, see my comment below) but they can have quite different behaviors in
> general. For example, it is possible that message equivocation drops to zero
> at some point but key equivocation **never** becomes zero until and after the
> received message ends. Do you need examples?
Of course they can have lots of different behaviors. On the
other hand, one constraint Shannon clearly shows is
H_E(M) <= H_E(K).
> Thus, a better wording would have been:
>
> "It will be seen from Fig. 7 that message equivocation approaches zero rather
> sharply."
The issue is not how you think Shannon should have defined
his terms, but how he _did_ define them. On Fig. 7 we see
H_E(K), and not H_E(M). Since H_E(M) can't be greater than
H_E(K), it will also be vanishingly small at the unicity
point.
> > Thus we may, with but little ambiguity, speak
> > of a point at which the solution becomes unique.
>
> Solution of what? The only fitting answer is "cryptogram" -- which implies
> that Shannon meant message equivocation, as I have worded above.
Message _and_ key. I myself was unclear on that for some of
the early posts commenting on your paper. A careful reading
of Shannon, without changing his words, shows that a solution
to the cryptogram solves for both the message and the
transformation induced by the key.
> > The equivocation curves in figure 7 show key equivocation. Shannon does
> > not even draw message equivocation on the graph to which he refers in the
> > definition of unicity distance.
>
> You are mistaken -- but I take your emphatic words once again as a sign of
> good-will and ignorance, not purposeful lack of dialogue and fool's arrogance.
>
> Please read the text one line above that Fig. 7 -- and one line after Fig. 7.
> Which ends with: "After a rounded transition, it follows the He(K) curve
> down." I guess you can tell me what the "it" stands for?
Yes, the message equivocation curve follows the key equivocation
curve down, since in general H_E(M) <= H_E(K). But no, it's not
on Fig. 7. Shannon requires _both_ H_E(M) and H_E(K) to be (very
close to) zero at the unicity point. Since H_E(K) approaching
zero implies H_E(M) approaching zero, it is sufficient to consider
only H_E(K).
> HINT: Just read.
Done.
> The rest of your message is trivial and has been answered before by myself.
> Pls see the archives.
Yes, proving a fixed transformation has a zero unicity distance
was trivial. But I thought it worth while since you were
asserting an incorrect answer.
--Bryan
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Peter Pearson)
Subject: Re: Common meaning misconception in IT, was Re: Unicity of English, was Re:
New high-security 56-bit DES: Less-DES
Date: Fri, 5 Mar 1999 03:09:45 GMT
In article <7bkvts$e6l$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> Bryan Olson <[EMAIL PROTECTED]> wrote:
...[snip]...
>
>But, it is no surprise that you are again confusing issues before this list
>-- instead of learning things first. It is fine to ignore basic facts and
>perhaps you can learn a lot more just by reading and asking questions. I
>believe you will receive a lot more attention and much improved answers once
>you start to truly communicate. Just trust yourself a bit more, in a fair
>dialogue -- if you do not understand something -- ask. By the current odds,
>as in the archives, if you do not understand something then most ptobably the
>problem lies at your side... so, give yourself a chance.
>
>Ed Gerck
Please refrain from using this newsgroup to broadcast personal
insults, particularly personal insults directed at one of our most
scholarly contributors.
- Peter Pearson
------------------------------
From: David Sternlight <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp.discuss,alt.security.pgp
Subject: Re: Scramdisk - paranoia
Date: Thu, 04 Mar 1999 18:56:38 -0800
Reply-To: [EMAIL PROTECTED]
Aman wrote:
>
> But how can we mend these bugs when every single PC machine I have
> come accross works pefectly correctly. ?
Aaargh! That's the defensive cry of many an inexperienced
software support person--"well, it doesn't happen on my machine."
I think you know better, Aman. Ask him for more details
including his configuration, via e-mail. Get him to give you
some debugging info if he's willing.
The proper customer support response isn't "doesn't happen on my
machine", but "tell me more".
David
------------------------------
From: [EMAIL PROTECTED] (Gordon Burditt)
Subject: Re: Doing It Right: The Next Chip Controversy
Date: 5 Mar 1999 03:23:19 GMT
>Let us assume that the pundits are right, and the trend will be towards
>giving the home PC the ability to present *controlled content* - it will
>be possible to download copyrighted works cheaply from the Internet,
>because their owners are secure in the knowledge that your home PC cannot
>misuse or copy them.
I think I can predict what will happen immediately after this is
developed and deployed to any extent. Copyright holders, secure
in the knowledge that they'll get paid, will SPAM their material
unmercifully to the entire planet. (Since webmasters started paying
for click-thrus, SPAM will pull just about any lie they can to get you
to visit their web site.) They will misrepresent what the material is:
Something labelled hot porn might be a Disney film, or vice versa.
Or it might be "blank film". (There's a lot of this in porn spam,
especially the "remove list" link that leads to the porn site.) They
will misrepresent what it costs, or simply claim that it's free, while
it actually charges as much as it can. (Happened a lot with 900
numbers.) To the extent possible, while you're watching the material
the "trusted code" will be spamming copies of itself to everyone.
(What version of happy99.exe are you running?)
Long-term, this is rather self-defeating, as few people will dare buy
ANYTHING through this mechanism because of the sleaze merchants.
Is anyone reminded of the history of 900 numbers here?
>Besides putting a serial number in the CPU chip, what else is going to be
>required to achieve that dream?
>
>The answer is: giving chips the ability to execute programs that aren't
>merely "hard to disassemble", but which are actually encrypted - and
>decrypted on the chip.
>
>As one can guess, this is likely to be done by giving only reputable and
>big companies willing to sign NDAs the public key with which to prepare
>such encrypted programs.
I don't believe that this will prevent large-scale fraud.
Some of the larger credit-card companies and phone companies seem
to think it's legal to sign you up for their latest pointless service,
bill you for it, and then if you object enough, take it off the bill.
Maybe.
>This is the "wrong way" of doing it, though. It would be preferred that
>the method of preparing such programs be made public, so as to make it
>available to the lowliest shareware author... but wait! Wouldn't this kind
>of feature on a chip allow the creation of computer viruses that would be
>impossible to eradicate?
You have a problem with two sets of code that are (or should be)
mutually suspicious of each other. The copyrighter's code
wants to ensure:
- If you use the material, you pay for it.
- If you use the material, you can't capture an unencrypted copy of it.
The user's code wants to ensure:
- To avoid paying more than the represented cost of using the material.
- To avoid paying more than the amount the user consented to pay (possibly
aborting the transaction or cutting it short).
- To avoid paying at all for material that is not what is represented.
- To avoid having the copyrighter's code use or transmit marketing information
back to the copyrighter. (For the purpose of this, "marketing information"
is any individual-specific or individual's-computer-specific information
that a marketing department is not willing to pay money to AVOID receiving.
It's hard to get much broader than that. If you "rent" a movie, it is
not any of the movie producer's business who you are or even WHICH movie
you rented. Only the payment amount (by anonymous digital cash) is relevant.
The code might need to use a little (very little) additional information,
like the type of your video card. It has no business transmitting this
off-system.
- To avoid having the copyrighter's code transmit anything to a third
party (SPAM, "marketing information" as defined above, anything that
costs money to transmit, death threats to the President, copies
of itself, etc.)
>The Pentium chip ID lacks one feature that would make it less of a
>problem. One would like to be able to turn it on, for certain programs and
>web sites - and then turn it off again - without resetting the computer.
>But how can that be done: if it's available under program control, can't
>any program read it?
>The answer would be to "lock" the ID with a password. (The ability to
>change the password would be on at reset, and turned off - the way the ID
>itself is now - via the BIOS.) Turning it on and off would be done by an
>application separate from your browser.
Of course, Microsoft's browser will quietly turn it on, get the
ID, and if it was off, turn it off again. Then it includes it
in a header in every HTTP request.
Gordon L. Burditt
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Another extension to CipherSaber
Date: Fri, 5 Mar 1999 03:57:39 GMT
In article <7bnaba$fq2$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>> This doesn't seem too useful; it has about the same effect on the
>> RC4 internal state as doing a single key initialization and then
>> running the cipher for a while and discarding some output.
>
>Increasing the number of initialization rounds does have about the same
>effect as discarding the equivalent number of cipher bytes, tho the key is
>mixed in more in the former. It seemed to me that initializing with only 256
>operations was a design defect in RC4 and simpley increasing the number was a
>more natural way to correct that defect. Also it is simpler to impliment.
>Since a major goal of CipherSaber is ease implimentation by novice
>programmers the added complexity is significant. I have a bunch of e-mail
>from aspiring CipherKnights to prove it.
We don't know how RC4(tm) initialization as implemented by its
designers really worked. The version that's published was reverse
engineered from applications that used the RSA library but may not
include the setup procedures. I agree that running the cipher for a
while is similar to re-running the key setup, though not the same.
Re-running the key setup with the same original key uses the key closer
to the final output, which may leak info about it.
Also, I can't comprehend why anyone thinks re-running the key
initialization is simpler. Both are trivial. You already have to be
able to do both the key setup and output generation; so throwing away
N bytes of output (usually N=256) is no more complicated than running
the setup N times.
>There is no reason to do both, which the original poster seems to suggest.
I agree with this.
>In http://ciphersaber.gurus.com/cryptanalysis.html I try to show that ASCII
>keys are a class of strong RC4 keys that make discarding initial bytes less
>necessary. I presented Ciphersaber 2 as an option for those who were still
>concerned. Making the number of rounds variable allows the feature to be used
>as a simple key strecher. I suppose there should be a default number of
>rounds.
More variables that don't help security in a concrete way don't seem
good. Ciphersaber should be as simple as possible. CS2 should specify
a number of rounds, not a variable. I suggest throwing away 256 initial
bytes but re-running the key setup a few times (say twice) is also ok.
>Several people in this thread have suggested hex. Since CipherSaber strives
>for maximal simplicity, I think hex (with whitespace ignored) should be the
>default standard for CipherSaber ascii armour. People can agree on other
>standards if they wish.
CipherSaber should try to maintain interoperability by specifying an
encoding and staying with it. Hex is an ok choice. It fits within
the type of compromises that CipherSaber already makes.
>> Re security, I'd propose increasing the length of the initialization
>> vector from 10 bytes to maybe 20.
>
>If you have a good source of randomness, 80 bits is enough to make collisions
>very unlikely. If you don't, 160 bits won't help.
OK.
>I like the idea of a Javascript implimentation with hex armour. It would make
>a nice addition to chat clients.
I don't know of any chat clients that offer javascript capability, but
that's an interesting idea.
------------------------------
** 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
******************************
