Cryptography-Digest Digest #506, Volume #10 Thu, 4 Nov 99 14:13:02 EST
Contents:
Re: questions about twofish (Tom St Denis)
Re: Re: Compression: A ? for David Scott (CoyoteRed)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
([EMAIL PROTECTED])
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column ("Trevor
Jackson, III")
Re: A new thread disappeared ? (SCOTT19U.ZIP_GUY)
Re: relative security of hashes, md5 vs. snefru (Ian Wehrman)
Re: Steganography Academy (wtshaw)
Re: crypto and dependencies (wtshaw)
Re: A new thread disappeared ? (wtshaw)
Re: The Code Book (Derrick Schneider)
Re: The Beale Mystery ("Charles Brockman")
Re: What is the deal with passwords? (Tom St Denis)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: questions about twofish
Date: Thu, 04 Nov 1999 13:05:31 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In counterpane's optimized twofish, there are different options you
can
> choose during compilation like zero, partial, or full key.
> First,
> What are the advantage/dis-advantages.
> Do they affect security, or is it just a memory/speed trade-off.
I would suggest you read the paper.
>
> Second,
> What's the difference between using the 192 bit key option, and using
> the 256 bit key option with 64 bits zeroized (both still have same key
> space).
See above.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (CoyoteRed)
Subject: Re: Re: Compression: A ? for David Scott
Date: Thu, 04 Nov 1999 13:34:55 GMT
Reply-To: this news group unless otherwise instructed!
On Wed, 3 Nov 1999 16:04:26 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>Not random. Structured. (Assuming some expansion takes place).
If we have structure, where does this structure come from? Is it
inherent to the algorithm or is added in? It would have to inherent
to the decompression algorithm and not added it because the attacker
could use this to his advantage.
Pardon me if this has already been answered, but I couldn't follow
some of the other threads, it was just over my head.
--
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 04 Nov 1999 13:43:36 GMT
I think we are talking about different degrees of agility. You are
concerned only about the agility to define a set of acceptable ciphers.
I want something more: the agility to be able to modify the ciphers in
the future.
In article <[EMAIL PROTECTED]>,
"Trevor Jackson, III" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>> Let's see: Normally, I compose the message and encrypt it off-line,
>> then I connect to Internet and send all my mail in batch mode.
>
>Good, that means you already have obtained the public keys of all of
>the recipients of your messages. When you got their public keys you
>also got their supported cipher list.
If I want to allow my addressees to change their choice of cipher, then
I would have to download their list every time I want to send them a
message.
>>What if none of the ciphers in one addresse's set is trusted by me?
>
> Then you cannot communicate.
If there is a code server then you can. Maybe I trust rot13. I encrypt
my message with it and send it to you. Your email client does not know
anything about rot13 - it downloads its code and successfully decrypts
my message. It is my message and if I chose a bad cipher it is my
problem; you will always be able to read any message you receive.
>This problem is not created by having multiple ciphers supported at
>each end. This problem is created by having users insist upon
>particular ciphers. Note that if you insist upon ciphers {A1, A2, A3
>} and your respondent insists upon { B1, B2 }, they you can still
>communicate securely in both your opinions, by using two ciphers, one
>of yours and one of his. Both of you will believe that the doubly
>encuphered messages are secure.
This is a good idea and certainly an improvement over the original
"join the cipher lists" idea.
>> What if my addressee does not have public keys?
>
>Then, as now, you would need to obtain a secret key from him. With the
>secret key comes the set of his ciphers.
Again, I want to be able to change ciphers at a moment's notice.
>> What if my addressee uses a different PK protocol?
>
>Then you can't talk anyway.
Why not think about how this could be achieved? Maybe PK systems can be
changed dynamically. How about having a centralized server cross-
certify users?
>> What if I want to send one message to 100 destinations?
>
>You have to encipher multiple times anyway because using the same key
>for broadcast messages creates an opportunity for attack. I'm not a
>protocol expert, barely even a student. But I know there's weakness
>in reusing message keys whether serially or in parallel.
Oh, I agree. What I was worried about in the case of multiple addresses
is the slowness of having to negotiate the cipher with each one of
them. You see I assume you do want to allow people to change their mind
about their choice of cipher. If so, you would have to download each
addressee's list before sending them mail. With my method there is no
such problem: I decide which cipher to use knowing that everybody else
will be able to read my messages.
>> More importantly: what if the standard (or widely used) PK system
>> suffers a catastrophic failure in the future?
>
>Yeah, what if? The ensuing disturbance would have nothing to do with
>cipher agility.
Yes, but we agree that PK agility is even more important.
>>This is more probable to
>>happen with PK than with a symmetric cipher. Therefore it is even
>>more important to be able to change PK environments.
>
>Probably true. But AFAIK there is no reason to believe we can create
>"many" PK systems, whereas there is good reason to believe that we can
>create "many" symmetric ciphers.
I think there are already several PK systems (based on a few
mathematical problems). It would be quite interesting by the way if
somebody discovered a PK system that does not depend on math in its
core.
>> (...) In a networked world third parties are a fact of life.
>
> Sure. As a key respository. Not as a repository for security
> implementations. The two aren;t anywhere near comparable.
Not really. The difference between code and data is contextual. In LISP
both code and data have exactly the same form. The basic idea behind my
Frog cipher is to compile the key into code. Code can be
cryptographically weak but so can a key.
Observe that we already use "code servers" for almost everything we run
in our computers: our software providers. There is really nothing
fundamentally different in my idea of a centralized server that holds
certified crypto primitives.
>>(...) In other words let us define a high level standard that
>>explains how to change a low level standard.
>
> An extremely ambitious goal.
Also an extremely important goal, I think. Technically it is doable and
it is not restrictive in any way. It will always be possible for
somebody to continue producing rigid security applications that do not
offer the agility to dynamically change their primitives. (In this
entire discussion of course we assume that security systems are
software based; hardware based systems are an entirely different
problem.)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Thu, 04 Nov 1999 10:03:46 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
[EMAIL PROTECTED] wrote:
> I think we are talking about different degrees of agility. You are
> concerned only about the agility to define a set of acceptable ciphers.
> I want something more: the agility to be able to modify the ciphers in
> the future.
>
> In article <[EMAIL PROTECTED]>,
> "Trevor Jackson, III" <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] wrote:
> >> Let's see: Normally, I compose the message and encrypt it off-line,
> >> then I connect to Internet and send all my mail in batch mode.
> >
> >Good, that means you already have obtained the public keys of all of
> >the recipients of your messages. When you got their public keys you
> >also got their supported cipher list.
>
> If I want to allow my addressees to change their choice of cipher, then
> I would have to download their list every time I want to send them a
> message.
In a perfect world you would have to refresh their list for every message.
In a reasonable approximation to the perfect world you would refresh at some
infrequent interval (month/year), or when you received a message from your
correspondent where the message, encrypted with their private key for
authentication and your public key for privacy from third parties, included
a "cipher set timestamp" later than the one attached to the key you you
already had.
>
>
> >>What if none of the ciphers in one addresse's set is trusted by me?
> >
> > Then you cannot communicate.
>
> If there is a code server then you can. Maybe I trust rot13. I encrypt
> my message with it and send it to you. Your email client does not know
> anything about rot13 - it downloads its code and successfully decrypts
> my message. It is my message and if I chose a bad cipher it is my
> problem; you will always be able to read any message you receive.
I disagree. It is OUR conversation. Since I expect you to refer,
implicitly and explicitly, to the contents of the messages I send, which
contents I intend to keep private, I have a vested interest in the security
of the messages you send.
How often are you willing to indulge in a conversation where one person
speaks in thought-to-be-secure ciphertext and the other speaks in
plaintext? Unless the person speaking plaintext is restricted to
monosyllabic responses, I would not partake.
> >This problem is not created by having multiple ciphers supported at
> >each end. This problem is created by having users insist upon
> >particular ciphers. Note that if you insist upon ciphers {A1, A2, A3
> >} and your respondent insists upon { B1, B2 }, they you can still
> >communicate securely in both your opinions, by using two ciphers, one
> >of yours and one of his. Both of you will believe that the doubly
> >encuphered messages are secure.
>
> This is a good idea and certainly an improvement over the original
> "join the cipher lists" idea.
>
> >> What if my addressee does not have public keys?
> >
> >Then, as now, you would need to obtain a secret key from him. With the
> >secret key comes the set of his ciphers.
>
> Again, I want to be able to change ciphers at a moment's notice.
>
> >> What if my addressee uses a different PK protocol?
> >
> >Then you can't talk anyway.
>
> Why not think about how this could be achieved? Maybe PK systems can be
> changed dynamically. How about having a centralized server cross-
> certify users?
We can certainly think/talk about it. I believe it to be a topic of
interest and utility. However, it is distinct from the original issue.
>
>
> >> What if I want to send one message to 100 destinations?
> >
> >You have to encipher multiple times anyway because using the same key
> >for broadcast messages creates an opportunity for attack. I'm not a
> >protocol expert, barely even a student. But I know there's weakness
> >in reusing message keys whether serially or in parallel.
>
> Oh, I agree. What I was worried about in the case of multiple addresses
> is the slowness of having to negotiate the cipher with each one of
> them. You see I assume you do want to allow people to change their mind
> about their choice of cipher. If so, you would have to download each
> addressee's list before sending them mail. With my method there is no
> such problem: I decide which cipher to use knowing that everybody else
> will be able to read my messages.
How often do you expect people to change their cipher set? How volatile do
you expect a person's cipher set to be?Only in the case that they change
both often and thoroughly does this become an issue.
>
>
> >> More importantly: what if the standard (or widely used) PK system
> >> suffers a catastrophic failure in the future?
> >
> >Yeah, what if? The ensuing disturbance would have nothing to do with
> >cipher agility.
>
> Yes, but we agree that PK agility is even more important.
>
> >>This is more probable to
> >>happen with PK than with a symmetric cipher. Therefore it is even
> >>more important to be able to change PK environments.
> >
> >Probably true. But AFAIK there is no reason to believe we can create
> >"many" PK systems, whereas there is good reason to believe that we can
> >create "many" symmetric ciphers.
>
> I think there are already several PK systems (based on a few
> mathematical problems). It would be quite interesting by the way if
> somebody discovered a PK system that does not depend on math in its
> core.
>
> >> (...) In a networked world third parties are a fact of life.
> >
> > Sure. As a key respository. Not as a repository for security
> > implementations. The two aren;t anywhere near comparable.
>
> Not really. The difference between code and data is contextual. In LISP
> both code and data have exactly the same form.
Hardly. Representation yes; form, meaning structure, no.
Consider that given something that claims to be a cipher key I can fairly
trivially determine whether it is ir is not a cipher key. (I'm, thinking of
modern symmetric ciphers). Given something that claims to be a secure
implementation of a particular cipher, I would expect it to be impossible
to render a definitive judgement without a detailed analysis of the
software.
> The basic idea behind my
> Frog cipher is to compile the key into code. Code can be
> cryptographically weak but so can a key.
>
> Observe that we already use "code servers" for almost everything we run
> in our computers: our software providers. There is really nothing
> fundamentally different in my idea of a centralized server that holds
> certified crypto primitives.
>
> >>(...) In other words let us define a high level standard that
> >>explains how to change a low level standard.
> >
> > An extremely ambitious goal.
>
> Also an extremely important goal, I think. Technically it is doable and
> it is not restrictive in any way. It will always be possible for
> somebody to continue producing rigid security applications that do not
> offer the agility to dynamically change their primitives. (In this
> entire discussion of course we assume that security systems are
> software based; hardware based systems are an entirely different
> problem.)
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: A new thread disappeared ?
Date: Thu, 04 Nov 1999 17:14:38 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>Yesterday morning I saw a new thread with a post containing a
>proposal to encrypt message P with two algorithms using a random
>string R and send out two ciphertexts. His wordings could be
>expressed like this:
>
> C_1 = E_1(R)
>
> C_2 = E_2(P xor R)
>
>But several hours later, when I tried to look at it again, the
>thread disappreared. I like to know whether this is a problem
>specific to my news server (i.e. you still see that article) or
>other people also experienced the same rather strange phenomenon.
>Thanks.
>
>M. K. Shen
I usually don't like such ideas since they double the lenght of
bandwidth required for sending and this does require a Random
file with all the problems associated with a random file. But if
a truely random file was used I think you may have the advantages
of a OTP with out the disadvantage of presending the random file
on a CD or whatever. But I would not send two files. Here is what
I would do.
1) compress "P" to a file "A" using my one to one compress or something
simlar
2) get file C_1 = E_1 ( R)
3) form file B = file A xor file R ( file B could be rotated and or padded
front and back based on R if one wish or needed it)
4) Form file D = alternating bytes of file B and file C_1 starting with file
C_!. ( again more complexity could be added her if wished. ) also
one may need extra bytes at end in some mods of the AES thing
5) get file C_2 = E_2(D)
then only send file C_2
this file is same lenght as the two files you sent but it is
only one file that needs to be sent.
for E_1 and E_2 I would use to totally differnt encryption methods
such as E_1 could be scott16u while E_2 could be scott19u or
if you prefer one AES method with one different method of your choice
but make sure that the methods do not change the lenght of files
encrypted since this could add bad info.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: Ian Wehrman <[EMAIL PROTECTED]>
Subject: Re: relative security of hashes, md5 vs. snefru
Date: Thu, 04 Nov 1999 11:44:25 -0600
zentara wrote:
> The linux group is starting to use signed files made with gpg, to
> verify files, suggesting that it is stronger than md5sum.
> How does it qualitively compare to 8 -pass snefru?
gpg can be used to compute a MD5, SHA1, or RIPEMD160 hash, by default.
it has no hashing capabilities of it's own.
later,
ian
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Steganography Academy
Date: Thu, 04 Nov 1999 10:56:28 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (JPeschel) wrote:
> [EMAIL PROTECTED] (wtshaw) writes:
>
> >In the light of my definition of what constitutes a strong cipher, how
> >much plaintext must be involved to confirm the correct key, all AES
> >candidates are near or in the weak category axiomaticaly.
>
> Then you better re-work your definition.
>
Rather than having no definiution of strength, or an inferior one, it is
better to recognize that several can exist that refer to actual properties
of algorithms. The point of the SSS# is that it is defined and useful to
some extent.
I also recognize other definitions of strength, and may well have to clean
up some of them for popular use as well. And, there are some in use that
are poor as being more politically applied than scientific.
--
Those who think that all useful encryption is done in binary
are destined to be thought of as mere bit-players.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: crypto and dependencies
Date: Thu, 04 Nov 1999 11:15:33 -0600
In article <7vpokv$2st$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> I'm trying to build a model for Internet Security, one component
> of which is cryptography. Upon what (example: time, bandwidth, ...)
> does "cryptography" depend for the purpose of generating capability
> trends?
>
The basis for good crypto has to be intelligent security in the local
platform and network. Meanwhile, generally, there is insufficient
security to begin to worry about the finer things that crypto can add
without being defeated on another level.
It is critical to realize that politicing can not sove technical problems,
and patches speak to trying to fix basic flaws which should not be there
to start with.
Yes, there are better plans, but many stand in the way of doing the
technical right thing. A spokesman for IBM has alluded to the main
problem at one level, consumer software pushed by greed with poor
foresight in honest security.
In short, scap the whole thing and buil it honestly better.
--
Those who think that all useful encryption is done in binary
are destined to be thought of as mere bit-players.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: A new thread disappeared ?
Date: Thu, 04 Nov 1999 11:20:30 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> Yesterday morning I saw a new thread with a post containing a
> proposal to encrypt message P with two algorithms using a random
> string R and send out two ciphertexts. His wordings could be
> expressed like this:
>
> C_1 = E_1(R)
>
> C_2 = E_2(P xor R)
>
> But several hours later, when I tried to look at it again, the
> thread disappreared. I like to know whether this is a problem
> specific to my news server (i.e. you still see that article) or
> other people also experienced the same rather strange phenomenon.
> Thanks.
>
It's not strange, either he or someone else removed the article, for
whatever reason.
It is supicious when good postings disappear. But the act is not that
frustrating to the driven, just one of those petty challenges that can be
overcome in a free society, as long as it is free.
--
Those who think that all useful encryption is done in binary
are destined to be thought of as mere bit-players.
------------------------------
From: Derrick Schneider <[EMAIL PROTECTED]>
Subject: Re: The Code Book
Date: Thu, 04 Nov 1999 08:46:28 -0800
As a beginning enthusiast in cryptanalysis, The Cipher Challenge is certainly not
beneath
_me_. Though it does seem like $15,000 isn't that much money for all the work
involved, it
looks like fun.
I, too, am currently working on stage 3. My hunch is that it's not one letter replacing
another, but is in fact one symbol replacing a letter, where each symbol is some
combination of characters. The number of characters evenly divides by two, but not
three,
so perhaps a digram represents a letter?
That's my current line of research, anyway.
Derrick
Nigel Mercier wrote:
>
> Has anyone tried "The Cipher Challenge" in "The Code Book" by Simon
> Singh? I know this will be beneath some of you guys, but I don't know
> where else to ask. If you can suggest a more appropriate group please
> let me know.
>
> I've cracked stages 1 and 2 (this has an interesting twist), but I'm
> stuck on stage 3: I don't understand how the homophones are included.
> I've noticed that the most frequent character is X (207) at twice the
> frequency of the next (Q, 103) which leads me to think that "X plus
> other characters" may be the homophones for some letters - leaving the *
> to represent another letter.
>
> Any ideas?
>
> --
> Nigel Mercier
>
> Please remove NOSPAM from my return address
------------------------------
From: "Charles Brockman" <[EMAIL PROTECTED]>
Subject: Re: The Beale Mystery
Date: Thu, 4 Nov 1999 09:17:52 -0800
Reply-To: "Charles Brockman" <[EMAIL PROTECTED]>
You might also read about Beale in Simon Singh's excellent "The Code Book."
(1999, Doubleday) Start in chapter 2 at page 82.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What is the deal with passwords?
Date: Thu, 04 Nov 1999 17:14:47 GMT
In article <[EMAIL PROTECTED]>,
John Kennedy <[EMAIL PROTECTED]> wrote:
> On Thu, 04 Nov 1999 05:20:15 GMT, Tom St Denis
> <[EMAIL PROTECTED]> wrote:
>
> >In article <[EMAIL PROTECTED]>,
> > John Kennedy <[EMAIL PROTECTED]> wrote:
> >>
> >> I didn't say it had to be. But 41k seemed pretty small to me for
the
> >> feature set described for this particular program.
> >
> >Actually the 1.70 version (to be released in two days) has the
> >following features
> >
> >) Can encrypt the keyring
> >) Can encrypt/decrypt files
> >) Can encrypt/decrypt messages upto 16kb using any one of seven
popular
> >ciphers
> >) Create/copy/add/delete public/private keys (dh keys)
> >
> >And is only 44kb. So beat that.
>
> Gee Tom, was it really fair to snip this?
>
> "I defer to the judgement of those with experience coding crypto."
Hmm, do I count as experienced? Even a little?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
