Cryptography-Digest Digest #905, Volume #10 Fri, 14 Jan 00 13:13:01 EST
Contents:
Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?) (Mike McCarty)
Analysis of new crypto regs (Eric Lee Green)
Free file encryption ("Speech Systems for the Blind")
Re: Little "o" in "Big-O" notation (Anton Stiglic)
Re: "1:1 adaptive huffman compression" doesn't work (Tim Tyler)
New Crypto Regulations ("John E. Kuslich")
Re: "1:1 adaptive huffman compression" doesn't work (Tim Tyler)
Re: SRP optimisation (John Myre)
Re: New Crypto Regulations (Eric Lee Green)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mike McCarty)
Subject: Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?)
Date: 14 Jan 2000 16:42:20 GMT
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
)Mike McCarty wrote:
)> )"The spirit is willing but the flesh is weak."
)> "The vodka is strong, but the meat is rotten."
)> Translated to Russian and back to English in the very early 60s by a
)> computer.
)
)That seems to be an urban legend.
That's interesting. Do you have any evidence? I recall having read the
story in a book in the early 60s which purported to give the name of
the machine, the name of the project, and the date on which it
occurred. Of course, the book may have been in error. Also, I do not
recall any of these details, since in the early 60s I was much younger
than I am now.
Of course, it is the *kind* of thing that could be a legend. I make no
claims either way.
)Although the general state of machine translation was (and is)
)such that such poor translations frequently occur. High-quality
)translation requires *understanding* the original, then
)re-expressing the thought in the new language. Machines just
)can't do that yet.
Actually, you misstate the situation. The state is such that poor
translations *always* occur. Good machine translation has yet to be
demonstrated, ever.
In fact, machine comprehension has yet to be demonstrated. And I agree
with you that comprehension of some sort is a necessary predecessor to
translation. Some reasonable progress has been made with comprehension.
You show your bias by using the word "yet". Why not just say "Machines
cannot do that at present"?
:-)
Good machine translation, like profitable fusion power, seems always 20
years away. It was 20 years away in the 50s. It is still 20 years away.
For all I know, it will always be 20 years away.
Mike
--
----
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: Eric Lee Green <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Analysis of new crypto regs
Date: Fri, 14 Jan 2000 09:48:13 -0700
I am now in possession of the newly published modifications of regulations
governing encryption exports, plus 15CFR740 and 15CFR742 which define "Mass
Market Encryption Products" and the export approval process (15CFR742
Supplement 6).
I realize that no one here is a lawyer and that a complete analysis of the
regulations is thus not reasonable to expect, but I'm having some
difficulties. On page 2493 of the Federal Register, Vol 65, No. 10, Friday,
January 14, 2000 section 4.c, it talks about "Retail encryption commodities
and software". No key length restrictions are mentioned in this paragraph
other than finance-specific non-mass market products with 56-bit key length
and 512 to 1024 bit key exchange, which are hereby classified as "Retail
encryption commodities". However, it says "Refer to 740.17(a)(3) for a
detailed definition of retail encryption commodities and software". Said
section says "key lengths up to and including 56 bits, such as DES or
equivalent".
Question: does anybody know whether the BXA is interpreting this to mean that
a "retail encryption commodity" is limited to a key length of 56 bits? But
page 2494, section 6(a) implies 64 bits. Regarding reporting requirements, it
appears that 64 bits is the maximum allowed (page 2494, section 6(a) ) without
detailed reporting requirements of end-user name etc., which are not feasible
for a mass-market retail product such as, e.g., Red Hat Linux, which is sold
through foreign wholesalers rather than directly exported to end users.
Has anybody had a chance to produce a "Cliff's Notes" version of what this
means to those of us who write retail software and are interested in providing
encryption protection for network communications between components of our
software?
Note: I have directed followups to talk.politics.crypto because this is
technical in nature only in that these regulations specify what I am allowed
to specify for encryption components for future export-capable releases of our
product line. Otherwise this is pure politics. Flames to /dev/null, as
usual...
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: "Speech Systems for the Blind" <[EMAIL PROTECTED]>
Subject: Free file encryption
Date: Fri, 14 Jan 2000 11:59:10 -0500
--
http://www.aasp.net/~speechfb
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Little "o" in "Big-O" notation
Date: Fri, 14 Jan 2000 11:57:53 -0500
==============14B0292827D2BE5FF717B246
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
>
>
> I have never seen O and o used as the names for *sets*. It would not be
> consistent with
>
> f(x) = x^2 + O(1/x)
>
> unless f(.) were somehow promoted to a set as well.
>
Most algorithmics books will use the set defintion, most
math books will use the limit definition.
The bible of algorithms book (Introduction to Algorithms,
from Cormen Leiserson and Rivest) have the set notation,
see also Algorithmics, from Brassard and Bratley (another
excellent alogorithmics book).
Anton
==============14B0292827D2BE5FF717B246
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<blockquote TYPE=CITE>
<p>I have never seen O and o used as the names for *sets*. It would not
be
<br>consistent with
<p> f(x) = x^2 + O(1/x)
<p>unless f(.) were somehow promoted to a set as well.
<br> </blockquote>
<pre>Most algorithmics books will use the set defintion, most</pre>
<pre>math books will use the limit definition.</pre>
<pre>The bible of algorithms book (Introduction to Algorithms,</pre>
<pre>from Cormen Leiserson and Rivest) have the set notation,</pre>
<pre>see also Algorithmics, from Brassard and Bratley (another</pre>
<pre>excellent alogorithmics book).</pre>
<pre></pre>
<pre>Anton</pre>
</html>
==============14B0292827D2BE5FF717B246==
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: "1:1 adaptive huffman compression" doesn't work
Reply-To: [EMAIL PROTECTED]
Date: Fri, 14 Jan 2000 17:17:22 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
:> : Do you think that my proposed scheme has 'practically' solved the
:> : problem or not?
:>
:> In practice, the Huffman ending problem appears to offer the attacker few
:> footholds anyway. Seven bits per message may compromise some systems,
:> but not very many. At worst it knocks this number of bits off the
:> keyspace. Most systems should withstand this, most of the time.
:>
:> I don't know if your scheme reduces the problem to acceptable levels.
:> What is "acceptable" depends on your application.
: May I remark that your last-but-one sentence says nothing in a
: scientific discussion? I could similarly say 'I don't know' this and
: that and a lot of other things. If you want to show the weakness of
: someone else's argument, please show it plainly and with sharp focusing.
What do you mean by ``your scheme has "practically" solved'' the problem?
There are reminaining security issues, which could result in attacker's
gaing knowledge under special circumstances.
How can I see if your solution is "practical" when there's been no
definite statement of the domain of the problem?
Your scheme leaves issues unresolved. I would not be completely satisfied
with it.
:> I see your scheme as an source of unnecessary and easily eliminated
:> potential weakness. I don't see what the problem is with using the ideal
:> Huffman file ending scheme, now that it has been discovered.
: I have said many times that I don't claim my scheme is better.
: As to 'potential weakness', I repeat what I said above: Please show
: it.
My "compressed password" example did this. My failed message, which
needed recompressing and retransmitting did this.
I'm getting bored with giving examples, only to be asked the same
questions over and over again.
:> : How does one proceed to exploit the 'certain non-random stuff'?
:>
:> I've given in some detail one way the analyst might get information from
:> this, even if the padding is /totally/ random.
:>
:> Giving the analyst unnecessary information about plaintext statistics in
:> messages is not a good idea. I'm sure you can figure out what an analyst
:> can do with such information for yourself.
: If I append 'periodically' to my encrypted messages with the plaintext
: 'AA', 'AB', 'BA' and 'BB'. What can the analyst do with that??
Gain information from consecutive messages relating to the bit sequence of
the compressed file which he would not otherwise have, for a start.
:> : Please tell me a 'concrete' way to get some 'information' out of
:> : these that is 'actually' sensible to his task, namely to decrypt
:> : to obtain the information in the bit sequences 'preceeding'
:> : these 2 filling bits.
:>
:> If he has one message, his job is not easy. Also, your question
:> is not necessarily the right one. With two bits of information, he's
:> not going to get /much/ useful information about the rest of the message -
:> unless the message has a two bit key.
:>
:> I've explained how /even/ totally random padding can give the analyst
:> information he wouln't haveif a deterministic compressor had been used,
:> that might help identify the sender.
: That's interesting. I said in another post the compressor is public.
: HOW is the analyst going to identify the sender with the compressor
: the sender uses, since anyone can use that compressor??
I thought I explained. The compressor doesn't identify anything
really. It's the bits at the end of the file that scramble an enitr block
that do the revealing. They can show (for example) the size of the block
size - or give other clues about the cypher being used.
If you know the different parties present use different types of cyphers,
information about the cypher used reflects on the identity of the sender.
:> :> : In fact, I don't need 'true randomness', nor even
:> :> : 'pseudo-randomness', only 'non-constancy'.
:> :>
:> :> This won't do at all, IMO.
:>
:> : Please explain.
:>
:> You think (say) preferentially padding with zeros is generally acceptable
:> behaviour, despite the fact that it gives away probably-known plaintext?
: Always padding with zeros may notbe good, but padding with stuffs
: that vary periodically (all different patterns have almost equal
: frequency of occurence) doesn't leak information in any practical
: sense in my opinion.
Our opinions differ.
: You can simply regard these as sepeate messages
: that 'happen' to be 'attached' to the proper messages. Since the
: content of these attached messages has nothing that needs protection,
: it follows that it doesn't matter whether the analyst correctly
: get them or not.
No. Not correct. They are attached /before/ encryption. If they were
(say) all zero, that would allow rejection of decrypted messages, based on
decrypted files. It is not just all-zero message padding that allows
this. *Any* pattern that can be predicted by the analyst has the
same effect.
:> Would you more more concerned if you were padding to a 128-bit block
:> rather than an 8-bit one?
: No, if the padding patterns occur with equal frequency and after
: seeing one pattern one does not know which is the next to be expected.
: (Please note that the compressor may deterministically emit the
: filling bit patterns. But this is only for the case in the present
: context when the analyst 'repeatedly' uncompress-compress the 'same'
: stuff that he obtains with one particular trial key. He knows that,
: if the key he assumes were indeed correct and the sender were to
: send the same message once again, he has equal chance of seeing
: other filling bit patterns. Hence the particlar pattern he sees
: tells him nothing.)
You are wrong. I've explained the problems with this reasoning enough
times now. "Equal chance" of seeing other filling patterns over a
period of time is not sufficient. The patterns have to be random
(given the constraint that they not form any complete Huffman symbols).
:> I was under the impression that giving away probable plaintext to
:> attackers was generally considered undesirable. I'm a bit puzzled
:> about being asked for "supporting material". The attacker gains
:> statistical knowledge about the plaintext, which was previously
:> unavailable to him. What more do I need to say?
: See what I wrote above about the 'attached messages'.
That gives me some insight into what's going on inside your head,
I suppose.
:> I'll give an example, which should demonstrate how an analyst might be
:> helped.
:>
:> He has a bunch of messages, which he knows from the context of
:> their interception contain encyphered-compressed password data.
:>
:> The passwords were generated by a random number generator.
:>
:> Each password is encyphered with its own key.
:>
:> The analyst wants access to the passwords.
:>
:> [In this instance compression doesn't help, but the compressor was built
:> into the cypher-machine.]
:>
:> The analyst has access to a captured table of keys to the cypher
:> - but he doesn't know where the user started in his key table, so he tries
:> starting positions one at a time, assuming consecutive keys were used
:> for consecutive messages, as specified in the manual of a captured
:> machine.
:>
:> Since the messages themselves are random, his only source of information
:> is the padding used by the compressor. If he decyphers a large number of
:> password files in a row, and they exhibit the same statistical anomalies
:> that are introduced by the padding scheme of the compressor, he knows he
:> has found the correct starting key.
:>
:> None of this would have bneen possible, were it not for a very few
:> non-random bits information appended to the files.
: Are you saying that the assumption that consecutive passwords are
: encrypted with consecutive keys helps the analyst?
In my example that is true. It's harly much of an assumption,
since he has the operating instructions of the machine to hand.
: But what has this to do in the present context?
Why, nothing, except apparently to distract you from my main point.
Recall that this was that statistical deviations from randomness in the
endings of compressed files can completely give away all the content of
the messages under circumstances where 1-1 compression would have
left the analyst in a hopeless position.
: Here the analyst tries a key
: K to get a compressed file which he finds, say, to have 2 filling
: bits 00. On repeated uncompresion-compression he finds other
: patterns (01, etc) and that all these patterns occur equal frequently.
: So that original '00' is nothing 'particular' and hence he can't
: derive any information from that particular occerence of the
: filling bits, can he?? (Sorry that I repeat what I said.)
Equal frequency != random. If the endings are random, the analyst gains
nothing. But if there's any detectable pattern, all may be lost.
As a crude example 1010101010101010 has the same frequency of 0s and 1s as
a typical random string - but is *very* easy for an analyst to spot.
:> : In the example case mentioned above, all four filling bit patterns are
:> : 'equally likely', there is no 'most likely' one. Could the analyst
:> : still do something with his 'statistical data' of the filling bits?
:>
:> You said they were used in sequence. Consequently he knows that if the
:> message has a two-bit padding - he knows which two bits will be used.
:>
:> Consequently some bits *are* more likely than other ones - despite each
:> two-bit sequence being used with equal frequency.
:>
:> Can the attacker do anything with this? It's not very likely that he can
:> do much with 1/4 of a bit. Analysts are clever folk, though. I wouldn't
:> like to say it was always totally useless.
: If an analyst tries a key K1, he can do uncompress-compress to find
: out what the filling bits (and of course how many filling bits) the
: original sender's compressor 'happened' to have used, IF indeed the
: key K1 is correct. If he tries another key K2, not only the pattern
: of the filling bits but also the length will generally be different.
: So he doesn't know even the length of the 'correct' filling bits
: through trying different keys.
Indeed not. However he has a 1/8 chance of getting a message with
these bits and his knowledge of these bits (should they crop up) means
that the distribution of expected messages is no longer random.
Files ending with the two padding bits he is expecting are more common
than usual. The analyst *can* sometimes use such information - as in
the "compressed password" example I gave.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Laugh and the whole world thinks you're an idiot.
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: New Crypto Regulations
Date: Fri, 14 Jan 2000 10:27:17 -0700
I hereby dare anyone to tell me that he/she has read and understood the
new crypto regulations. They are simply beyond comprehension and
deliberately so. These regs will make many a lawyer rich!
see http://www.cdt.org/crypto/admin/000110cryptoregs.shtml
What kind of government can get away with making laws the meaning of
which are not clear until such time as one is prosecuted for violating
such laws?
What kind of government can require a technical review of products for
sale and not have clearly defined the technical requirements until the
product comes under review?
What kind of government can prohibit or license the sale of "Tempest
fonts". These are fonts (software) intended to reduce compromising
emanations. That's right, BXA, under the new crypto regs can stop
export of software designed to allow someone to eavesdrop on the
electromagnetic emanations from your computer!!!!
Here's the quote:
"a.4. Specially designed or modified to reduce the compromising
emanations of information-bearing signals beyond what is necessary for
the health, safety or electromagnetic interference standards;"
It appears under "items controlled" way down near the end of the revised
EAR document.
Perhaps the answer is a government led by a man who can lie under oath,
violate his marriage vows with a post pubescent bimbo in the Oval
Office, and keep a Cabinet together after using them to lie to the
public and assist in the cover-up of his immoral acts.
If we allow our executive to make our laws under the guise of regulation
(remember, the Congress is supposed to make the laws and the executive
enforce them) we will deserve our fate.
These regulations are an abomination and should be completely removed by
an act of Congress.
After all, we do have the best Congress money can buy. Perhaps we
should tell BXA to stick it in their EAR.
Here is their e-mail address: [EMAIL PROTECTED]
Tell them what you think.
JK
--
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.com
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: "1:1 adaptive huffman compression" doesn't work
Reply-To: [EMAIL PROTECTED]
Date: Fri, 14 Jan 2000 17:24:34 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
:> : My proposal is able to satisfy the requirement you
:> : originally raised, i.e. to give the analyst no information via
:> : the decompression-(re-)compression process.
:>
:> Which it would do reasonably well, /if/ you could get hold of some "real"
:> random numbers. Getting hold of them in a portable way would be better
:> still.
: I have explained in a previous follow-up that one needs only
: 'non-constancy'.
Any such "explanation" was not explaining something that was correct.
: Here is a repetition: Suppose the decrypted
: compressed file is uncompressed and compressed again. The two
: files can be compared to easily find out the filling bits. Suppose
: the old and new filling bits are 00 and 11 respectively. What
: information does the analyst get from that? He knows that if, for
: example, he contitunes to do uncompress-compress he will get
: in most cases different filling bits. So from these filling bits
: he knows nothing. If you don't agree with this, please kindly show
: where my argument is wrong with details. Simply claiming that it
: doesn't work or doesn't work well is not sufficient.
The analyst can gain information in the "compressed password" example I've
already given. Also in the previously given "corrupted message" example -
which involved recmpression and resending of a message.
If the bits are predictable, the analyst may be able to predict them.
If he can do that, he can (for example) identify a series of correctly
decrypted messages. This is not good. Padding bits need to be as
random as is practical, in order to best resist such attentions.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Hey - that's not ANSI 9660 - that's DREADFUL.DOS!
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: SRP optimisation
Date: Fri, 14 Jan 2000 10:44:30 -0700
Keith Burdis wrote:
<snip...>
>
> As noted, three messages is the lower bound for a secure authentication
> protocol, but would it not be possible to have:
>
> C --> S: C,A
> C <-- S: s,B,M2
> C --> S: M1
>
> where:
>
> M1 = H(B,M1,K)
> M2 = H(A,B,K)
The definition of M1 makes no sense. Do you mean M1=H(B,M2,K)?
> This allows mutual authentication to take place in three rounds instead of
> four.
>
> Can anyone see any problems with this?
Yes - see below.
> Does having the server send its evidence first adversely affect the
> security of SRP in any way?
Now the adversary can do an off-line password guessing attack. With
the four-message version, the server doesn't provide M2 (which can be
used to verify a guess of a password) until it checks M1 (which proves
knowledge of the password). In theory, with SRP you can't check a
password guess except by trying to log on, as long as you don't break
in to the server itself.
(The attack on the 3-message version would be: start the log on, then
quit as soon as you get M2. Then guess different passwords until you
can compute M2 yourself).
John M.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: New Crypto Regulations
Date: Fri, 14 Jan 2000 10:59:31 -0700
"John E. Kuslich" wrote:
>
> I hereby dare anyone to tell me that he/she has read and understood the
> new crypto regulations. They are simply beyond comprehension and
> deliberately so. These regs will make many a lawyer rich!
I have my own concerns. By dividing things into multiple categories by market,
e.g., e-commerce, retail products, and banking products, each of which has
completely different requirements, we would basically be required to maintain
three different versions of our products, with three different sets of
reporting requirements etc. As small businessmen we simply cannot afford to do
that. Several banks have asked that we provide capability to encrypt network
communications and tape storage using 3DES, which apparently is the current
standard in the financial world, but at the moment we just don't have the
capability to have multiple versions of our product, and probably never will.
So we lose that business.
At a minimum, the regulations must be simplified so that smaller vendors such
as my employer can produce one product which meets the needs of all
marketplaces. Otherwise we shall remain at a competitive disadvantage.
I am currently writing a letter to Mr. Ruggiero with more detailed
explanations of my concerns and how the regulations as currently written
appear to adversely affect small businesses such as my employer. I suspect
that will get dumped into a wastebasket, but probably not as swiftly as a
flame-riddled EMAIL message. And best case, we COULD get a more comprehensible
set of regulations out of the BXA, without so many special case situations
that would prevent us from producing a single retail product that meets the
needs of all target marketplaces.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
** 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
******************************
