Cryptography-Digest Digest #90, Volume #10 Sat, 21 Aug 99 17:13:06 EDT
Contents:
Re: Crypted messages inside porno spams? (Dave Salovesh)
Re: CRYPTO DESIGN MY VIEW (Mok-Kong Shen)
simple message encryptor for ICQ like programs (Tom St Denis)
Re: truly anonymous membership proof (stanislav shalunov)
Re: Crypto for PALM III? (Keith A Monahan)
Why wait for the patent? - Ciphile Software (Anthony Stephen Szopa)
Re: Why wait for the patent? - Ciphile Software (David A Molnar)
Re: CRYPTO DESIGN MY VIEW (SCOTT19U.ZIP_GUY)
Re: simple message encryptor for ICQ like programs (Michael J. Fromberger)
Re: Human-Readable Encryption (Newbie) (Jim Dunnett)
Re: truly anonymous membership proof (David A Molnar)
Re: all or nothing (wrapped pcbc) (David A Molnar)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Dave Salovesh)
Subject: Re: Crypted messages inside porno spams?
Date: Sat, 21 Aug 1999 17:05:16 GMT
In article <7pjgo3$ker$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] opined:
>I noted that a lot of spam messages end with a random-like sequence of
>lowercase chars and spaces. Something like this
That's just padding, thrown in to mislead the automated spam cancel
software.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Sat, 21 Aug 1999 19:47:02 +0200
SCOTT19U.ZIP_GUY wrote:
>
> >> First of all the proof is in the working program. Find an example
> >> od where a file that when being decompressed and then compressed
> >> again does not back to the same and you haev found a error
> >>
> >> the file ... xxxxxxxy yyyyyyyy would decompress to what I guess
> >> you want.
> >> the file xxxxxxxxy and the last byte gone would decompress to
> >> something different. But when you compress the file you got from
> >> decompressing you get a file that ends with xxxxxxxy
> >
> >But you can't decompress according to the Huffman scheme, because
> >suppose this first y following x is, say, 0, then, since 0 followed
> >by 8 bits is a valid Huffman code, 0 alone can't be a valid huffman
> >code (this follows from the principle of construction of the
> >Huffman tree). This proves that the algorithm after finishing the x's
> >and finding the first y (here 0) can't do anything anymore. Isn't that
> >clear?
> It is clear to me you have a very closed mind. What is being done
> is a "mod" to handle the fact that huffman compression may end on
> a non byte boundary. I handle the mode such that sometimes the
> last byte is left alone. Sometimes zeros are added. Sometimes it is
> deleted. The mode is such that there are no incconsisties. Every file
> as a "unique expansion" and every file has a "unique compression".
> But since this is over your head you sit and argue. WHY DON'T you
> test it. IT WORKS. just because you can't seem to expand on the
> concept in your limited way of thinking does not mean it is not
> being done. As I feared I am going out of my way to help you. At least
> this time it is on this forum. Instead of email. I do have one question
> have you ever been a member of MENSA?. I was for a while since I worked
> for a boss who thought it was hot shit. Pissed him off when they allowed
> a beer drunking asshole like me in.
I am very surprised that you don't yet catch my point. Why did you
say 'the Huffman compression may end on a non-byte boundary' and 'some
times the last byte is left alone. Sometimes zeros are added. Sometimes
it is deleted' with respect to the 'particular' case I constructed???
In that particular case the Huffman compression happens (by
construction) to end 'exactly' on a byte boundary, so we can forget in
the present discussion the general case of ending on a non-byte
boundary and hence needing padding (or your 'deletions'), can't we???
In that particular case the last character of the input file has a
Huffman code of 9 bits and the input sequence (by construction) is
such that the pre-ultimate byte has only 1 bit free so that the first
bit of the 9 bits of the Huffman code gets into the pre-ultimate byte
and the remaining 8 bits fill (entirely) the last byte. Are you going
to add any zeros in this situation?? (It would be foolish if you would
do that.) Are you going to delete the last 8 bits?? (You couldn't do
that, because we can assume that there are other input characters that
also have a code of 9 bits beginning with 0 and hence if you delete
the 8 bits you wouldn't be able to uniquely get back to the original
file.) Do you agree with what I write above?? If you don't agree
with the above, please kindly say so and give your precise and
clear-cut counter-arguments.
Thus said, it should be clear that in my example the original file
will be encoded such that there is no filling bits (padding), nor
any of your mentioned 'deletions'. Hence I repeat that the last 2
bytes of the (correct) output file are exactly of the form
xxxxxxxy yyyyyyyy. (Any disagreements up to here???) To be concrete,
let's assume that these are xxxxxxx0 10111010. Now the 'wrong' file
is by constrution the correct file minus the last byte. Hence the
'wrong' file terminates with xxxxxxx0. Let's now apply the Huffman
uncompressing algorithm parallely to both files and follow these two
processes step by step (side by side). All the steps are obviously
the same up to the point when the xxxxxxx above get processed
(decoded). (Do you agree??) Now the process handling the correct file
can further proceed. It finds first the 0 bit. Since 0 alone isn't
a valid code in our case (see below) it continues to fetch further
bits till a valid Huffman code is obtained -- in the present case it
happens (by construction) that it has to fetch exactly 8 more bits
in order to obtain a valid code. Thereafter it encounters the end
of file and terminates normally and correctly, there being no more
bits hanging unprocessed. (That 0 alone is not a valid Huffman code
in our case is because by our assumption there is a valid code
beginning with 0 and longer than 1 bit, namely 9 bits in total.
Do you agree with this?? If not, please say so!) On the other
hand, the other process similarly gets (after finishing with the x's)
the 0 bit. But this 0 is at the end of the (wrong) file processed by
it. As said above, 0 is not a valid Hoffman code. What should now this
process do in this situation??? I have in the previous post listed a
few possibilities, but unfortunately none of these is a 'normal'
termination!! Now please say clearly and directly what in your opinion
the process handing the 'wrong' file will do and how it can do that?
(Could it probably 'guess' the 8 bits that I have deleted or else do
anything else than the possible actions that I listed previously?????)
M. K. Shen
================================
http://home.t-online.de/home/mok-kong.shen (new web addr.)
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: simple message encryptor for ICQ like programs
Date: Fri, 20 Aug 1999 18:55:26 GMT
If anyone is interested I wrote a simple RC4 message encryptor where it
will encrypt messages to the clipboard and decrypt messages from the
clipboard...
If anyone wants a copy (whopping 7kb) ask me at
[EMAIL PROTECTED]
or
icq: 46838187
It's not tied to ICQ but usefull with it...
Thanks for the time
Tom
p.s if you want to know the details it's basically RC4 with the
password used as a key with a 32-bit salt (seeded from the milliseconds
since you turned on your computer). I dumnp the first 1024 bytes to
avoid week keys.... simple as that! (it's not secure if someone can
break into your computer though, no stack cleanup....)
--
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: stanislav shalunov <[EMAIL PROTECTED]>
Subject: Re: truly anonymous membership proof
Date: 21 Aug 1999 13:37:34 -0400
[EMAIL PROTECTED] (Ben Handley) writes:
> Is there a known method for proving membership to a group, without
> even the issuing body being able to tell who you are by your
> response? It should also make it not possible for people to pass on
> the information necessary to prove membership to others (presumably
> by requiring that the person use their private key as part of the
> verification process).
I don't think there can be a solution to this problem. If entity A
can prove it belongs to the group, it can pass all its knowledge to
unauthorized entity B, that now would be able to replay A's behavior
in any protocol.
It's like saying ``I want to truely ensure I talk to Jim without
anyone being able to impersonate him without knowing Jim, even if Jim
co-operates with the impostor.''
> I think that I have a solution to this problem [...]
Post it.
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: Crypto for PALM III?
Date: 21 Aug 1999 18:48:06 GMT
Good question... What packages have you seen? I'd be interested in at least
reviewing the software.... I think I've seen one or two, but they are really
home-made algorithms from what I remember.
I'd love to see a Blowfish or IDEA implementation on the palm.
Keith
grimm ([EMAIL PROTECTED]) wrote:
: greetings,
: Like many others, I'm finding myself using my PALM III
: a great deal, but I would really like to know what you
: guys have to say about encryption programs for the
: palm III. I have tried a few and seen many which have
: already been cracked.
: I have also seen many supposed 128 bit encryption
: programs which don't even bother masking the password
: entry box.
: There must be someone out here who has some suggestions
: on advanced crypto packages for the palm III. When is
: Palm PGP coming out? <grin>.
: [EMAIL PROTECTED]
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Why wait for the patent? - Ciphile Software
Date: Sat, 21 Aug 1999 12:07:04 -0700
Reply-To: [EMAIL PROTECTED]
Why wait for the patent? - Ciphile Software
OAP-L3 is available now as shareware.
Included are extensive help files that contain a detailed explanation
of 1) the random number generator engine and the encryption process
2) the otp file management system.
Also included are test files and procedures so you can prove for
yourself that every aspect / detail of the software is implemented
correctly and carries out each process precisely as described.
Essentially, the OAP-L3 Help Files are the patent description and
operation submission sections.
All your questions are answered in these Help Files. Get the shareware
from me or someone who has indicated they already have it.
The latest self extracting ZIP file: OAPL3_41.exe is dated 8/19/99.
You can get it from Ciphile Software at http://www.ciphile.com or get a
copy from someone you know who already has it.
(It sounds like Dr. Jeff knows what he is talking about. Get the
software so you will, too.)
Thanks.
AS
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: Why wait for the patent? - Ciphile Software
Date: 21 Aug 1999 19:58:02 GMT
In sci.crypt Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> Included are extensive help files that contain a detailed explanation
> of 1) the random number generator engine and the encryption process
> 2) the otp file management system.
Thanks for pointing this out. You might want to mention this somewhere on
the web site; it wasn't clear to me that the extra files included
this...which is one of the reasons I was annoyed in a previous post.
Also, it would be really nice if the detailed explanation
could be posted on or downloaded from the web site. That way if someone
would like to comment on it, they can include links to appropriate parts.
-David
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Sat, 21 Aug 1999 20:01:23 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> ...
> I am very surprised that you don't yet catch my point. Why did you
> say 'the Huffman compression may end on a non-byte boundary' and 'some
> times the last byte is left alone. Sometimes zeros are added.
Sometimes
> it is deleted' with respect to the 'particular' case I constructed???
"that is what I write" you give an example of the last two bytes
as determined by the tree. My code is a MODE of Huffman for causing
the ending to end on a byte boundary. DO you understand the word
MODE ( hell maybe it is spelt MOD I am not sure if spelling but you
should know my spelling sucks such English is inferior in its
spelling methods.)
> In that particular case the Huffman compression happens (by
> construction) to end 'exactly' on a byte boundary, so we can forget in
> the present discussion the general case of ending on a non-byte
> boundary and hence needing padding (or your 'deletions'), can't we???
Ok I am trying to follow your logic though different than
mine.
> In that particular case the last character of the input file has a
> Huffman code of 9 bits and the input sequence (by construction) is
> such that the pre-ultimate byte has only 1 bit free so that the first
> bit of the 9 bits of the Huffman code gets into the pre-ultimate byte
> and the remaining 8 bits fill (entirely) the last byte. Are you going
> to add any zeros in this situation?? (It would be foolish if you would
> do that.) Are you going to delete the last 8 bits?? (You couldn't do
> that, because we can assume that there are other input characters that
> also have a code of 9 bits beginning with 0 and hence if you delete
> the 8 bits you wouldn't be able to uniquely get back to the original
> file.) Do you agree with what I write above?? If you don't agree
Lets say for the sack of argument I am trying to follow
what you say but I would not word it that way.
You can use the "DAM EXECTUABLE TO CHECK
THIS". That being said why would add zeros in the case you said.
Howeveer many some one can come up with a mod that is still one to one
and still add zeros for the next word. I guess the first question
I need to ask you is xxx...y y...y what your are looking at the
the compressed file or is the the last 2 symbols that came out of
the pure huffman part of ptogram before the file is actaully written.
Assumming the latter and assuming the the patterrn has exactly 9 bits
then they can't all be ones in this case and the file is wwritten out
as is. But the fact that just becasue there are several possible bit
patterns that can "span" the last two bytes does not mean that you
have to always save the last byte to the file that is wasted space.
If the last symbol spans two bytes I only write it to the file if
the expansion part is not all ones and the prepart not all zeroes.
Note this alone is not enough to guarantee that the moded Huffman
compression is "one to one" You haave to play games with the TREE.
Which adds nothing to space used since there are many trees that
compress exactly the same.
> with the above, please kindly say so and give your precise and
> clear-cut counter-arguments.
>
> Thus said, it should be clear that in my example the original file
> will be encoded such that there is no filling bits (padding), nor
> any of your mentioned 'deletions'. Hence I repeat that the last 2
> bytes of the (correct) output file are exactly of the form
> xxxxxxxy yyyyyyyy. (Any disagreements up to here???) To be concrete,
> let's assume that these are xxxxxxx0 10111010. Now the 'wrong' file
> is by constrution the correct file minus the last byte. Hence the
> 'wrong' file terminates with xxxxxxx0. Let's now apply the Huffman
> uncompressing algorithm parallely to both files and follow these two
> processes step by step (side by side). All the steps are obviously
> the same up to the point when the xxxxxxx above get processed
> (decoded). (Do you agree??) Now the process handling the correct file
So far we agree which I find truely amazing since we usually
can't agree on anything. Maybe I think we agree but maybe we both
interpt what you said above differently. In which case I can actaully
only state if you mean what I mean by what you wrote in the preecding
paaragraph we agree.
> can further proceed. It finds first the 0 bit. Since 0 alone isn't
> a valid code in our case (see below) it continues to fetch further
> bits till a valid Huffman code is obtained -- in the present case it
> happens (by construction) that it has to fetch exactly 8 more bits
> in order to obtain a valid code. Thereafter it encounters the end
> of file and terminates normally and correctly, there being no more
> bits hanging unprocessed. (That 0 alone is not a valid Huffman code
> in our case is because by our assumption there is a valid code
> beginning with 0 and longer than 1 bit, namely 9 bits in total.
> Do you agree with this?? If not, please say so!) On the other
Only to the extent of my preceeding comment and to the assumption
that your talking about the long case.
> hand, the other process similarly gets (after finishing with the x's)
> the 0 bit. But this 0 is at the end of the (wrong) file processed by
> it. As said above, 0 is not a valid Hoffman code. What should now this
> process do in this situation??? I have in the previous post listed a
> few possibilities, but unfortunately none of these is a 'normal'
> termination!! Now please say clearly and directly what in your opinion
> the process handing the 'wrong' file will do and how it can do that?
> (Could it probably 'guess' the 8 bits that I have deleted or else do
> anything else than the possible actions that I listed previously?????)
in the above case the program would have noticed ( assuming we
are looking at decompression now) that it got previously a valid
symbol the x's. Since theer is still from 1 to 7 ( not eight ) bits
left it checks to see if they are all zero. They are all zzero so
the x's maarked the last symbol. I think you may be confused in
that you think this is an error. It is not. In there two examples
if you decompress them and recompress then you get the starting
files back. There is still the preserve one to one ness of the
compression decompression routines.
Even though we went through this one example this time I bet
you still don't have aa clue as to what I am talking aboutt.
Sure I made a mess of english mistaaakes but you have an executabe
you should have a hex dump and hex editor if not I can give you
one. You can check this your self.
http://members.xoom.com/ecil/compress.htm for compression code
--
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
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Michael J. Fromberger <[EMAIL PROTECTED]>
Subject: Re: simple message encryptor for ICQ like programs
Date: 20 Aug 1999 19:57:19 GMT
In <7pk8ao$7i0$[EMAIL PROTECTED]> Tom St Denis <[EMAIL PROTECTED]> writes:
>If anyone is interested I wrote a simple RC4 message encryptor where
>it will encrypt messages to the clipboard and decrypt messages from
>the clipboard...
>If anyone wants a copy (whopping 7kb) ask me at
>[EMAIL PROTECTED]
>or
>icq: 46838187
>It's not tied to ICQ but usefull with it...
>Thanks for the time
>Tom
>p.s if you want to know the details it's basically RC4 with the
>password used as a key with a 32-bit salt (seeded from the
>milliseconds since you turned on your computer). I dumnp the first
>1024 bytes to avoid week keys.... simple as that! (it's not secure
>if someone can break into your computer though, no stack cleanup....)
Hi, Tom...
Why don't you have a look at Arnold Reinhold's "CipherSaber" page, at:
http://ciphersaber.gurus.com/
CipherSaber-1 is similar in design to yours, and if you converted your
program to use it, you'd be interoperable with anyone else who already
has a CS-1 implementation (such as myself, for example! :)
Cheers,
-M
--
Michael J. Fromberger Software Engineer, Thayer School of Engineering
sting <at> linguist.dartmouth.edu http://www.dartmouth.edu/~sting/
Z0UjAe/Nq4mYuohlNyZuNaPu/CPbUNFUTsRiBAEAtdpCnvGR+DzTVcB2akadeFSkLNJ1UeQj
If all these sweet young things were laid end-to-end, I wouldn't be a
bit surprised. -- Dorothy Parker
------------------------------
From: [EMAIL PROTECTED] (Jim Dunnett)
Subject: Re: Human-Readable Encryption (Newbie)
Reply-To: Jim Dunnett
Date: Sat, 21 Aug 1999 18:59:22 GMT
On Fri, 20 Aug 1999 20:00:00 GMT, [EMAIL PROTECTED] (John
Savard) wrote:
><[EMAIL PROTECTED]> wrote, in part:
>
>>I am looking for algorthims (even a weak cipher will do nicely) that will
>>encrypt a message into a human-readble encrypted form. Specifically I would
>>like to specify a resulting numeric range that could correspond to the ASCII
>>character set (e.g. ASCII 32-126, or {space} through {~}). I would also
>>like to be able to decrypt (is this implied?).
>
>Even PGP does this: binary encrypted output is converted to printable
>character form in a process called 'armor' so that it will be more
>easily transmitted through the Internet.
There's also 'ATBASH'. This converts ASCII to 5-character groups
(mixed upper-case letters and figures).
I don't know how strong the crypto is. ISTR it uses IDEA or at least
one of the reliable algorithms.
--
Regards, Jim. | We have decided not to go to France
amadeus%netcomuk.co.uk | this summer as it is too full of
dynastic%cwcom.net | unattractive, shirtless Englishmen
| talking into mobile 'phones.
PGP Key: pgpkeys.mit.edu:11371 | - Auberon Waugh.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: truly anonymous membership proof
Date: 21 Aug 1999 19:37:31 GMT
stanislav shalunov <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Ben Handley) writes:
>> the information necessary to prove membership to others (presumably
>> by requiring that the person use their private key as part of the
>> verification process).
> I don't think there can be a solution to this problem. If entity A
> can prove it belongs to the group, it can pass all its knowledge to
> unauthorized entity B, that now would be able to replay A's behavior
> in any protocol.
Indeed. I think that last parenthetical comment was aimed at making the
"info needed to prove belonging to the group" include A's private key. If
A has to give B its private key before B can prove he's a group member...A
might think twice. So while the maximal case is impossible, you may be
able to get a scheme where showing B how to prove group membership leads
to horrible consequences for A.
> It's like saying ``I want to truely ensure I talk to Jim without
> anyone being able to impersonate him without knowing Jim, even if Jim
> co-operates with the impostor.''
Except how far will Jim's cooperation go ?
-David
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: all or nothing (wrapped pcbc)
Date: 21 Aug 1999 19:51:24 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> DS keeps saying 'you change one bit of ciphertext and the message is
> corrupt' but is that really better? Either you know the key or you
> don't....
you generally would like your encryption to be non-malleable -- by that I
mean if an attacker changes bits in the ciphertext, it should
a) be unable to pick any sort of target for the new plaintext
and
b) the legitimate decryptor should know the ciphertext was tampered with.
Preferably before decrypting, if possible.
The classic example of why you need it is the "auction problem" (due to
Moni Naor and maybe others) : lots of people are bidding on items in an
auction. The attacker is not powerful enough to impersonate any of these
people, but he figures out how to flip the right bits to change, say, the
thousands' digit of a bid. Now he can mess with the bids of the people he
doesn't like -- and if the auction house doesn't confirm bids with them
thru some channel he doesn't control, they never know.
You also need it for bit commitment. If an attacker can damage a
commitment going between Alice and Bob such that it looks like some
legitimate value (just not the one which was committed to), then when it
comes time to open and compare cmmitments, there will be trouble. The
values will be different, and Alice and Bob will have no way of knowing
whether one cheated the other or who did it.
so yes, it is a nice property to have.
-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
******************************
