Cryptography-Digest Digest #117, Volume #10 Fri, 27 Aug 99 00:13:03 EDT
Contents:
Re: Can americans export crypto when in another country? (SCOTT19U.ZIP_GUY)
Re: NEW THREAD on compression (SCOTT19U.ZIP_GUY)
Re: Wrapped PCBC mode (SCOTT19U.ZIP_GUY)
Re: Where to find (SCOTT19U.ZIP_GUY)
Re: cryptographic DLL (Aidan Skinner)
What the hell good is a session key! (Anonymous)
Re: 2 person data exchange - best method? (Terje Mathisen)
Re: How does RC4 work ? (Wil Baden)
Re: RSA and Microcontroller (Paul Rubin)
Re: One-time pad encryption. ("rosi")
Re: Can americans export crypto when in another country? (wtshaw)
Re: NIST AES FInalists are.... ("rosi")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Can americans export crypto when in another country?
Date: Fri, 27 Aug 1999 01:18:29 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Doug Stell)
wrote:
>On Wed, 25 Aug 1999 19:32:32 -0700, [EMAIL PROTECTED] (Michael D.
>Crawford) wrote:
>
>Mike,
>
>From past experiences, I understand it to work as follows:
>
>The export regulations preclude "U.S. rnvolvement" in crypto work
>outside the U.S., unless you are licensed to do so. This applies to
>U.S. citizens and, with some caveats, to corporations.
>
>>Speak Freely includes encryption, so if I port that while I'm in the US
>>I can't contribute my changes back to the original source archives,
>>which are in Switzerland.
>
>Correct. That would be an exportation.
>
>>But I may be moving to Canada in a few months (I'm marrying a Canadian
>>woman). Once I'm in Canada, as long as I create my port of the crypto
>>software while I'm in Canada (so I never bring the crypto Speak Freely
>>into the US, and don't take it back out again), can I export the crypto
>>back to Switzerland without violating US laws?
>
>Unless you give up your U.S. citizenship, doing so would be "U.S.
>envolvement" and would be covered under the export regulations. Living
>in Canada or marrying a Canadian would make zero difference.
If you write the crypto out of the US then you are not exporting it.
How do you think the companies that moved to New Zealand
do there work. But in my case I talk in my sleep so my mexican
wife can write the crypto outside the US. Also how to the phony
AES routines written by MR BS get exported out of the country
is "AES" stuff so weak that it can be experted.
>
>BTW, a U.S. company may be licensed to participate in crypto work
>outside the U.S., only if there is no paarticipation on the part of
>people in the U.S. or U.S. citizens, whereever they reside. The two
>countries I know of such arrangements with were Austrailia and Israel.
>Canada may be in a better position than even these allies.
>
>>I expect to travel to the US frequently on business and it would be a
>>drag to get arrested for some free software work I do while in Canada.
>
>You would be running that risk.
>
>>Canada itself has some export controls, but according to the Crypto Law
>
>Canada is more lax than the U.S., both in its regulations and in their
>application. However, you would would be bound by the stricter U.S.
>regulations and application, unless and until you relinquish your
>citizenship.
>
>doug
>
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NEW THREAD on compression
Date: Fri, 27 Aug 1999 01:38:20 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>SCOTT19U.ZIP_GUY wrote:
>>
>> Don't add anything else yet. I agree one extra symbol is small.
>> I agree the scheme will allow any file to be compresed uncompressed
>> and will compress back again to the original file. But it is not "one to
> one".
>> To be "one to one" and useful as a first pass before encryption it should
> have
>> in my view the property that. If any A compresses to a file B then
>> uncompressing B should get A back (yours meets this part as do most
>> methods). The next part is harder to meet and that is. Any file C when
>> uncompressed to a file D and then when D is compressed you get file
>> C back (your scheme does not meet this). The counter example is
>> to pretend that the file made of only two bytes 00000000 00000000
>> is a compressed file. How would you uncompress this file with your
>> method. SHOW ME use any tree you want.
>> Know you may ask how such a file gets to be even a candidate for
>> uncompression. This is how. You send a message to your friend. First
>> you compress the message then you encrypt it. Your friend gets the
>> message decrypts it and then decompress that result to get original
>> message. Your enemy also intercpets the encrypted message during
>> the transmition. When it guess a ( worng key) lets pretend he gets
>> in the front of the file 00000000 00000000 .... know he tries to decompress
>> it. He can't becasue this file is not possibly a valid compressed file under
>> your scheme so the enemy is imediately given information as to why his
>> guess of the key is wrong. This may lead to a greater reduction than even
>> the blind testing of keys, THe attacker may even have the math smarts to
>> eliminate who classes of keys based on the fact they would lead to unreal
>> compressed files. It would be far safer for you if every file that an
> attacker
>> got with a wrong key was a real compressed file. That why the attacker has
>> to uncompress the file and then decide by exaiming the next output phase as
>> to weather or not the file had meaning. This is more than a few extra steps.
>> If he gets an impossible file he KNOWS he has the wrong key. IF he gets
>> somthing strange he does not know right a way that it is wrong. He has to
>> rule out other languages oher types of files or even the posssiblity that
>> these are special files such as just a binary of your secret keys that your
>> friend needed to decrypt some stuff that he needs for some other program.
>> The point is if every file that the attacker can get with a false key should
>> send the attacker farther down the wrong trail. Don't give him the data to
>> know that a path is false. Make the bastards work
>>
>> that he is on a fasle trail.
>
>I think that I correctly understand (since the more recent exchange
>of posts) your 'one to one' property and also that the purpose of
>your deletion of a sequence of 1's on compression (with the analog
>of addition of 1's on decompression) is not for saving one byte but
>to enable the finding of a valid Huffman code, in case at the end of
>the decompression process the buffer is not empty (because the
>'compressed' file has been obtained by the analyst through decryption
>with a wrong key). But, if you examine closely, you'll see that
>a similar feature is provided yb me for such cases. I use 0's
>instead of 1's. The 'real' (though not very big) difference is that
>I have tried to avoid the type of rules for handling certain special
>cases at the end of processing that you have employed as decribed
>in a previous post of yours.
>
>Through our discussion I have modified a little bit my convention (3),
>it now reads:
>
>(3) After (2) is done, any number of trailing bytes that contain
> contain all 0's may be deleted or added according to user's
> choice or else randomly decided upon by the program.
>
>That this convention successfully deals with the buffer problem
>mentioned above should be clear. Now let's consider your file C
>problem. As said in my previous post, file C with two bytes of 0's
>decompresses to an empty file, which we name D. On compressing D,
>the Huffman scheme of course produces nothing. But (3) says one
>can add to the output any number of bytes. A particular case is
>then adding 2 bytes, which means we can get back to C (more exactly
>C is one of the possible outcomes of compressing D, my compression
>being 'non-deterministic' due to (3)). Since the analyst can't know
>what "the user's choice" in (3) in any compression run is, he can't
>rule out that this getting back to file C is 'normal',
>i.e. he gets no clue from decompression and again compression in
>the present case. (Let me remark in addition that if file C is the
>result of decryption form a file X, then only a single one of the
>normally huge number of possible keys could produce such an
>extraordinary file consisting of all 0's, so that it isn't very
>crucial after all, even if he were able to ascertain that that one
>key is not valid.)
>
>M. K. Shen
Yes if you use the "random added feature" yes you can do I think
what you are saying. But to me we pretend the enemy knows all but
the key and the message That means the enemy knows what you did for random
numbers. Or you have to consider the means of adding in a random
feature as part of the encryption. But these are my views if you want to
call the random feature part of compression fine.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Wrapped PCBC mode
Date: Fri, 27 Aug 1999 02:40:56 GMT
In article <[EMAIL PROTECTED]>, Coms 1003
<[EMAIL PROTECTED]> wrote:
>With all this discussion on the "w-PCBC" mode, could someone post (or post
>a reference to) exactly what this is?
>
It is the mode I use in my encryption programs. Just look at scott19u.zip it
is in there. Also if you look at old posts I have descriped it a lot in this
news group. Maybe David Hamiltion could help you. Put it is like PCBC
except you don't have to use XOR for the operations you can use others
I replace second wiht addition.
Cn = E{ Cn-1 xor Pn xor Pn+1} let Po be the first block C-1 is the last
block in file.and may not necessarily mesh with any Pn due to file size.
also the file thought of as in a loop. Also the C's are offset to the P's
in scott19u the block size is 19 bits the offset is 9. You can look at
the code to see. One minor complication. To encryt you go down the file
in forward diction and "wrap" around to the top. To decrypt unlike most
methods you have to go in reverse direction from botton to top and
wrap around to bottom. The advantage of this over noraml chainning
is tremendous. One it can't be decoded by going down the file. The
file has to be processed in reverse direction ( this is not ture in PCBC)
and I doubt if the NSA likes or even bothers to consider this in decryption.
Also onther plus is the "all ot nothing feature" If you change only one bit
in the output file. And attempt to decrypt you get totally garbage. If you
do this with any of the AES mehtods using standard blessed chaining
like CBC or your 3 letter one of choice on a small portion of file in error.
Also with an apporved method an attacker only needs to look at a portion
of the file to test a break. With my method you need to look at the whole
file not a small fragment like with any of the AES methods using the
weak chaining method od choice.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Where to find
Date: Fri, 27 Aug 1999 02:22:29 GMT
In article <7q3vkc$q9k$[EMAIL PROTECTED]>, "Richard A. DeCamp"
<[EMAIL PROTECTED]> wrote:
>Forrest Johnson <[EMAIL PROTECTED]> wrote in message
>news:8NKw3.1$[EMAIL PROTECTED]...
>> In article <7prr6a$1m7g$[EMAIL PROTECTED]> SCOTT19U.ZIP_GUY,
>> [EMAIL PROTECTED] writes:
>> > It may be arrogance but I am sure many Navy Pilots owe me unknownly
>> >for fixing many potentail dangerous errors introduced by the kind of
>> >programers that some one of your limited back ground would respect.
>> >
>
><Mr. Johnson's list of questions as to dscott's actual credentials and
>qualifications in programming for Navy weapons systems>
>
>> Sorry about all the questions -- I'm just curious about these changes you
>> made to these weapons systems and how you got them done.
>
>Per your original reply, d, way to avoid the question. I have another one
>for you to ignore. You mentioned previously that you had a patent. Which
>one? A patent number will suffice. A brief description of the invention
>would also be appreciated, although the number alone will suffice. A small
>hint: any form of the phrase "go look it up" without the number or
>description will be considered unhelpful, for reasons that will become clear
>if you enter "david scott" into the IBM patent server search. If you've
>forgotten the number, it doesn't strike me as terribly difficult to check
>your own records and refresh your memory. You did keep a copy of the
>patent, didn't you? That is, if you actually have one...
My spelling not the greatest but it was for a "derotation plate" I doubt if
I have the paper work I don't save anything. I have never even seen my porgram
scott19u in print. Only on the crt screen.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (Aidan Skinner)
Subject: Re: cryptographic DLL
Date: 26 Aug 1999 23:55:07 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 24 Aug 1999 22:15:18 GMT, Greg <[EMAIL PROTECTED]> wrote:
>I don't see how that can really be enforceable from a US point of
>view. Canada can take any position it wants to no matter how rabid the
>Commerce department gets.
Well, America seems to like to force it's laws upon other people,
especially litigation, cf Helmes-Burton.
- Aidan
--
Gimme money, gimme sex, gimme unix and root access.
http://www.skinner.demon.co.uk/aidan/
------------------------------
Date: Thu, 26 Aug 1999 14:31:27 +0200 (CEST)
From: Anonymous <[EMAIL PROTECTED]>
Subject: What the hell good is a session key!
References:<[EMAIL PROTECTED]>
Yes, that is my point, J Savard gets an A. But would the
master-key/session-key protocol be any security advantage over just a random
IV or random salt??
(when using only conventional encryption in CBC *not* CFB mode)
Regards,
George Gordon
Anonymous (George Gordon) wrote:
: Using only conventional encryption (like PGP if you check the conventional
: box) if an attacker can brute-force your session key in a month, then they
: can certainly subsequently brute-force your master key, if it is the same
: length.
JSavard responded:
>Ah, this must be a new mode in recent versions of >PGP.
>The advantage of this kind of session key for security >is: if they
_cannot_ quite brute-force the length of key >used, _other_ techniques, such
as differential >cryptanalysis, which requires a large amount of >plaintext,
are hampered because each session key is >used only for a short message.
>Until a session key is found, since the master key is >directly used only
to encrypt session keys, which are >random, a brute-force attack against the
master key >cannot begin.
>So your main point *is* correct: the use of a master >key and session key
will not help you if the cipher you >are using is so weak that a
>brute-force attack against it is possible.
------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Subject: Re: 2 person data exchange - best method?
Date: Thu, 26 Aug 1999 14:38:50 +0200
Shaun Wilde wrote:
>
> Hi all,
>
> Please forgive this newbie but I have a query as regards crypto algorithms.
>
> If I have 2 people who wish to exchange information what is the best way to
> do so assuming that I have no trustee (holder of public keys) and such that
> I can defeat the Man-In-The-Middle attack.
>
> Can I get away with message splitting (interlock-protocol?)? Is there any
> problems with this? Is there anything better?
If there are just two people involved, I'd just use some secondary form
of communication to verify the public keys, i.e. send the signature by
fax and/or read it over the phone.
For a really paranoid setup, you would of course start with a
face-to-face meeting where you exchange all needed key material.
Terje
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
From: Wil Baden <[EMAIL PROTECTED]>
Subject: Re: How does RC4 work ?
Date: 27 Aug 1999 03:29:07 GMT
Are all who told how RC4 allegedly worked or gave
code "criminals"?
(
--
Wil Baden Costa Mesa, California [EMAIL PROTECTED]
)
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: RSA and Microcontroller
Date: 27 Aug 1999 03:00:07 GMT
In article <[EMAIL PROTECTED]>,
Ryan Phillips <[EMAIL PROTECTED]> wrote:
>This is just a research project (for now), but is it possible to put RSA
>Encryption and Decryption into an Intel compatible 8031 or 8051
>microcontroller?
Encryption (low exponent) wouldn't be too bad. Decryption would be
too slow to use in any interactive application. There are variants of
the 8031/8051 (mostly intended for smart card use) with public key
accelerators on the chip, that make RSA and similar algorithms
practical on them. There are other 8031/8051 variants with
signal processing extensions that could also be used for RSA.
Contact your favorite chip vendors for more info.
I believe RSADSI has a software implementation for the 8051, but it
would necessarily have the above speed constraints, and it's probably
pretty expensive.
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: One-time pad encryption.
Date: Thu, 26 Aug 1999 22:38:32 -0400
Dear Trevor,
Thanks for the post. I think I know what you mean. The problem this
time is definitely mine.
First, sorry if my post confused people. I just would like to make it
clear what I was saying.
The necessary condition for Perfect Secrecy holds. Anything short
of that is not perfect.
I used the words 'near perfect' and it is my opinion that one-wayness
may be possible.
Graceful degradation is one way of using a piece of secret. It is viable.
I am for it (in cases where this appears to be the most attractive). My
only concern is that the rate and degree of degradation may not be
precisely established. Only my suspect here.
I need to put this aside for a bit and then come back. That way I may
better see it. Anyway, I was referring to one-wayness. In other words,
given a piece of secret 'of size 2^n', assuming that direct access to this
secret is not a given, then the breaking of the scheme is of complexity
O(2^(n-delta)) for some small delta (under the reasonable assumption
that the attacker has (some) corresponding plaintext). And delta does
not (hopefully) increase, i.e. no degradation. By the way, I am not as
confident as I was when posting earlier. Still I do not see any obvious
problems yet. If I do see, I will update.
Can not forget to point out that most of the nuisance with OTP is still
with this one. But the piece of secret mentioned above is designed to
be used unlimited number of times.
I apologize once more if I confused people. I should gain more
confidence before posting. Sorry.
Thanks again, Trevor, for the discussion.
--- (My Signature)
Trevor Jackson, III wrote in message <[EMAIL PROTECTED]>...
>rosi wrote:
>
>> Guess, it just would not leave us. :)
>>
>> While hanging off the other thread (thinking what the heaven I meant),
>> old dust in my head got stirred up. More precisely the 'secret expansion'
>> part.
>>
>> I believe (though have to go back and think carefully, lest there are
holes)
>> MTP is near possible and quite 'practical'. To be not so pompous, there
>> may not be perfectness but, IMO, near perfectness (will give a slightly
>> better description). However, one-wayness should be guaranteed.
>>
>> Like OTP, there is no magic. There ARE assumptions.
>> 1. The bits generated should be 'truly' random.
>> 2. The bandwidth is still needed for the transfer of the pad(s)
>> 3. (As MTP) an initial secret needs to be securely established and,
>> just as the pad of OTP, it needs to be secured. (But no worry
>> when openly distribute its multi-time used version, yet of course
>> authentication is needed, but hopefully no conjecture involved)
>>
>> This applies the notions of Perfect Secrecy and (non-compressing) one-
>> way functions.
>>
>> Near perfectness is in the following _sense_: a pad is not as long as the
>> message to be protected but, e.g. is alway short of one bit which will be
>> made up by the parity of the pad (or part of the pad) for an encryption
>> instance.
>>
>> I can find myself wrong. If others already have similar thoughts, please
>> point out or declare. Likely that is the case.
>>
>> --- (My Signature)
>
>I've speculated on ways to gracefully degrade an OTP into an MTP. The core
idea
>is to shroud the actual OTP by a bit selector.
>
>Consider the "truly" random keypad as a set of individual bits -- an
entropy
>pool. For each message to be encrypted uniformly select bits from the pool
>until you have as many key bits as there are bits in the message. These
bits
>are the message key. Use the typical Cipher = Plain XOR Key encryption
process.
>
>If the receiver has a copy (out of band) of the pool, and uses the same bit
>selection algorithm (PRNG) decryption is the same as encryption.
>
>In this approach the pad is not the key. The key is constructed from the
pad.
>The entropy of the pad is gradually reused, but the structure/sequence of
the
>pad is not used. Each message probably shares key bits with every other
>message, so the system of messages is not perfect security.
>
>This approach eliminates one of the troublesome aspects of OTP systems
which is
>message key size == messatge text size. In fact one could use a pool
smaller
>than the smallest message.
>
>An interesting aspect of this approach is that there are two parts of the
system
>to hide. The entropy pool has to be treated just like an OTP keypad. The
PRNG
>seed has to be treated just like the message key of a symmetric cipher. So
it
>would be possible to produce "shrouded PGP" by using the symmetric message
key
>as a seed for an entropy pool bit selector PRNG.
>
>Note carefully that this kind of system is NOT a One-Time Pad. The key
resuse
>starts within the very first message! In theory, the first two bits are
>related. The term I've been using for this is "degraded OTP".
>
>Mathematically, the degree is degradation is log (sum message sizes) /
>log(entropy pool size). This ratio defines the degree of theoretical
>compromise. I suspect, but have not proven, that a degradation ratio < 1
is
>equivalent to a true OTP.
>
>
>---- New topic: Shrouded PRNG
>
>Rather than consider the PRNG bit selector as the shroud for the OTP
keypad, the
>entropy pool can be considered as shroud for the PRNG. This makes it
possible
>to scalably add entropy (non-determinism) to a deterministic algorithm.
>
>
>
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Can americans export crypto when in another country?
Date: Thu, 26 Aug 1999 21:51:26 -0600
In article <7q4lqa$35cq$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> Since you claim I am covered by US law do I have to drive
> on the right side of road when overseas. No you can't export it
> if you wrote it over there. Same if you go to Holland and smoke
> a joint. Its ok in Holland so who cares what it is in the US.
> Alsoi many people have dual citizen ship. What rules would they
> follow.
>
Supposing that you are in another country, the other country is not duty
bound to see that you follow US laws, and might be upset if agents of our
government were acting there in any than a treaty allowed official
capacity. Can you say, "Spy," as in, "No diplomatic immunity."
Switch this thing around and presume that a woman of one of certain Arab
countries was not wearing her veil while in this country. Just how much
cooperation do you think the US government would give and how far do you
think that the government would allow foreign agents to interfere with the
conduct of such a person while here?
Something here does not make good sense. I'm not trying to say that we do
not need to safeguard some of our technologies, but, it seems that in a
country were freedom of movement and expression are constitutional
virtues, that we are unwilling to share these things mutually, even with
sympathetic countries, while we seem to casually allow so many things to
go to our enemies through high channels.
--
I'd rather have prime rib than prime numbers.
Moore's Law always yields to Les's Rule.
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: Thu, 26 Aug 1999 22:58:43 -0400
Memory is not just memory for practical purposes, am I right?
Still the basics. We've got to put stuff in memory. I doubt if we could
fill up '2^n memory' in less time in the general case, or in particular
cases that interest us. I favor the view that complexity is in that of the
description. If the description does not 'allow' parallelism or speed
up (in the conventional manner), I doubt if we can do any more.
Trade-off up to a point, IMO. Still the same thing.
--- (My Signature)
David Wagner wrote in message
<7pu9d0$652$[EMAIL PROTECTED]>...
>In article <7pt6em$8lg$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>> By the way, time and memory resources are not completely
>> independent. If random access memory is required then there is a
>> time cost for addressing a large memory, i.e. on any given
>> technology the bigger the memory the slower the access. Fundamental
>> physics play a role here: the larger the memory the more space will
>> it fill and therefore more time will be needed for a signal to
>> cover the distance between memory and processor. So, a better cost
>> function for computer resources should be Cost = Time * Memory^K
>> with K>1.
>
>If you arrange the memory as a binary tree -- or as a butterfly -- then
>the time cost to access memory goes as O(log Memory), which suggests that
>the right formula is Cost = Time * Memory * log Memory.
------------------------------
** 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
******************************
