Cryptography-Digest Digest #111, Volume #10 Wed, 25 Aug 99 23:13:06 EDT
Contents:
OT -- but you ain't gonna believe this ("Rick Braddam")
Re: NEW THREAD on compression (SCOTT19U.ZIP_GUY)
Re: passphrases (Keith A Monahan)
Re: One-time pad encryption. ("rosi")
Re: cryptographic DLL (Greg)
Re: OT -- but you ain't gonna believe this ("Thijs vd Berg")
Re: Fermat theorem on primes? ("Thijs vd Berg")
Can americans export crypto when in another country? (Michael D. Crawford)
Re: OT -- but you ain't gonna believe this (Paul Rubin)
Re: Fermat theorem on primes? (David A Molnar)
----------------------------------------------------------------------------
From: "Rick Braddam" <[EMAIL PROTECTED]>
Subject: OT -- but you ain't gonna believe this
Date: Wed, 25 Aug 1999 17:35:41 -0500
I just recieved this in e-mail today. They must be really hurting for "experts". Based
on what little I know about my own
shortcomings as a cryptographic programmer or user, I wouldn't recommend the following:
=Dear Rick Braddam,
=I've been browsing the sci.crypt website and discovered that you are quite
knowledgeable about =Security and Encryption. I want to
invite you to join us at
= http://www.expertcentral.com/specialinvitation. ExpertCentral.com is a site where
users can =quickly find the right person to
answer their questions on many different topics.
=Because of your demonstrated knowledge, I'd like to start you off as a highly-rated
advisor in our =Computers & Internet category
(as well as any additional categories where you think you can help =people).
Membership is FREE, incidentally.
=By joining us, you'll receive honor, recognition and success. (We like to state the
risks in advance.) =You'll also get the
satisfaction of helping people, while potentially earning money by charging for
=advice -- and, all the while, enhancing your
reputation as an expert in your field.
=What's more, if you're one of the first to join, you'll have an opportunity to build
a ratings lead (like =those enviable first
sellers on eBay).
=You'll appreciate that I had to go to some trouble to find you, and we'd like to make
it easier for =other people, so I hope you'll
take the time to visit our site
= (http://www.expertcentral.com/specialinvitation) to learn more.
=Sincerely,
=Geoff Ashman
=Expert Recruiter
=PS
=We found you through painstakingly combing the Internet for high quality experts to
invite to join us. =Once again, membership is
FREE and there are no hidden costs. If you join now you have a =chance to win a Palm V
connected organizer from Palm Computing.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NEW THREAD on compression
Date: Thu, 26 Aug 1999 00:45:52 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[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.
>
>Would you please give your opinion on that?
>
>M. K. Shen
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.
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.
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: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: passphrases
Date: 26 Aug 1999 00:50:53 GMT
Perhaps I'm just paranoid, but considering the number of different ways
someone can get ahold of your passphrase, including the implementation holes
you listed below, I would recommend changing your password frequently.
I would modify how often you change your password based on how secure
you need your data to be. This is to keep any attackers on their toes.
Perhaps an attack on the algorithm could be made where certain amount
of ciphertext using the same key is required.
Who knows? But the bottom line is this : if your data is sensitive enough
to require encryption, then spend the 5 minutes here or there to ensure
its continued security.
I'd rather be safe than sorry.
Keith
[EMAIL PROTECTED] wrote:
: It has been said that it's wise to change your passphrase often to stay
: secure.
: However, consider this:
: Lets assume you pick a very good passphrase that has sufficient entropy
: (i.e. many random characters, numbers, and punct.) that you can easily
: remember. Since this passphrase cant be guessed or brute forced in a
: resonable time, your data will remain secure for a long time.
: But, if there is a hole in your implementation such that the key can be
: recovered (like a key logger, swapfile, slack disk, EMI, etc.), then it
: doesn't matter how often you change your passphrase, you're screwed!!
: Therefore, as long as you have no holes and a very good passphrase, you
: don't have to change it.
: Any opinions?
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: One-time pad encryption.
Date: Wed, 25 Aug 1999 19:48:35 -0400
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)
Tony L. Svanstrom wrote in message
<[EMAIL PROTECTED]>...
>Please explain the weakness of this senario (besides the fact that the
>"key" has to be within reach and that finding "random" characters
>usefull to be used might in field be quite hard):
>
>Agent X and Agent Y wants to send encrypted messages to eachother, they
>pick OTP; which they use like this:
>
>The needed area for the message is this long:
>
>xxxxx
>xxxxx
>xxxxx
>
>That possible number of characters (it might be shorter and then padded,
>but if longer then two messages would have to be sent) is then "hidden"
>by padding it with "randomly" picked characters so that you might get
>something like this (no pattern beyond being able to be read by a human
>is needed):
>
>xxxxx
>12345
>xxxxx
>xxxxx
>67890
>12345
>
>Added to the above is then the next OTP to be used (not for the reply,
>but for the next encrypted message from that agent):
>
>xxxxx
>12345
>xxxxx
>xxxxx
>67890
>12345
>09876
>54321
>09876
>54321
>09876
>54321
>
>That "packet" is then being "encrypted" using the OTP from the last
>message, the OTP is used twice to cover the 2([length of the OTP]) long
>message.
>
>My reasoning is that using the OTP twice shouldn't weaken this based on
>the fact that the second time it's being used it's used on a "text" that
>has been randomly picked and that contains no words or any other
>information that could be compared to the known to be a text part of the
>message (where the known to be text-part has been located by knowing the
>basic structure of this method).
>
>
>Is this the best possible way to implement OTP in a everyday situation
>where you want to send secure messages?
>
>
> /Tony
>--
> /\___/\ Who would you like to read your messages today? /\___/\
> \_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
> --oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
> DSS: 0x9363F1DB, Fp: 6EA2 618F 6D21 91D3 2D82 78A6 647F F247 9363 F1DB
> ---���---���-----------------------------------------------���---���---
> \O/ \O/ �1999 <http://www.svanstrom.com/> \O/ \O/
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: cryptographic DLL
Date: Thu, 26 Aug 1999 01:03:15 GMT
> In fact, it's unclear you'd be breaking Canadian law (the rules about
> "US-source" stuff are *very* hazy), but it's certain you'd be breaking
> US law. US Persons (as defined in the EAR) are not allowed to post
strong
> crypto to the Internet without a licence, period. It doesn't matter
where
> you happen to be when you do it.
I can't buy that. If you go out of the USA with crypto to post it on
the web, you violate the export rules because you took it with you.
But if you go out and write the code, you do not violate the export
rules. (Unless you think the government will begin to consider what is
in your mind a commodity?) In fact, you can go out with the code
written on paper, type it into a PC in another country, and you have
not exported any crypto. This is exactly what PGP Inc does today.
If you post crypto code on an international server with internationally
developed code, there is no export taking place.
I could take every bit of my elliptic curve cryptosystem software save
one file that could sit on about 100 lines, type in the lines while in
flight to Europe or Mexico from a print out, then have a fully
operational nuclear strength cryptosystem ready to post to a web site
when I arrive. I have not exported any regulated software in the
process. And NSA has already declared that the other files are not
regulated by the EAR.
I am actually thinking of doing this, though a lot of preparations
would have to be made, like finding a site in Mexico, that I can easily
and cheaply use. I am just no there yet.
--
Red Dawn- "What makes us better than them?" "We live here!"
Wallace on Brave Heart- "While you stand around and bicker,
I am going to take the fight to the [king's back yard]."
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Thijs vd Berg" <[EMAIL PROTECTED]>
Subject: Re: OT -- but you ain't gonna believe this
Date: Thu, 26 Aug 1999 03:50:02 +0200
Same with me, except the heading was different. Now there is a clue for
decription!
Rick Braddam <[EMAIL PROTECTED]> wrote in message
news:7q1r3o$pqb$[EMAIL PROTECTED]...
> I just recieved this in e-mail today. They must be really hurting for
"experts". Based on what little I know about my own
> shortcomings as a cryptographic programmer or user, I wouldn't recommend
the following:
>
> =Dear Rick Braddam,
>
> =I've been browsing the sci.crypt website and discovered that you are
quite knowledgeable about =Security and Encryption. I want to
> invite you to join us at
> = http://www.expertcentral.com/specialinvitation. ExpertCentral.com is a
site where users can =quickly find the right person to
> answer their questions on many different topics.
>
> =Because of your demonstrated knowledge, I'd like to start you off as a
highly-rated advisor in our =Computers & Internet category
> (as well as any additional categories where you think you can help
=people). Membership is FREE, incidentally.
>
> =By joining us, you'll receive honor, recognition and success. (We like to
state the risks in advance.) =You'll also get the
> satisfaction of helping people, while potentially earning money by
charging for =advice -- and, all the while, enhancing your
> reputation as an expert in your field.
>
> =What's more, if you're one of the first to join, you'll have an
opportunity to build a ratings lead (like =those enviable first
> sellers on eBay).
>
> =You'll appreciate that I had to go to some trouble to find you, and we'd
like to make it easier for =other people, so I hope you'll
> take the time to visit our site
> = (http://www.expertcentral.com/specialinvitation) to learn more.
>
> =Sincerely,
>
> =Geoff Ashman
> =Expert Recruiter
>
> =PS
> =We found you through painstakingly combing the Internet for high quality
experts to invite to join us. =Once again, membership is
> FREE and there are no hidden costs. If you join now you have a =chance to
win a Palm V connected organizer from Palm Computing.
>
>
>
------------------------------
From: "Thijs vd Berg" <[EMAIL PROTECTED]>
Subject: Re: Fermat theorem on primes?
Date: Thu, 26 Aug 1999 04:21:04 +0200
<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,
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!
Way to go mr. M. K. Shen!!! Keep on scanning the newsgroup for novices and
amateurs and people who are just interested and keep on trying to look
superior.
------------------------------
From: [EMAIL PROTECTED] (Michael D. Crawford)
Subject: Can americans export crypto when in another country?
Date: Wed, 25 Aug 1999 19:32:32 -0700
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] (Paul Rubin)
Subject: Re: OT -- but you ain't gonna believe this
Date: 26 Aug 1999 02:52:12 GMT
In article <7q1r3o$pqb$[EMAIL PROTECTED]>,
Rick Braddam <[EMAIL PROTECTED]> wrote:
>I just recieved this in e-mail today. They must be really hurting for
>"experts". Based on what little I know about my own shortcomings as a
>cryptographic programmer or user, I wouldn't recommend the following:
Yeah, I got one of those too. I replied by email and the guy actually
did answer some questions for me, so I don't especially feel spammed.
Well, only slightly spammed. I looked at the site and the idea is
kind of interesting, but it was carried out in such a tacky fashion,
and had obnoxious enough legal mumbo jumbo, that I decided not to sign up.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Fermat theorem on primes?
Date: 26 Aug 1999 02:47:29 GMT
Thijs vd Berg <[EMAIL PROTECTED]> wrote:
> 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
He didn't write "only if."
-David
------------------------------
** 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
******************************
