Cryptography-Digest Digest #90, Volume #11 Thu, 10 Feb 00 14:13:01 EST
Contents:
Re: Message to SCOTT19U.ZIP_GUY ([EMAIL PROTECTED])
Re: Guaranteed Public Key Exchanges (Darren New)
Re: Guaranteed Public Key Exchanges (Mike Rosing)
Re: RE (Mike McCarty)
Re: Court cases on DVD hacking is a problem for all of us (wtshaw)
Re: Latin Squares (was Re: Reversibly combining two bytes?) (wtshaw)
Re: Does hashing an encrypted message increase hash security? (Bill Unruh)
Re: NIST, AES at RSA conference (Terry Ritter)
Re: I'm returning the Dr Dobbs CDROM (Vernon Schryver)
Re: NIST, AES at RSA conference (Terry Ritter)
Re: NIST, AES at RSA conference (Terry Ritter)
Re: Persistent vs Non-Per DH for Voice (Mike Rosing)
Re: micropayments and denial of service? (Roger Gammans)
Re: NIST, AES at RSA conference (David Wagner)
Re: NIST, AES at RSA conference (David Wagner)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Message to SCOTT19U.ZIP_GUY
Date: Thu, 10 Feb 2000 18:02:14 GMT
HERE IS YOUR MESSAGE IN FULL POSTED A WHILE BACK....Perhaps you and Tim
or anyone else would care to Comment on IT:::::::::
**********************************************************************
I know most of you will never have access to good ciphers. The NSA and
crypto gods will see to that. But it does not
mean that
you can't use some of the weak AES methods and still obtain a
far higher degree of security than what they want. Below is a
procedure that is "not all or nothing" but would allow one to encrypt
by removing the so called error recovery "feature"
that most people are stuck using.
Here it is in a nutshell You need 3 ciphers and 2 one to one
compressions to achieve the results. IF you have access to the
routines them selves it can be done in one pass since each method works
on the data previously processed but I will
explain it as 5 passes.
Pass one Encrypt with AES using weak 3 letter chaining even ECB
Pass two use Compression A "explained latter"
Pass three Encrypt with different key (with different method if one
wishes} Pass four use Compression B
Pass five Encrypt with different key
For the truely insecure among you. You can make this "all or nothing"
by reversing the byte order in the file after each
compression. But that requires whole file at one time..
Know for a disccusion of how to implement the Compression.
by Compression A I mean one of my one to one compressions that
uses a "condition file" with all 256 possible characters. This makes a
starting tree that can be greatly varied. But since
compression is one to one no information is added to data stream. Also
the message will as it passes through the
compression will change in length so that it is highly unlikely that
one can know where a block from the previous
encryption layer is passed to next encryption layer and it is highly
unlikely to even be the same length. For Compression B
you use a different "condition file" with all the 256 possible
characters in the file.
The input file should be at least long enogh for a few blocks to be
encrypted or you can reject the file as to short. Notice
also that each compression will most likely make the file longer and
that
the encryption methods should handle short blocks at the end of files.
Most methods already have a way to do this but if
at least one block is encrypted on each pass you can just pass the
short block without doing anything to it. Since the
state of the adapative huffman compressor will be such that the data in
last block will be transformed by the
compression.
Any thoughts on this by my nonadmirers.
David A. Scott
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Guaranteed Public Key Exchanges
Date: Thu, 10 Feb 2000 18:13:23 GMT
> I totally agree, but *how* or *is* there a way to do it securely?
I think you're missing my point. You're emphasizing "securely" and you
haven't even defined "do it" yet. Do *what*? Communicate with someone you
never communicated with before and know nothing about? No, you can't do
that, since you don't even have any way of getting in touch with them, since
you don't know them and can't look up their phone number in the phone book.
Can you exchange keys securely with Joe Bloom if you never met Joe Bloom
before but now someone claiming to be Joe Bloom is standing before you? No,
since you can't tell whether that's Joe Bloom or not. Can you exchange keys
securely with me if we're standing face-to-face? Sure. But all that's saying
is it's more likely that the person standing in front of you isn't really
Darren New than it is likely that there's a man-in-the-middle in a
face-to-face meeting.
My point is that you're asking the wrong question. You need to ask "how
securely can I do it?" Is the likelyhood of a secure key exchange higher
than the likelyhood of you really just being a brain in a jar hooked up to a
big simulation computer? Is it more likely than someone hacking into the
telco and forwarding your calls to someone else to answer with a
hacked-and-spliced Dan Rather clip telling you what Dan Rather's PGP
fingerprint is? Is it more likely that I bribed or threatened a notary to
certify that the key I'm sending you really does belong to George Bush?
When you answer the question "why am I exchanging keys with this person"
you'll have a better idea of how to do it securely.
--
Darren New / Senior Software Architect / IZ, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
There is no safety in disarming only the fearful.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Guaranteed Public Key Exchanges
Date: Thu, 10 Feb 2000 12:17:10 -0600
No Brainer wrote:
> > Nope. You gotta have an out of band exchange to prove no intercept.
> >
> > For most applications, the probability of an intercept is small so it's
> > not that big a deal. But if you are going to really worry about it, you
> > have to assume your line is controlled by the "enemy" and you need more
> > than one channel of comm-link to ensure the exchange was clean.
>
> Oh :(
>
> Cheers :)
In one thread you asked how to do it securely. One out of band method
is
a newspaper. Take out an ad in the classfied section an just publish
the ascii text of your public key. It's easy enough for anyone to check
that.
If you are advertising a product, and you want people to get your stuff
using public key exchange, you can put the key (or its "fingerprint" ala
PGP) in the ad. It's an out of band solution not involving phone calls.
It's also just one way. You don't know who's going to link to you, all
you know is that they know they've got a link to you!
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Mike McCarty)
Crossposted-To: talk.politics.crypto,misc.int-property,misc.legal.computing
Subject: Re: RE
Date: 9 Feb 2000 23:00:23 GMT
In article <4ajn4.366$[EMAIL PROTECTED]>,
C. Prichard <[EMAIL PROTECTED]> wrote:
)Its my understanding that almost all laws are meant in a social context.
)
)That is to say that they are not even intended to reach into your =
)privacy. What you do in private is of no concern to the government =
)(sometimes referred to as 'the people') regarding these laws whatsoever.
It may sometimes be referred to that way, but if so, it is incorrect.
Please read the Constitution of the United States of America:
We the People... do ordain and establish this Constitution for
the United States of the America.
Clearly the People pre-exist the Government, and create it.
)The line is drawn where there is something that you do socially like =
)distribute information, or a product to others.
)
)-C. Prichard
)
)
)
--
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for Alcatel <- They make me say that.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Court cases on DVD hacking is a problem for all of us
Date: Thu, 10 Feb 2000 11:26:05 -0600
In article <[EMAIL PROTECTED]>, "Dr.Gunter Abend"
<[EMAIL PROTECTED]> wrote:
> If you *buy* some good (instead of leasing it), might the previous
> owner impose such restrictions on it? Only the *government* may
> restrict the use of your property, and only if it causes some harm
> to the public or the environment. Do you know any example of
> restrictions like those on DVD *players* -- which are not allowed
> to play all DVDs?
>
> DeCSS can only be used to enable my *player* -- and if this is not
> forbidden, why do they accuse Jon Johansen?
>
A simple solution is not a solution if it creates additional problems.
--
If Al Gore wants to be inventor of the internet, complain that he
did a lousy job. If he admits to not doing much, complain that he
is a slacker. Now, do we want him in charge of security?
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Latin Squares (was Re: Reversibly combining two bytes?)
Date: Thu, 10 Feb 2000 11:23:23 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> That's the point. With Latin squares, the probabilities get more
> uniform.
Consider Swagman, which specifies such a square for the key. I hear that
there is a Lazy Swagman, but figure it violates some rule. Perhaps
someone will fill in the details.
Obviously a Swagman is limited by design to a fairly small key block, but
the idea of trying to obscure the key components is the same for any size.
--
If Al Gore wants to be inventor of the internet, complain that he
did a lousy job. If he admits to not doing much, complain that he
is a slacker. Now, do we want him in charge of security?
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Does hashing an encrypted message increase hash security?
Date: 10 Feb 2000 18:24:31 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Erann Gat) writes:
]Suppse I do the following:
]1. Generate a 128-bit MD5 hash of a message.
]2. Generate a second 128-bit MD5 hash of the same message encrypted
]with (say) Blowfish using an N-bit key.
]3. Concatenate the results together to form a 256-bit hash.
]Does the resulting 256 bit hash have any more security than the
]original 128-bit MD5 hash by itself? How much more? What if
Of course a 256 bit hash is more secure ( ie harder to find collisions
for) than a 128 bit hash. Even say MD5(text)+MD5(ROT13(text)) would be
safer. What do you want it for?
]the Blowfish encryption key is known -- is there still something
]to be gained in terms of hash security by concatenating a hash
]of the cleartext with a hash of the Blowfish ciphertext?
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: NIST, AES at RSA conference
Date: Thu, 10 Feb 2000 18:37:04 GMT
On 10 Feb 2000 11:57:04 +0000, in <[EMAIL PROTECTED]>, in
sci.crypt Alan Braggins <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Terry Ritter) writes:
>> with any reasonable probability. And we already know that the problem
>> is not restricted to the mathematical definition of groups, so there
>> is no technical name for it. In the end, adding a non-groupy
>> assumption would seem to be reasonable progress.
>
>But unless you have a technical _definition_ for "groupy" more precise
>than "causes this sort of problem", you're just saying "we can prove
>that for those ciphers where there is no problem, there is no problem,
>but we can't be sure which those ciphers are". Which doesn't seem like
>progress at all.
You seem to have a definition of "progress" which to me sounds more
like "success." And right now! But "progress" is the road, not the
destination. Progress includes the false turns and breakdowns and
asking for directions as well.
Eventually there will have to be some tight definition for "groupy,"
but just the idea that we must have something like that starts the
process of thinking what that could be. We can also say, "assuming we
have 'non-groupy,' then what can we do?" It thus allows us to address
two sub-problems which each begin to have distinguishable technical
features instead of one monolithic problem which provides no clue
about technical details.
For example, the claim that Simple Substitution is "groupy" is only
partly right: Sure, if we can key any possible state for the
substitutions, we have a group. But for the huge simulated Simple
Substitutions we call "block ciphers," we can key-select only a tiny,
tiny fraction of their possible transformation sets. So if we have
two different keying systems for these large substitutions, it is
improbable that their multiciphering result will be reachable by any
key in either system; thus, they generally will *not* be "groupy."
The problem we have with this is that many academic ciphers are
constructed in some sense similarly. To me this means that there is
at least the possibility that their keying sets may be more closely
related than we would expect of random samples from among all possible
keyings. That would make groupiness more likely between those
ciphers.
Now, does that seem more like "progress?"
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: I'm returning the Dr Dobbs CDROM
Date: 10 Feb 2000 11:30:04 -0700
In article <[EMAIL PROTECTED]>,
Victor Zandy <[EMAIL PROTECTED]> wrote:
> ...
> I don't know how the PDF files on the CDROM were prepared, but
>they look like they were scanned from physical book pages. For recent
>titles, like Stinson, they should have been generated from the
>computer originals to make a smaller file, with better image quality.
>
> Several people who responded to me said they appreciate being able
>to search and cut-and-paste the text on the CDROM. ...
That comment spawned many responses about how to deal with bit maps,
scanned images, and even compressed FAX pixels, but never answered a
question that leaped out at me.
If the contents are only scanned images, then how can you "search and
cut-and-paste the text"?
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: NIST, AES at RSA conference
Date: Thu, 10 Feb 2000 18:37:33 GMT
On 9 Feb 2000 23:38:17 -0800, in
<87tpt9$pi4$[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (David Wagner) wrote:
>In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
>> It is clear to me that you think all we need to do is have some
>> academics check out candidate ciphers (even though we really don't
>> know how much effort anyone in particular has put into doing that),
>> then society should use the result.
>
>Terry, it seems to me that your statement is primarily subjective in
>nature: You are not personally comfortable with the level of assurance
>provided by the AES candidates.
>
>That's perfectly fine. Indeed, figuring out what level of assurance
>we are each comfortable with surely requires a necessarily subjective
>and personal assessment. But I hope we can agree that this is an issue
>that reasonable people can rationally disagree on [*], and no matter how
>much we discuss it back and forth, it is unlikely that we will come to
>any widespread agreement. Fortunately, we need not all agree.
I think there is a professional responsibility to recognize what is at
stake here, and that goes far beyond personal opinion. At risk is
nothing less than the security of the entire information society.
The two sides of this opinion are not equal: If I want various other
security features in the system and I am wrong, then society may have
spent a little more than it needed to spend. But I do mean "little":
once the decision is made, I would expect the result to cost about the
same. Applications which use ciphering would be slightly slower.
The other side is to say, "we don't need those features." But if
*that* is wrong, we place at risk the entire information society.
Now, we can refine this reasoning, for it is clear that what I propose
cannot solve every possible problem, and if not, what is the point?
The point is that we *should* do what we *can* do, and not use the
slimy reasoning that since the added features also offer no proof of
strength they are no improvement at all.
>Perhaps it would be more productive to discuss the science: if we find
>ourselves in a situation where we are unhappy with the assurance level
>offered by the available cryptographic primitives, what techniques will
>be most effective for remedying that situation?
>
>You've already suggested multi-ciphering as one possibility.
I have presented a whole list of possibilities. Repeatedly.
>How does
>that compare to just bumping up the number of rounds by a corresponding
>amount, without introducing heterogenous round structures?
I think it is reasonable to fear attacks which target the constituents
of the round operation. That is an unchanging structure which is just
asking to be attacked. I doubt that simply increasing homogeneous
rounds would foil such attacks.
>How does that
>compare to "frequent re-keying" techniques, a la those advocated by John
>Savard on this forum (and others elsewhere)?
That is of course an old suggestion. In the ultimate extension, we
have a stream meta-cipher using a block cipher which is differently
keyed for every element. Now we need a keying sequence (smaller than
the data, presumably), which becomes one of the targets, so it should
not be trivial. I think this can be very useful, and indeed should be
a great benefit as a different sort of structure. But I still would
prefer to see any such cipher protected by other ciphers.
>What other possibilities
>are there? What metrics might one use to assess the merits of the
>competing proposals?
One thing we can do is to talk about specific known attacks which are
complicated by the additions.
It might be reasonable to take some ciphers which have been found weak
under specific attacks, or to generate some ciphers which would be
weak, and then see how they are strengthened by additions, with
respect to specific known attacks.
>Just a suggestion. I'm curious to hear your thoughts, but as always,
>feel free to ignore this post if you don't find it useful.
>
>-- David
>
>
>[*] Of course, if anyone relies on faulty logic in coming to their
>judgement, it is only kindness to point out flaws in their logic, but
>that's a special case.
I think it would be worthwhile to get some other people into the
conversation who can do some of the work of challenging the false
logic which often appears here. One person can do only so much, and
if I am doing it all, it makes me look crazy, it makes me feel crazy,
and then I don't have anything left for anything else.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: NIST, AES at RSA conference
Date: Thu, 10 Feb 2000 18:38:17 GMT
On Thu, 10 Feb 2000 04:36:52 -0600, in
<87u4c5$ne5$[EMAIL PROTECTED]>, in sci.crypt "Rick Braddam"
<[EMAIL PROTECTED]> wrote:
>[...]
>The danger can be averted. One cipher can be selected as "must
>implement", the others selected as "may implement". Procedures can be
>put in place to evaluate new candidates *as they are developed* and add
>them to the "may implement" list. The standard could restrict business
>with the US Govt to the "must implement" cipher while implicitly
>endorsing the others (for other uses) by their inclusion in the
>standard.
It seems to me that a required basis for this is to have a
standardized cipher *interface*, separate from standard ciphers. Then
at least we can change ciphers when and if necessary. In particular,
I would like to see the concept of a replaceable "cipher" include
keying from an arbitrary string (passphrase or random binary). This
seems necessary because various use a massive internal state which far
larger than a simple hash result.
>Were the AES candidates developed *just* for the standardization
>competition, or were they already in development? In other words, did
>the AES competition stimulate the development of ciphers which may not
>have been developed without it? I think we need a continuous AES
>competition, with no limit on the number of "may implement" ciphers.
>Different classes of users have different requirements for ciphers, and
>the more "approved" ciphers available the more likely one of them will
>be the best fit for a class of user.
>From my view, part of the problem with AES is that it eliminates the
direct financial advantage for the creation of a good cipher. That
does not help generate the industry of cipher design (and related
analysis tools) that we need. We need to employ good people to work
on this all day every day for years, with a corporate memory of their
intermediate results. We need teams of experts with substantial
resources and no other responsibility. We have to pay for that.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Persistent vs Non-Per DH for Voice
Date: Thu, 10 Feb 2000 12:37:43 -0600
[EMAIL PROTECTED] wrote:
>
> A number of Voice encryption systems (PGPFone etc)have been developed in
> the past using Non-Persistent DH using Secret Sharing to ensure Forward
> Secrecy. The DH keys are volatile and last only for the session
>
> I would like to know, if the technology of using Persistent Keys ( DH or
> RSA) is more secure for voice communications or a better method
> (authentication, Integration with digital certs etc).
Bad idea. If you call the same person you want a different session key
each time for maximum security.
> One can envision using a smart card with Secret/Public key pairs for
> encryption and authentication.....
>
> Would like input on these two approaches...
>
> The recent starium startup seems to go for the first approach....But
> that is just a hint..they have not published any details...they have a
> smart card, I guess for authentication only.
Something like the MQV algorithm would work pretty well with this.
Use the permenent key for authentication (generated at the shop where
the card is purchased) and ephemeral key for creating the session key.
It's been 6 years since the MQV algorithm was first implemented, and
no patent has issued yet (although it's claimed one is being pursued).
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Roger Gammans)
Subject: Re: micropayments and denial of service?
Date: Thu, 10 Feb 2000 18:45:20 GMT
In article <[EMAIL PROTECTED]>, Glenn Larsson wrote:
>[EMAIL PROTECTED] wrote:
>
>>I understand that denial of service attacks are usually done
>>indirectly through compromised sites.
>
>Wrong. Source of orgin forgery is standard practice.
Maybe, maybe not.
CA-99-17 documents TFN2K, which works in a manner like Bob originally
described.
Of course this doesn't prevent use of ip-spoofing as well.
TTFN
--
Roger
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: NIST, AES at RSA conference
Date: 10 Feb 2000 11:02:41 -0800
In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
> From my view, part of the problem with AES is that it eliminates the
> direct financial advantage for the creation of a good cipher. That
> does not help generate the industry of cipher design (and related
> analysis tools) that we need. We need to employ good people to work
> on this all day every day for years, with a corporate memory of their
> intermediate results. We need teams of experts with substantial
> resources and no other responsibility. We have to pay for that.
How much would it cost to assemble a team of experts as good as,
or better than, today's de facto ragtag assembly of academics and
others? My expectation is that -- even if you can find the bodies
-- it might be extremely expensive. (And finding the bodies might
be even more of a challenge: there seems to be a very limited number
of people in the industry with the required background, skills, and
experience to do the job.)
Do you have any sense for what the costs might run to, and who might
fund it? (NIST is poor, so they certainly couldn't fund it.)
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: NIST, AES at RSA conference
Date: 10 Feb 2000 11:06:03 -0800
In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
> The two sides of this opinion are not equal: If I want various other
> security features in the system and I am wrong, then society may have
> spent a little more than it needed to spend. But I do mean "little":
> once the decision is made, I would expect the result to cost about the
> same. Applications which use ciphering would be slightly slower.
One problem is that there are also many applications where
if the crypto is too slow, they'll just ditch it. (Put another way,
the crypto is low on their priority list, so they'll only consider
using it if it's cheap and easy and free.)
If we standardize on a slower, more over-engineered cipher, we have
to balance the reduced risks of compromise against the increased number
of systems which will decline to use the crypto. It seems challenging
to find the right balance.
> It might be reasonable to take some ciphers which have been found weak
> under specific attacks, or to generate some ciphers which would be
> weak, and then see how they are strengthened by additions, with
> respect to specific known attacks.
Agreed!
------------------------------
** 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
******************************
