Cryptography-Digest Digest #112, Volume #10 Thu, 26 Aug 99 07:13:03 EDT
Contents:
Re: Where to find (Forrest Johnson)
Re: Can americans export crypto when in another country? (David A Molnar)
Re: Fermat theorem on primes? (Jerry Coffin)
Re: NEW THREAD on compression (Mok-Kong Shen)
Re: cryptographic DLL (fungus)
Re: cryptographic DLL (Tom St Denis)
RE: MUM Revisited (Gary)
RE: MUM Revisited (Gary)
Searching for Source of PGPPhone or Document how it works (Hartmut Schroeder)
----------------------------------------------------------------------------
Subject: Re: Where to find
From: Forrest Johnson <[EMAIL PROTECTED]>
Date: Thu, 26 Aug 1999 03:30:53 GMT
In article <7q0ug3$2hd4$[EMAIL PROTECTED]> SCOTT19U.ZIP_GUY,
[EMAIL PROTECTED] writes:
> Well look it up I wrote several papers in the 70's on quaterion
>apporximations. These are Navy Papers and people at Ratheon
>New York took copyes of these unclassified reports so can look
>them up.
What were the titles of the papers? Were they published in any sort of
journal? You mentioned they were "Navy Papers". What were the document
control numbers? (If they aren't under any sort of document control,
there's little hope of finding them. Ditto for the prospect of finding
anything that someone might have carted back to Raytheon 25 years ago.)
What does writing papers on quaternion approximations have to do with
patching code in fielded weapons systems?
>As far as Y2K I did try to come out of retirement and
>help fix the problems ( we use to complain to management about
>it. But that is a waste of time). I taught UNIVAC assembly at CHINA
>LAKE for a while. I was on call 24 hours aday in case the UNIVAC
>crashed. I use to fix working programs the navy relied on that they
>long ago lost the source code. The use of the product FLIT. I felt
>that since my boss suggested I go back and help with Y2K that I
>might as well look into it. I give my resume to the CSC office
>in RIDGECREST. But I never heard back from them.
None of this has to do with changing code in fielded weapons systems.
>But basically if it FLEW or was related to FLYING I worked on it.
Give me some particulars. Which specific aircraft and which specific
systems on those aircraft did you make code changes to?
> One day bored
>so even applied for a patent on some hardware stuff for the
>Navy surely you can look that up.
No, I can't look up a patent application. I could look up a *patent* if
one had been granted and if I had some idea of the title or subject
matter of the patent, but again you didn't give me any particulars.
There are only 79 patents registered to David Scott from 1976 to 1979, so
it won't be hard to find yours if you give some detail.
>(reminiscences not applicable to the question snipped)<
I enjoy your war stories and such, Mr. Scott; they just don't give me the
information I need. Could you give me some details on the when, where,
what, and how you applied your code changes to fielded weapons systems?
Thank you.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Can americans export crypto when in another country?
Date: 26 Aug 1999 02:51:06 GMT
Crossposted to talk.politics.crypto in hopes of reaching a wider
readership. My understanding has always been that U.S. citizens writing
crypto are not allowed to "export" it, no matter where they write it. I
would love for this not to be the case, but have no current source one way
or the other.
Michael D. Crawford <[EMAIL PROTECTED]> wrote:
> Hi,
> I'm an American citizen, presently living in the US, and I've been
> wanting for a while to port Speak Freely to the Be operating system.
> See http://www.speakfreely.org and http://www.be.com
> 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.
> 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?
> 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.
> Canada itself has some export controls, but according to the Crypto Law
> Survey at:
> http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm
> crypto is not export controlled if the software is in the public domain,
> which is the case for the original speak freely and will be true for my
> changes.
> Mike
> --
> Michael D. Crawford
> GoingWare - Expert Software Development and Consulting
> http://www.goingware.com
> [EMAIL PROTECTED]
> Tilting at Windmills for a Better Tomorrow.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Fermat theorem on primes?
Date: Wed, 25 Aug 1999 21:44:13 -0600
In article <7q27u6$d57$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> <snip>
>
> > Fermat's little theorem says that if p is a prime and does not
> > divide a, then a^(p-1) = 1 mod p. Instead of doing copying from a
> > book, I suggest that you look into any introductory text book on
> > number theory for its proof as well as for its generalization
> > due to Euler.
> >
> > M. K. Shen
>
> Hi there mr. expert-wannabe,
and hello to you, though I'm not sure what you want to be.
> I suggest you also take a look in that text book of yours for that "proof".
> I you think its neccesary to flame, than don't make such a fool out of
> yourself.
> a=2,p=11*31=341 "OOOPS, (blush) did I say "proof"? But, but, you must
> believe me! I know very much a bout math, I even quoted Fermat, which is
> cool, and Euler too!
Please read what M.K. Shen said. He pointed out that Fermat's little
theory makes a statement about what will happen if p is prime. This
statement is absolutely true. Fermat's little theorem, as well as
M.K. Shen's statement about it above, do NOT say anything at all about
what happens if p is not a prime. In particular, it's been well known
for many years that you can get the same type of result for some non-
prime values of p.
IOW, if a number fails this test, the number is definitely NOT prime.
If a number passes the test, it may or may not be prime.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: NEW THREAD on compression
Date: Thu, 26 Aug 1999 10:01:49 +0200
SCOTT19U.ZIP_GUY wrote:
>
> <[EMAIL PROTECTED]> wrote:
> >As described in your post, a number of checks are done at the
> >end of processing to take care of the different possible special
> >cases such that the scheme can work without trouble. I think that
> >the following scheme is simpler (hence somewhat easier to program)
> >and yet achieves all the purposes of yours. It has the following
> >conventions:
> >
> >(1) No input symbol has a Huffman code of all zeros (any number).
> >
> >(2) If the last output bit is not at byte boundary, add 0's
> > till byte boundary.
> >
> >(3) After (2) is done, delete all trailing bytes (any number) that
> > contain all 0's.
>
> FIrst of all it would not be "one to one". I am not sure how many
> cases don't map back and forth. For example. I claim that
> it is a neat fact if
> 1) any file A when compressed to a B when decompressed A should come
> back. And any file C when decompressed to D when compressed comes back to C
> as a quick example what happens to a
> file C that is defined as 00000000 00000000
> what is this after it is decompressed and what could possibly compress to this
> file.
I am not sure that I understand you. Is C an input (not compressed)
file? In that case we have two (8-bit) ASCII characters that are
the same and that has a certain Huffman code and the file is encoded
just as any other file. In the other case where C is a compressed
file, the answer is that such a file cannot exist because of my
convention (3). It remains to discuss how the program behaves if
it is nevertheless asked to decompress such a file. From (1) and
(2) it knows that a sequence of all 0's (and nothing following that)
means padding. So in this particular example it outputs nothing
(the ouput file is empty). No error message is issued, since there
are no hanging bits in the buffer that remain to be decoded. Hence
there is no 'abnormality' which you fear could be of use to the
analyst. If you still fell that this could consitute certain clue to
the analyst, (3) can be changed to be an 'optional' rule, i.e.
trailing bytes of all 0's may be omitted if the user desires it
(or let the program make a random decision of doing that).
> 2) In my method you cover all 256 symbols each at start has 8 bit paths. To
> use your method the all zeros symbol which is never used has to occupy the
> longest path. So at start 255 symbols have 8 bit paths while the other 1 would
> have a 9 bit path.
There is not much difference in efficiency. One constructs the
Huffman tree this way: Invent an extra symbol (257-th) and give it
the lowest frequency and keep it always on the left side (I assign 0
to left) of the tree. So it gets a code of all 0's assigned. This
extra symbol is never used, of course.
I have considered the compression, decompression and compression
back processes. There can be no case that could yield anything wrong.
Note that because of (3), if on decompression the buffer at the
end of the file is not empty, the program appends as many 0's to
the buffer as needed to form a valid Huffman code.
If you have counter-examples, please give (a small) one so that
we can discuss that with paper and pencil alone.
M. K. Shen
>
> However I think what you have is what most people would do for a small
> huffman tree. But for one that represents the full 256 character set most
> would make a minor change. Since it is easy to guarnatee that a huffman tree
> of 256 leaves will always have a path of 8 or mores zeros. Use the fill zeros
> which will always be at most 7 in the last byte if needed and there can be
> no confusion as to the end of the compressed file. This is what I did when
> I started playing with the Huffman compression since I did not like the extra
> bytes that the public domain code had.
> But even this bothered me since I noticed that when one tried to decompress
> and recompress back you don't always get the same file. Therefore it must
> be a weakness and one should be able to do more. That is when I came up
> with current scheme. Like I said I am not done yet and your discussions have
> made be look deeper. I wish I had a printer. But I have redone the logic of
> the compression so that the new case fits. I had slowly made changes to the
> compression version and it had become a monster of logic conditions so I
> have re thought them. But even then this is first cut. I don't like the fact I
> am currently useing the all zero case as the longest path. I will make a new
> version that changes the bit 0/1 bit assignments as the tree is built so that
> instead of the all zero case it will use instead as fill the current longest
> path to a leaf. And instead of the all ones for cutoff it will use the current
> shortest path to leaf from the internal node that it stopped at. This should
> be exportable since it will be pure compression and not encryption but any
> one that looks at text compressed by this might be under the illusion that
> it looks like encryption. When in fact it is meant to be used as a first pass
> before encryption takes place.
> However if someone took the starting 256 leaf table and did not use them
> in normal order. There would be as many arangements as in a 8 bit single
> cycle table. But not sure how to calulate that:)
> If one then revesrsed the file end for end and used a second huffman
> compression again with random starting leaf values. This could be thought
> of as encryption but I am not sure. Since I will only use a normal nokeyed
> starting order for normal compression at least for any code I write on the
> US side of the Mexican border.
>
> >http://home.t-online.de/home/mok-kong.shen (new addr.)
>
> 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: fungus <[EMAIL PROTECTED]>
Subject: Re: cryptographic DLL
Date: Thu, 26 Aug 1999 10:48:03 +0200
Greg wrote:
>
> This gets interesting. He lives in Canada and is breaking US laws!
> Cool...
>
What about me?
I live in Spain but my web page is hosted in the USA somewhere
(Florida I think). If somebody downloads crypto from my website
then who's guilty of the federal offence?
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: cryptographic DLL
Date: Tue, 24 Aug 1999 22:53:15 GMT
> For the inquiring minds I am now a 'clueless-hacker' interested in
> breaking the law or messing things up. I am quite lawful, xcept when
> it comes to 'silly' laws made by crypto-clueless people. EAR is like
> saying 'no car for you, you might hit someone' or 'no gun for you, you
> might shoot someone' etc...
eegad... change 'now' to 'not' and that's what I meant to say...
Geez... my head is not on straight...
Sorry bout that.
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Gary <[EMAIL PROTECTED]>
Subject: RE: MUM Revisited
Date: Thu, 26 Aug 1999 06:20:49 -0400
Thanks Ian for taking the time to look at the function. :)
Are there hashes (preferably computationaly fast) that use 2 inputs, where
knowledge of one input and the product is no help in discovering the other
input?
Futhermore is it impossible for such a hash to be associative?
Thanks
Gary
>===== Original Message From [EMAIL PROTECTED] (Ian Goldberg) =====
>In article <[EMAIL PROTECTED]>, Gary <[EMAIL PROTECTED]> wrote:
>>This function (defined by the following extract from C source):
>>
>>#define RotateLeft(A) (A=((A<<1)|(A>>31)))
>>#define ShiftRight(A) (A>>=1)
>>unsigned long f(unsigned long a,unsigned long b)
>>{
>> unsigned long s,i;
>> s=0;
>> for(i=0;i<32;i++)
>> {
>> if(a&1) s^=b;
>> RotateLeft(b);
>> ShiftRight(a);
>> }
>> return s;
>>}
>>
>>My analysis has shown that this function is both associative and
>>commutative.
>>This analysis also leads me to conjecture an element has an inverse if and
>>only if the number of bits set is odd.
>>1 is the identity.
>
>All three of the above statements are correct, and here's why:
>
>The bits in your unsigned longs represent the coefficients of a polynomial
>(of degree at most 31) over Z/2Z. Your function f is then just polynomial
>multiplication, mod (x^32+1). This explains the associativity and
>commutativity, and that 1 is the identity.
>
>Also, note that (x^32+1) == (x+1)^32, so A (thought of as the above
>polynomial) is invertible iff it is not divisible by (x+1); i.e. A(1) != 0;
>i.e. there are not an even number of non-zero coefficients; i.e. the number
>of set bits of A (thought of as the unsigned long) is odd.
>
>>And while I can't find a solution for B given the pair f(A,B) and A (where A
>>has no inverse), somebody else probably knows how to.
>
>Yes, given the above, it's fairly straightforward to recover B from f(A,B)
>and A, for any A.
>
> - Ian
============================================================
Get your FREE web-based e-mail and newsgroup access at:
http://MailAndNews.com and http://MailAndNews.co.uk
Create a new mailbox, or access your existing IMAP4 or
POP3 mailbox from anywhere with just a web browser.
============================================================
------------------------------
From: Gary <[EMAIL PROTECTED]>
Subject: RE: MUM Revisited
Date: Thu, 26 Aug 1999 06:35:21 -0400
Ooops should have stated that exponentation can't be used.
>===== Original Message From Gary <[EMAIL PROTECTED]> =====
>Thanks Ian for taking the time to look at the function. :)
>
>Are there hashes (preferably computationaly fast) that use 2 inputs, where
>knowledge of one input and the product is no help in discovering the other
>input?
>
>Futhermore is it impossible for such a hash to be associative?
>
>Thanks
>Gary
>
>>===== Original Message From [EMAIL PROTECTED] (Ian Goldberg) =====
>>In article <[EMAIL PROTECTED]>, Gary <[EMAIL PROTECTED]> wrote:
>>>This function (defined by the following extract from C source):
>>>
>>>#define RotateLeft(A) (A=((A<<1)|(A>>31)))
>>>#define ShiftRight(A) (A>>=1)
>>>unsigned long f(unsigned long a,unsigned long b)
>>>{
>>> unsigned long s,i;
>>> s=0;
>>> for(i=0;i<32;i++)
>>> {
>>> if(a&1) s^=b;
>>> RotateLeft(b);
>>> ShiftRight(a);
>>> }
>>> return s;
>>>}
>>>
>>>My analysis has shown that this function is both associative and
>>>commutative.
>>>This analysis also leads me to conjecture an element has an inverse if and
>>>only if the number of bits set is odd.
>>>1 is the identity.
>>
>>All three of the above statements are correct, and here's why:
>>
>>The bits in your unsigned longs represent the coefficients of a polynomial
>>(of degree at most 31) over Z/2Z. Your function f is then just polynomial
>>multiplication, mod (x^32+1). This explains the associativity and
>>commutativity, and that 1 is the identity.
>>
>>Also, note that (x^32+1) == (x+1)^32, so A (thought of as the above
>>polynomial) is invertible iff it is not divisible by (x+1); i.e. A(1) != 0;
>>i.e. there are not an even number of non-zero coefficients; i.e. the number
>>of set bits of A (thought of as the unsigned long) is odd.
>>
>>>And while I can't find a solution for B given the pair f(A,B) and A (where
A
>>>has no inverse), somebody else probably knows how to.
>>
>>Yes, given the above, it's fairly straightforward to recover B from f(A,B)
>>and A, for any A.
>>
>> - Ian
>
>------------------------------------------------------------
> Get your FREE web-based e-mail and newsgroup access at:
> http://MailAndNews.com and http://MailAndNews.co.uk
>
> Create a new mailbox, or access your existing IMAP4 or
> POP3 mailbox from anywhere with just a web browser.
>------------------------------------------------------------
============================================================
Get your FREE web-based e-mail and newsgroup access at:
http://MailAndNews.com and http://MailAndNews.co.uk
Create a new mailbox, or access your existing IMAP4 or
POP3 mailbox from anywhere with just a web browser.
============================================================
------------------------------
From: [EMAIL PROTECTED] (Hartmut Schroeder)
Subject: Searching for Source of PGPPhone or Document how it works
Date: Thu, 26 Aug 1999 10:35:50 GMT
Hi,
while working on an standalone Cryptophone the Idea comes in mind makeing
it compatible with existing Solutions (even PC-Based).
The only worth of implementing Solution seem to be PGPPhone but it seems
that develoment has been stopped?!?
It also seem that there's no Source avail. Is that true?
I don't require the Source but a Document how the communication Protocol works
will tell me if and how we can implement this.
Has anybody seen such a Document and can point me to it?
Regards H.Schroeder
Hartmut Schroeder MMS Communication AG
mailto:[EMAIL PROTECTED] Eiffestrasse 598
http://www.mms.de/~hacko 20537 Hamburg, Germany
Phone: +49 40 211105-40 Fax: +49 40 210 32 210
UTM 32U0569835 5934083 WGS84
------------------------------
** 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
******************************
