Cryptography-Digest Digest #494, Volume #10 Tue, 2 Nov 99 11:13:06 EST
Contents:
Re: Unbiased One to One Compression (Geoffrey T. Falk)
Re: Doesn't Bruce Schneier practice what he preaches? ("Ivanhoe")
SMARTCARD SECURITY NEWS ISSUE #7 ([EMAIL PROTECTED])
Re: Kerberos Question ("Craig Inglis")
Re: the ACM full of Dolts? (Mok-Kong Shen)
Re: the ACM full of Dolts? (Mok-Kong Shen)
Re: the ACM full of Dolts? (Mok-Kong Shen)
Re: the ACM full of Dolts? (Mok-Kong Shen)
Re: What is the deal with passwords? (Tom St Denis)
Re: What is the deal with passwords? (Tom St Denis)
Re: What is the deal with passwords? (Tom St Denis)
Re: What is the deal with passwords? (Tom St Denis)
Re: Compression: A ? for David Scott (SCOTT19U.ZIP_GUY)
Re: Compression: A ? for David Scott (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: gtf[@]cirp.org (Geoffrey T. Falk)
Subject: Re: Unbiased One to One Compression
Date: Tue, 02 Nov 1999 05:58:26 GMT
In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
>Geoffrey T. Falk <gtf[@]cirp.org> wrote:
>: In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
>:>Geoffrey T. Falk <gtf[@]cirp.org> wrote:
>
>:>: Again: Simply not being "one-on-one" itself, in general, only helps
>:>: the attacker if he can guess X and then compute Comp(Decomp(X)).
>:>
>:>No. Not at all. No, no, no, no, no!
>
>: OK, then give an example where the "not 1-1" helps the attacker, where
>: he does not know "X" and cannot compute Decomp(X).
>
>"Compression" involves interleaving the message with 0s.
>
>"Decompression" strips out alternate bytes iff they are zeros.
OK, very good start. Now, prove the reverse of my original claim "in
general": Namely, prove that ALL "not 1-1" compressions add information
that helps the attacker.
g.
--
I conceal nothing. It is not enough not to lie. One should strive
not to lie in a negative sense by remaining silent. ---Leo Tolstoy
ADDRESS ALTERED TO DEFLECT SPAM. UNSOLICITED E-MAIL ADS BILLED $500
Geoffrey T. Falk <gtf(@)cirp.org> http://www.cirp.org/~gtf/
------------------------------
From: "Ivanhoe" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk
Subject: Re: Doesn't Bruce Schneier practice what he preaches?
Date: Tue, 2 Nov 1999 01:15:28 -0500
John Kennedy <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I didn't mean "puzzling" to be inflamatory.
>
> I just find it puzzling, odd, inconsistent, by which I do not mean to
> imply fishy.
>
> You may not find it odd, but in light of Schneiers advice I do.
>
> I have not contacted them about it and I dont know if anyone has, it's
> not that big a deal to me. This is after all just a convienient doodad
> we're talking about, not something vital to anyone.
>
it does seem to be a contradiction. I'll offer another possible explanation;
that Schneier has become conditioned to a very minimal response to his
(and others') various calls for careful security practices. thus, his troops
develop a quick little utility to test Blowfish implementation on the Wintel
platform, and offhandedly decide to release it as freeware without really
expecting anyone to find it, much less use it.
alternatively, they may have wanted to get some experience with
retail- (i.e. end-user) interaction, sort of testing the waters.
at any rate, I believe if they felt that it was a serious tool, they would
have
offloaded the development to a reliable 3rd party outside the U.S. (I
believe
there is a quality implementation of Blowfish available from a German
academic,
for example). I don't yet think the Smoking Man has "turned" Schneier. ;)
there was a recent interview of Schneier on Slashdot, and he indicated that
his revenue model is still corporate consulting.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.security,comp.security.misc,alt.cellular-phone-tech
Subject: SMARTCARD SECURITY NEWS ISSUE #7
Date: Tue, 02 Nov 1999 08:19:36 GMT
SMARTCARD SECURITY NEWS ISSUE #7
Smartcard security technical info page is updated at URL:
http://www.geocities.com/ResearchTriangle/Lab/1578/smart.htm
This page contains technical information and links about
smartcards and especially smartcard security (including satellite
cards, GSM SIM cards, phonecards, banking cards,
secure microcontrollers, smartcard standards,
and smartcard protocols). Big attention is held on smartcard attacks.
There is no commercial and marketing blah blah.
The Smartcard Security News Issue #7 is also launched.
Hadlines:
- The (Tamper And Monitoring Protection Engineering Research)
Lab at the University of Cambridge Computer Laboratory
- Design Principles for Tamper-Resistant Smartcard Processors
by Oliver Kommerling and Markus G. Kuhn
- An article about Eurochip by [EMAIL PROTECTED]
- ST1-64 Free Basic Stamp 1 interpreter for PIC 16F84
- and much more...
Bo Lavare
If you want to be informed, subscribe the mailing list at
http://www.listbot.com/cgi-bin/subscriber?Act=subscribe_list&list_id=smartsec
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Craig Inglis" <[EMAIL PROTECTED]>
Subject: Re: Kerberos Question
Date: Fri, 29 Oct 1999 10:35:49 +0100
John Myre wrote in message <[EMAIL PROTECTED]>...
>
>Regarding Kerberos, EKE, and SPEKE, what about SRP? It's in
>the same general vein.
>
>It ought to be at http://srp.stanford.edu/srp/, although I
>can't seem to connect any more.
Or SNAKE, which isnt subject to the patent restrictions which
encumber the others.
see http://www.smdp.freeserve.co.uk/snake.html
an example application and source is there for the curious.
SNAKE is completely public domain... not open source or
GPL'd etc. :-)
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: the ACM full of Dolts?
Date: Tue, 02 Nov 1999 10:58:16 +0100
SCOTT19U.ZIP_GUY wrote:
>
> >Using an adaptive Huffman with an initial frequency distribution
> >does NOT add data to the file. The distribution is completely
> >hidden from the analyst.
>
> IF you mean my adaptive huffmna compressor which is one to one
> than if you use an intial frequency distributiuon you do NOT add data
> to the file.
Since the initial frequency distribution, like the key of the
encryption algorithm, is (or derived from) a secret information
kept at the place of both partners and is never transmitted together
with the messages, there is also no addition of data to the file
if one uses the 'normal' adaptive Huffman.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: the ACM full of Dolts?
Date: Tue, 02 Nov 1999 10:58:33 +0100
Tom St Denis wrote:
>
> You could build a random huffman tree for example and use it with your
> friend. This would make decompression randomly decrypted ciphertext
> awkward to say the least. However randomly created trees are hardly
> optimal, and optimal trees are hardly random...
To use a random Huffman tree is one of the ideas I pointed out
in the recent thread 'Notes on substitutions'. In the context
of cryptography the (main) goal is security, not optimal file size.
To generate a random binary tree is simple; from the programming
technique point of view there is nothing awkward in my humble opinion.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: the ACM full of Dolts?
Date: Tue, 02 Nov 1999 10:59:03 +0100
Tim Tyler wrote:
>
> How does your partner (to whom you are sending the message) get
> information relating to this distribution?
>
> He needs this information before he can decompress the messages.
>
> Is it:
>
> A) built into his decompressor;
> B) transmitted with each message;
> C) something else.
One way could be like this: One uses an agreed upon PRNG to generate
the intitial frequencies and load that into the adaptive Huffman. As
mentioned previously, this means however that the partners use, in
addition to the key of the proper encryption, some additional key
bits (the seed of the PRNG).
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: the ACM full of Dolts?
Date: Tue, 02 Nov 1999 10:58:49 +0100
Tim Tyler wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> : SCOTT19U.ZIP_GUY wrote:
>
> : Let me repeat: If one has an initial frequency distribution that
> : the analyst can't figure out, then he can't do any compression or
> : decompression properly.
>
> I don't understand.
>
> You're saying that the analyst can't decompress because he lacks frequency
> information about the distribution of possible plaintexts?
>
> I generally assume that the opponent has the cypher-machine (including any
> decompressor).
>
> If your are saying "the opponent cannot decompress", are you making
> different assumptions from me?
If you start with different initial frequency distributions of
adaptive Huffman and process the same plaintext, you get different
results. The analyst has the same algorithm but the initial
distribution is kept secret form him just as the key of any
encryption algorithm.
M. K. Shen
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What is the deal with passwords?
Date: Tue, 02 Nov 1999 12:19:31 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Johnny Bravo) wrote:
> Most people using secure encryption today don't really give a
flying fig about
> the NSA reading their mail, most people aren't that important. Other
than using
> digital signatures to verify that messages come from a particular
person, the
> majority of people who are using encryption are worried about someone
with
> physical access to the machine reading private files or
correspondence.
> (Private use, corporate secrets are another matter.)
>
> If anyone in the house can boot up the computer and read all your
encrypted
> mail, that is a serious security problem. Using a web based email
account with
> all the messages in plaintext would be more secure. For the private
files I
> have encrypted on my computer, I'd rather not have them become public
knowledge
> on the off chance that someone who gains access to my computer
without my
> knowledge (through theft of the machine, for instance).
Well I honestly believe you can never protect against a hacker sitting
at your computer. If need be, you can always put peekboo and your key
ring on a floppy and carry it with you...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What is the deal with passwords?
Date: Tue, 02 Nov 1999 12:20:36 GMT
In article <[EMAIL PROTECTED]>,
John Kennedy <[EMAIL PROTECTED]> wrote:
> Lack of encryption of a private key does not imply snake oil.
>
> I looked at the PeekBoo site and it does not smell particularly like
> snake oil.Iit may be fine.
Thanks. Do you have any comments or critisms? Should I add more info
to the website?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What is the deal with passwords?
Date: Tue, 02 Nov 1999 12:22:47 GMT
In article <[EMAIL PROTECTED]>,
John Kennedy <[EMAIL PROTECTED]> wrote:
> Depends. You have a point, but I can set up a virus free system for
> encryption for a lot less money that it would take to make my house
> burglar proof.
But you can always put peekboo on a floppy for 54 cents or so...
>
> For very high security I would use encrypted private keys, but
> unencrypted private keys may be perfectly acceptable for some
> purposes.
>
> Encrypted private keys can have another advantage, I don't need to
> keep them with me or on my machine at all. Hushmail keeps your
> encrypted private key for you and you can access it from any machine
> with a suitable browser.
Encryption of your key requires a very high entropy password. Most
people would use 'house' over '!@af331B%1%' so I don't really see a
security benefit other then making it a tad harder to attack. If you
don't have access to the keyring at all I think that makes it much
harder to attack.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What is the deal with passwords?
Date: Tue, 02 Nov 1999 12:24:41 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] () wrote:
> : True but you *can never* truly protect against mitm attacks. If you
> : can prove to me how.
>
> You got me there. You can't do that without a shared secret, you're
quite
> correct. But then, since you know that, why are you saying we don't
need
> passwords?
Because peekboo is an entire cryptosystem that doesn't require user
remember passwords. I find this to be very innovative and realistic.
> : Why would I protect against such things? Even PGP can fall quickly
> : with a remote malicious virus.
>
> True.
This is why Peekboo is 41kb and PGP is 7500kb ...
Note: I think PGP is very good software, just for my purposes it sucks
the big one [i.e encrypted email/chat].
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Compression: A ? for David Scott
Date: Tue, 02 Nov 1999 14:48:36 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>On Sun, 31 Oct 1999 11:03:30 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>>:> By one to one I mean for any file X Compress( Decompress (X)) = X
>>:>while most only consider for any file Y Decompress( Compress (Y)) = Y
>>:>most only consider the second but with encryption you need to consider
>>:>both.
>
>If the above is true, and the above equations hold true for any X and
>any Y, let's introduce a new term A, where A=Decompress(X). So now
>Compress(A)=X. If the compression function is used as input to
>encryption, A would be the input to encryption (function E), and X
>would be the plaintext. Thus the ciphertext, C, would be expressed
>as: C=E(Compress(A)). Since A is solvable (A=Decompress(X)), then
>plaintext can be chosen to create any desired input to the encryption
>algorithm.
>
>Note that this is not true with standard compression. Standard
>compression won't allow generation of every possible A.
>
Yes you are correct if you read my posts I admit that. If you
can get the attacker to mount a "total choosen file" kind of attack
you can reduce it to a total choosen file attack against the underlying
encryption system as if compression is not being used.
I never stated one-one compression prevented such attacks
I stated over and over again it does not add information to the system.
Note with statand compress you don't allow the generation of
every possible A so in a sense you can't try every type of plain
text attack against the encryption system. But then again you can
may times break the system only by analizing cipher text traffic alone
you don't need the victims help un doing total plain text file attacks
as is needed in one-one compression. You also are limiting the
space of inputs if mot are all there so you are reducing the overall
size of the solution space if not all files are allowed so you do have
a easier problen in general to break the system.
If you fell that it is a bonus to limit the input space of the encryption
system by using non one to one compression while at the same time
giving an attacker information when he looks at cipher text only go ahead.
I would rather use one-one compression where the attacker gets no free
rides and extra info from a cipher only attack. Which you don't seem to
understand that it is an order of magnitude worse to have weaknesses
available from a cipher only attack.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Compression: A ? for David Scott
Date: Tue, 02 Nov 1999 14:51:24 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>On Mon, 1 Nov 1999 10:13:53 -0600, "Tim Wood" <[EMAIL PROTECTED]>
>wrote:
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>
>>Tom wrote in message <[EMAIL PROTECTED]>...
>>>On Sat, 30 Oct 1999 13:27:48 GMT, [EMAIL PROTECTED]
>>>(SCOTT19U.ZIP_GUY) wrote:
>>>
>>>> By one to one I mean for any file X Compress( Decompress (X)) =
>>X
>>>>while most only consider for any file Y Decompress( Compress (Y)) =
>>Y
>>>>most only consider the second but with encryption you need to
>>consider
>>>>both.
>>>>..
>>>That means that in some cases you'll be reducing patterns, and in
>>>other cases creating them.
>>>
>>>Worse than that - this scheme makes the implementation of a chosen
>>>plaintext attack trivial, where using standard compression makes some
>>>forms of chosen plaintext attack completely impossible.
>>
>>This is not true. Assuming that the attaker can _choose_ the plaintext
>>it makes no difference what compression is used. The plaintext chossen
>>is the binary string *after* compression.
>
>Afraid it is.
>
>A chosen plaintext attack is just that - the person attempting to
>decrypt has the ability to insert data into the system before the
>encryption process. If the one-on-one system were implemented as part
>of a businesses data communication system, it doesn't sound too far
>fetched to be able to sneak additional information into the system to
>be encrypted. In any event, this is the definition of a chosen
>plaintext attack. To consider the compression as part of the system
>only makes sense, as it is being presented as being suited for use
>with encryption.
>
Yes you are correct if you read my posts I admit that. If you
can get the attacker to mount a "total choosen file" kind of attack
you can reduce it to a total choosen file attack against the underlying
encryption system as if compression is not being used.
I never stated one-one compression prevented such attacks
I stated over and over again it does not add information to the system.
Note with statand compress you don't allow the generation of
every possible A so in a sense you can't try every type of plain
text attack against the encryption system. But then again you can
may times break the system only by analizing cipher text traffic alone
you don't need the victims help un doing total plain text file attacks
as is needed in one-one compression. You also are limiting the
space of inputs if mot are all there so you are reducing the overall
size of the solution space if not all files are allowed so you do have
a easier problen in general to break the system.
If you fell that it is a bonus to limit the input space of the encryption
system by using non one to one compression while at the same time
giving an attacker information when he looks at cipher text only go ahead.
I would rather use one-one compression where the attacker gets no free
rides and extra info from a cipher only attack. Which you don't seem to
understand that it is an order of magnitude worse to have weaknesses
available from a cipher only attack.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
** 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
******************************
