Cryptography-Digest Digest #113, Volume #11 Sun, 13 Feb 00 11:13:01 EST
Contents:
Re: Which compression is best? (Helger Lipmaa)
Re: Message to SCOTT19U.ZIP_GUY (Tim Tyler)
Re: Period of cycles in OFB mode (Helger Lipmaa)
Re: Which compression is best? (SCOTT19U.ZIP_GUY)
Re: RFC: Reconstruction of XORd data (Mok-Kong Shen)
Re: New encryption algorithm ABC. (Tim Tyler)
Re: Which compression is best? (Tim Tyler)
Free C Crypto API -- Update (Tom St Denis)
Re: Which compression is best? (Tim Tyler)
Re: Which compression is best? (SCOTT19U.ZIP_GUY)
Re: Guaranteed Public Key Exchanges (No Brainer)
Re: Guaranteed Public Key Exchanges (No Brainer)
----------------------------------------------------------------------------
From: Helger Lipmaa <[EMAIL PROTECTED]>
Subject: Re: Which compression is best?
Date: Sun, 13 Feb 2000 16:27:08 +0200
Tim Tyler wrote:
> Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> : [EMAIL PROTECTED] wrote:
>
> :> 1) From a security perspective, how important is compression? Is
> :> prior compression just a kind of "weak enhancement" or is it
> :> considered an integral part of the encryption process as a whole?
>
> : If you don't know for sure that the enemy cannot crack your
> : encryption, then precompression at least interferes with attacks
> : based on statistical characteristics of the plaintext source
> : language, which *might* reduce the chances of the enemy reading
> : your message.
>
> This appears to cover 100% of all cases.
>
> : On the other hand, if you have justifiable confidence in your
> : cryptosystem, precompression would be a waste of resources.
>
> While this seems to cover pretty much 0% of them. How can you
> /know/ that any confidence you have in your cryptosystem is justifiable?
> You can't. You have to juggle probabilities.
Use semantically secure public key cryptosystems (ElGamal, for example). Only
in very weak cryptosystems (like some published in this newsgroup;)
compression really helps: thwarting statistical attacks is one of the most
basic requirements to the todays cryptosystems. If you don't believe they do
it in a satisfactory manner, don't use them for anything at all!
> You're compressing in order to add strength, and frustrate the analyst -
> *not* simply to remove redundancy present in the plaintext. Size simply
> is not the only criteria which is relevant.
This is done by encryption, frustrating the analyst has never been an
objective of compression. Leave security for cryptography and compressing for
compression!
Helger Lipmaa
http://home.cyber.ee/helger
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Message to SCOTT19U.ZIP_GUY
Reply-To: [EMAIL PROTECTED]
Date: Sun, 13 Feb 2000 14:23:38 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Encrypting something twice does not double the time to break.
:> Speaking *very* roughly, if anything, it squares it.
: If the encryption uses the same key, then it doubles the time
: for a brute-force key search.
Yes, but the passage apparently at the root of this seems to begin:
``Encrypt with Block Cipher A ( Key kA) [...]
Encrypt with Cipher B (Key kB) [...]
Encrypt with Cipher C (kC) [...]''
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Where you go depends on how you look.
------------------------------
From: Helger Lipmaa <[EMAIL PROTECTED]>
Subject: Re: Period of cycles in OFB mode
Date: Sun, 13 Feb 2000 16:32:59 +0200
David Wagner wrote:
> In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
> > Clearly, an arithmetic count sequence is very regular: The lsb
> > changes every time; the next higher bit half as often, and then only
> > when the lsb changes to zero. That is a lot of statistical
> > bit-position information which may be amenable to frequency and phase
> > detection techniques.
> >
> > Now, if the block cipher is perfect in practice, all this should not
> > be a problem. But practical block ciphers may not wrap one edge to
> > the other, and bit-diffusion from an edge of the block may not be as
> > good as we would expect elsewhere. The extremely strong counter
> > signal may thus expose cipher problems which would otherwise be
> > hidden.
>
> Good point.
> For instance, if there are good differential attacks, counter
> mode is skating on thin ice.
But a good cipher is not supposed to have such attacks, right? :-) If a cipher is
differentially weak, you can mount a lot of different attacks on it (including
ciphertext-only attacks). I wouldn't buy such cipher anyways; a good block cipher
should look like a pseudorandom permutation. For ideal ciphers (pseudorandom
functions), counter mode is actually better than the CBC mode, since one cannot
apply birthday attacks on this mode.
> Do you mean using a LFSR to drive the block cipher?
> That sounds like a good idea, if it was what you meant.
Or may be Gray codes :-)
Helger Lipmaa
http://home.cyber.ee/helger
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: Re: Which compression is best?
Date: Sun, 13 Feb 2000 15:02:47 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Tim Tyler wrote:
> >
> > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > : John Chandler wrote:
> >
> > :> I just noticed a post crediting "DS" with suggesting using
> > :> adaptive compression in _both_ directions before encrypting.
> >
> > : If the forward pass does a good compression job, I wonder how much
> > : additional compression could be expected from the backward pass.
> >
> > The backward pass is not intended to compress. AFAICS, It's purpose
is
> > primarily to make sure that information necessary to decrypt
plaintext is
> > not present in any fragment of the message.
>
> Depending on the compression algorithm, the backward pass is not
guaranteed
> to do anything substantive at all. Many adaptive algorithms will
simply
> give up and copy the data verbatim (with a tag indicating that is what
has
> been done) when they find that it isn't compressible by a significant
> amount - which it won't be after the forward pass. In fact if an
algorithm
> *doesn't* do this, it can end up substantially expanding some inputs;
this
> is one of the problems with the Unix "compress" (.Z) format.
>
> > This means (for one thing) that an analyst is effectively forced to
> > decrypt the whole message in order to recover any decompressed text
at all
> > - which you will probably need to do before you can reject a key.
>
> The analyst is not necessarily forced to do any such thing, unless you
> place much stronger constraints on the compression algorithm than are
> normally assumed (different contraints than the "good enough" property
we
> have been discussing in another thread). The problem seems to be that
this
> construction tries to use a compression algorithm for mixing, which it
is
> not designed for.
>
> If you need an all-or-nothing-transform, use something that has been
> analysed for that specific use; don't try to construct one badly from
a
> compression algorithm.
>
Some what true but not to the degree you imply. We where
talking about compression. But if one wants a "all-or-nothing"
type of encryption I can think of no better than scott19u.zip
which the phony crypto gods have declatred dead several times
but when there methods fail to crack they whine like babies
saying they can't understand code that is compliable. And
they don't have the BALLS to run a contest for cash like I
did for over a year. Since they know the AES methods are CRAP.
--
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/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: RFC: Reconstruction of XORd data
Date: Sun, 13 Feb 2000 16:16:44 +0100
Jerry Coffin wrote:
>
> Right -- when you get down to it, the individual components of most
> ciphers aren't worth a whole lot by themselves. It's only when you
> combine a number of these components that you gain a lot of strength.
> You've pointed out the importance of diffusion, and Doug Gwyn
> mentioned the importance of non-linearity, typically implemented in S-
> boxes.
>
> At least in a block cipher, you want to ensure that you use enough
> rounds that your diffusion is complete throughout the block -- I.e.
> that each bit of input has had a chance to affect each bit of the
> output. Addition gives a diffusion rate of roughly 3/8ths, meaning
> you want a minimum of three rounds of addition in each direction to
> give each bit of input a good chance of affecting each bit of the
> output.
Many thanks for the valuable comments. How to best incorporate
nonlinearity into algorithms is indeed the 'art' of cipher designers.
I only like to add that it is desirable that the number of rounds be
variable, i.e. user choosable instead of being fixed in implementations.
M. K. Shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: New encryption algorithm ABC.
Reply-To: [EMAIL PROTECTED]
Date: Sun, 13 Feb 2000 15:18:51 GMT
Bogdan Tomaszewski <[EMAIL PROTECTED]> wrote:
: [...] You know some programme testing entropia or breaking keys?
"ENT" claims to be able to test entropy:
http://www.fourmilab.ch/random/
You may be better off with "Diehard":
http://stat.fsu.edu/~geo/diehard.html
I don't think it pretends to be able to measure entropy - but is probably
more like what you want.
Any "key breaker" is not very likely to be of much use on a new (and
unknown-to-it) algorithm.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
I will never lie to you.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Which compression is best?
Reply-To: [EMAIL PROTECTED]
Date: Sun, 13 Feb 2000 15:26:44 GMT
Helger Lipmaa <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
:> : [EMAIL PROTECTED] wrote:
:> :> 1) From a security perspective, how important is compression? Is
:> :> prior compression just a kind of "weak enhancement" or is it
:> :> considered an integral part of the encryption process as a whole?
:>
:> : If you don't know for sure that the enemy cannot crack your
:> : encryption, then precompression at least interferes with attacks
:> : based on statistical characteristics of the plaintext source
:> : language, which *might* reduce the chances of the enemy reading
:> : your message.
:>
:> This appears to cover 100% of all cases. [snip]
: Use semantically secure public key cryptosystems (ElGamal, for example).
Too slow.
: Only in very weak cryptosystems (like some published in this newsgroup;)
: compression really helps: thwarting statistical attacks is one of the most
: basic requirements to the todays cryptosystems. If you don't believe they do
: it in a satisfactory manner, don't use them for anything at all!
That would rather stunt communication in the un-believers, wouldn't it?
If you have "faith" in your entire system (i.e. not just your cyphers), by
all means ignore the security aspects of compression. There's no point
improving your security if you're already happy with it.
Others should probably consider the issue, if they send many redundant
messages, or help others to do so.
:> You're compressing in order to add strength, and frustrate the analyst -
:> *not* simply to remove redundancy present in the plaintext. Size simply
:> is not the only criteria which is relevant.
: This is done by encryption, frustrating the analyst has never been an
: objective of compression.
Yes it has. It is now.
: Leave security for cryptography and compressing for compression!
This appears to be bad advice.
Compressors designed /only/ to compress will probably not pay any
attention to getting the 1-1 property - which is desirable because it
demonstrably avoids systematically adding information to compressed files,
whcih can act like known plaintext, and prevents the attacker from
eliminating keys with *absolutely no knowledge* of the plaintext of the
messages being sent.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Atheism is a non-prophet organisation.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Free C Crypto API -- Update
Date: Sun, 13 Feb 2000 15:31:01 GMT
At:
http://www.dasoft.org/peekboo/cb.html
Is the updated version of my Crypto API for C. It includes various
symmetric ciphers, RSA signatures/encryption, signatures of in memory
blocks or files. Symmetric encryption of in memory blocks or files,
data compression [using LZO], hashing using SHA, and a base64
encoder/decoder.
If you want to contribute, make a suggestion, perhaps fix a bug, or
make makefiles for other platforms, email me at [EMAIL PROTECTED], I would
appreciate the help.
All the source is there, and it should build with LCC-win32 and DJGPP.
It's little endianed, but I hope to fix that :)
Thanks for your time,
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Which compression is best?
Reply-To: [EMAIL PROTECTED]
Date: Sun, 13 Feb 2000 15:34:58 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> How can you /know/ that any confidence you have in your cryptosystem is
:> justifiable? You can't. You have to juggle probabilities.
: You prove an appropriate theorem using appropriate methods
: (as opposed to blathering about how you don't know all methods
: of attack).
Your cryptosystem can be insecure through bribery, theft, covert
observation, espionage, stupidity, bugs, and so on.
What "appropriate theorems" should be used to quantify these things?
Bear in mind that some attackers have been practicising their art in
secret for an extended period, and consequently the capabilities of
these opponents are very difficult to say much about.
Quantifying security is /really/ difficult. People have been estimating
the strength of their systems wildly incorrectly for centuries.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Leglise IT.
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: Re: Which compression is best?
Date: Sun, 13 Feb 2000 15:44:23 GMT
In article <[EMAIL PROTECTED]>,
Jerry Coffin <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
> [ ... ]
This is getting to large and bloated. It is a pitty
you don't have a grasp of what is going on. I can no longer
get the sci.crpt downladed to my newsreader so have to use
the slower than shit deja news one. But Tyler knows and understands
1-1 compression and its uses. However I will try to comment
on a few parts.
> I guess as long as you're free to define "in some sense" any way you
> want, (I.e. requiring the result you say you want) then your statement
> becomes a meaningless tautology. Otherwise, it's basically just
> false. e.g. Huffman has been proven to be "maximal in some sense",
> but the effect you claim simply doesn't happen. Taking random garbage
> and trying to run it through David's decompression algorithm does what
> I said before: it produces individual letters with roughly plausible
> frequencies, but is easily distinguishable from normal text as soon as
> you look at digraphs, trigraph, and so on.
>
What you fail to understand is this is not encryption. It
is the use of compression so as to not add information to a file.
The main reason to use this compression is so that it does not
add information to a file as other compression methods currently
do.
Also the socalled methods that do compress better will most likely
have 1-1 equivalents when compression writters get the concept.
Matt Timmermans got it to work for arithmetic and I have various
RLE version as well as the Huffman ones. It is only a question of
time before 1-1 compression routinces will be the norm for those
wishing to do compression before encryption. I hope you some day
have A high enough IQ to realize that fact.
> At the same time, a 1-1 compressor CAN allow easy and systematic
> rejection of keys: using David Scott's compressor as an example, even
> though every input is theoretically legal, decompressing from most
> produces output that's _easily_ distinguishable from normal text.
Actaully this is somewhat true. If you use my condtional
compressor even on a short file. Most of the text that comes
back when a wrong key is used is unreadable. Assuming that a
readable text was encrypted. However there still are many valid
messages. But if you used non 1-1 compression it is highly likely
that the only message that decompresses properly is the one that
was encrypted. Also if you not sure of the type of file encrypted
the non 1-1 compression may still only lead to one file even if
that file is random. But if my compression used there is no one
to tell what the input file was withe other information
--
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/
Before you buy.
------------------------------
From: No Brainer <[EMAIL PROTECTED]>
Subject: Re: Guaranteed Public Key Exchanges
Date: Sun, 13 Feb 2000 23:49:25 +0800
Mike,
On Thu, 10 Feb 2000 12:17:10 -0600, Mike Rosing <[EMAIL PROTECTED]>
wrote:
<snip>
> In one thread you asked how to do it securely. One out of band method
> is a newspaper. Take out an ad in the classfied section an just publish
> the ascii text of your public key. It's easy enough for anyone to check
> that.
<snip>
> It's also just one way. You don't know who's going to link to you, all
> you know is that they know they've got a link to you!
>
Ok, I see your point...it can be tricky.
I know this may be digressing, however:
If I know the e-mail address of a contact and I also know the URL of a server
that contained his public key (encapsulated in an X509.3 signed executable
perhaps?) is there a 100% way of connecting to that site and successfully
downloading the signed executable for extraction of the public key?
Or is that opening up another can of worms? :)
------------------------------
From: No Brainer <[EMAIL PROTECTED]>
Subject: Re: Guaranteed Public Key Exchanges
Date: Sun, 13 Feb 2000 23:58:21 +0800
Darren,
On Thu, 10 Feb 2000 21:28:04 GMT, Darren New <[EMAIL PROTECTED]> wrote:
> Dan Day wrote:
> > In a case like that, the "man-in-the-middle" is the *least* of your
> problems -- the guy at the other end of your
> > email traffic might *himself* be an enemy disguising himself as a friend.
>
> Right. My point is that even if I'm standing face-to-face with you, and you
> have your public key on a floppy in your hand, how do you know you're giving
> it to the right person? Your question as originally phrased is meaningless -
> that you know nothing about the person you're trying to exchange keys with.
> What you *do* know about the person is what you have to lever to get a
> secure exchange. If you know nothing, then you have no reason to even talk
> to that person in plaintext let alone via cyphers.
OK Guys, now you're really being paranoid :)
I see your point though...all I want to do is exchange public keys over the
Internet...that can't be too hard could it?
Let's assume that the e-mail address I have in my hand is the right contact
point for the person (whom I may have or may have not seen). I posted to Mike
earlier and asked the Q:
If I know the e-mail address of a contact and I also know the URL of a web site,
how could I successfully download the contacts public key (would I download a
sX509.3 signed executable and extract for the key?)?
Surely there may be some way to download software so that when you receive it
you know it hasn't been "modified"?
TIA.
------------------------------
** 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
******************************
