Cryptography-Digest Digest #448, Volume #10 Mon, 25 Oct 99 19:13:04 EDT
Contents:
Re: Newly Encountered Crypto System (Paul Gover)
Re: some information theory (very long plus 72K attchmt) (SCOTT19U.ZIP_GUY)
Re: some information theory (very long plus 72K attchmt) (Anton Stiglic)
Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E ("Trevor Jackson, III")
Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E (Paul Koning)
Re: How to use CBC w/ RC4? (Tom St Denis)
Re: There could be *some* truth to it (Patrick Juola)
Zimmerman Telegram Question (John Savard)
Modern secret writing (Mok-Kong Shen)
Re: This compression argument must end now (Tim Tyler)
Re: Note on Feistel Ciphers ([EMAIL PROTECTED])
Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E (Tim Tyler)
----------------------------------------------------------------------------
From: Paul Gover <[EMAIL PROTECTED]>
Subject: Re: Newly Encountered Crypto System
Date: Mon, 25 Oct 1999 13:55:20 +0100
David A Molnar wrote:
> ...
> Right now this description does not make much sense. although for
> some reason it reminds me of Wittgenstein.
> ...
> > Cryptographers worldwide would concede that this encryption technique called
> > A.N.E.C, does not conform to the traditional practices, beliefs or standards
> > within the cryptographers profession and has an innovative idiosyncratic,
> > uncanny technique unlike any cryptosystem I have ever encountered.
> > ...
Does anyone else find that this description, with the lists of odd
adjectives applied to abstract nouns ("innovative idiosyncratic
uncanny technique") reads a bit like the sentences generated by those
random marketing phrase generators?
Perhaps I'm suffering a slight touch of paranoia :-)
Paul Gover
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: some information theory (very long plus 72K attchmt)
Date: Mon, 25 Oct 1999 14:05:35 GMT
In article <7v12ct$[EMAIL PROTECTED]>, "Mattias" <[EMAIL PROTECTED]>
wrote:
>Hi
>
>An alternative way to look on the question:
>
>Defs:
>E() - encode in the crypto
>D() - decode
>Comp() - compress
>DeComp() - decompress
>
>Now we add the additional definitions:
>E'(P) = E(Comp(P))
>D'(C) = DeComp(D(C))
>
>Clearly E',D' can be seen as defining a crypto in its
>own right. The question now reduces to
>"Is the crypto defined by E'&D' more secure
> than the one defined by E&D ?"
>
>Generally speaking (without knowing anything more
>about E,D,Comp,DeComp and the domain of the plaintext
>P) this is clearly impossible to answer. Especially since
>defining the security of a crypto in any formal sense
>is problematic at best.
>
>Could we agree on that the fact that E',D' as well as
>E,D is 1 to 1 (ie no information loss) is NOT enough
>to prove that the two cryptos are equally secure?
>
>Otherwise this argument would easily generalize to
>saying that ALL cryptos are equally secure which is
>clearly absurd (Right?).
>(This would include such "cryptos" as E=D=I where
>I is the identity function which is fairly easy to
>break).
>
>If we can agree on this then we can start the discussion
>in which cases E'&D' is a more secure crypto.
>
It is very hard to prove security but it is easer to show or
prove nonsecurity.
Since one could say that the size of a key shows security
all else being equal. To be more precise I mean the number
of mapping of P as a function of K. If a given system has
only 256 mapping possibilites then an 8 bit key would be
all that is needed. But if one dropped 128 such mappings
then the resulting system is weaker since identical and know
only a 7 bit key is needed.
The following is true for most of the E and D functions one deals
with but lets add the paramter K for the "key"
E(P) is now E(P,K) where the "key" used is added to notation
know for all crypto sytems D(E(P,K),K)=P for all K and hopefully
there is no K such that E(P,K)=E(P,K1) for all P where K and K1 different
the number of values for K in binary length give the key size.
"In the following the addons of random padding and such are dropped
to look at only the underlying crypto system."
For all crypto systems I am familar with D(E(P,K),K1)=O and
system E(O,K1) = E(P,K) when
P = O then you have a valid guess for that key. If the message is
small maybe more than one valuw of K1 gives P = O so lets assume
P large so that usually only one suck value can exist. One measure
of the strength would be the number of K1's that can be used to create
a O divided by the number that leads to the correct solution this is
usually the whole keyspace for a good crypto sysyem.
Know look at the modifed system
D'(E'(P,K),K1)=O this becomes
DeComp(D(,E(Comp(P),K)K1))=O But for this to be valid then
a valid DeComp() must
exist for K1 and E(Comp(O),K1) = E(Comp(P),K) or the K1 can
be exculded from the set of possible solutions.
IF there is a reduction in the number of valid possiblites for K1
then the compression used actually weakness the crypto system.
This is why most compression systems weaken a crypto process.
Note it is important to note that the messages have to be of suffucent
lenght or there could be many values of K1 that cause the desired
solution. I think most would agree that a one-to-one compression
where the compressed file is longer than the key size would be what
one is striving for.
Even though I show that bad compression can weaken a crypto
system. If the sytem is very bad to begin with such as ROT 13
any compression would help since the ROT 13 should be solveble
on sight while the compressed ROT 13 may be harder to notice.
But at least compress with out headers and the average person
will not easily break it.
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: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: some information theory (very long plus 72K attchmt)
Date: Mon, 25 Oct 1999 10:25:14 -0400
[EMAIL PROTECTED] wrote:
> Anton Stiglic ([EMAIL PROTECTED]) wrote:
> : so the result of you compression function will be random.
> : If you choose your text to be in {a,b,c,....,z, ..., <space>}^30
> : (b.t.w., by {0,1}^n, I mean the set of string bits *smaller or equal* to
> : n),
> : and you only pick text that make sens in english, then it is no longer
> : random.
>
> That is my point: if my compressor is perfect, the space is no longer the
> space of strings of letters, but the space of texts that make sense in
> English!
If your intial plaintext set if all strings of letters, and what you realy are
interested in is the subset of this set which contains only texts that make
sens in English, then my distinguishing algorithm works for not all
c will be such that DeComp(c) give a valid english text (since Comp
is bijective, DeComp is simply the inverse of Comp, and thus will give you
back some strings of letters that don't make sens in english), this is
how he could distinguish.
Anton
------------------------------
Date: Mon, 25 Oct 1999 12:37:49 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E
[EMAIL PROTECTED] wrote:
> They are looking for
> encryption that is many times more secure than anything they can crack
> themselves, so not being able to crack a code is not sufficient to prove
> it is adequately secure.
Interesting and very succinct statement. It probably applies to organizations
as well as individuals. The inequality re ability and desires reminds of eyes
bigger than stomach, and all the important projects that have failed due to
lack of unobtainium.
Perhaps this is the reason that crypto is so fertile in regards to
charlatans. People buy the promises.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E
Date: Mon, 25 Oct 1999 12:14:05 -0400
[EMAIL PROTECTED] wrote:
> ...
> But what people have criticized about Original Absolute Privacy is that,
> for various reasons, they feel they do not have adequate reasons to
> believe that it will genuinely securely encrypt their messages. (I
> understand that it may be frustrating to you that these reasons appear to
> be chiefly _ad hominem_ reasons rather than technical ones.)
I don't remember them that way. Or do you consider a statement
of the form "a system that uses a PRNG to generate a pseudo one
time pad and then claims this is good because of the strength
of (real) one time pad is snake oil" to be an ad hominem attack?
I would not. The fact that it comes across that way to snake
oil vendors doesn't change that.
paul
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: How to use CBC w/ RC4?
Date: Mon, 25 Oct 1999 18:05:55 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Trying to figure out how to use RC4 to encrypt multiple files, as on a
> directory of a hard drive, with a single password. If you mean use a
> different public IV to xor with the password to create the key to
> initialize RC4, then I understand. If you mean a different password
> for each file, then it would be a mess. The separate passwords would
> have to be stored together in a file, then encrypted with a human
> rememberable password.
>
You do this right KEY = HASH(PASSWORD)
Just change that to KEY[i] = HASH(PASSWORD + SALTi)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: There could be *some* truth to it
Date: 25 Oct 1999 14:04:34 -0400
In article <[EMAIL PROTECTED]>, Anton Stiglic <[EMAIL PROTECTED]> wrote:
>Tim Tyler wrote:
>
>> Anton Stiglic <[EMAIL PROTECTED]> wrote:
>> : Tim Tyler wrote:
>>
>> :> This is not true for the attack I described on quantum cryptography -
>> :> where an attacker always has a finite chance of getting the message,
>> :> *and* knowing they have decrypted it correctly.
>>
>> : In classical crypto, an attacker also always has a finite chance of getting
>> : the message? Your point is invalid.
>>
>> What are you talking about this time?
>>
>> "One time pads" are part of "classical cryptography". With such a
>> cypher, an eavsdropping attacker can guess the plaintext, they have no way
>> of knowing if they have guessed right.
>>
>> This is not the case with the problem with quantum cryptography where
>> there is a positive finite chance of an eavsdropper decoding the
>> message and knowing that they have done so correctly.
>>
>> Of course the systems are both vulnerable to non-eavsdropping attacks of
>> various kinds - but these are not under discussion here.
>
>Quantum crypto also uses the One-Time Pad, so what are *you* talking about?
Doesn't need to. You could, if you like, use quantum crypto to exchange
or generate a key and then use "conventional" key-based algorithms.
Which would likely be a much more efficient use of a very expensive
quantum channel.
-kitten
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Zimmerman Telegram Question
Date: Mon, 25 Oct 1999 20:16:26 GMT
We've all seen photographs of the coded version of the "Zimmerman
Telegram".
Barbara Tuchman's book even includes a group by group transcript of
the message.
However, I remember looking there recently, and noting that only the
version in code 13040 was thus transcribed.
There may have been a very short extract from the first version
intercepted, in a newer code the British had not cryptanalyzed as
fully, in David Kahn's book "The Codebreakers", but as far as I know,
the other version of the Zimmerman tlelegram has not appeared in full
anywhere.
Am I mistaken?
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Modern secret writing
Date: Mon, 25 Oct 1999 22:25:59 +0200
One natural method of secret communication that is known since
ancient time is to write in an extremely small area such that the
adversary barely notices. The technique is also known to have been
exploited in WWII. It is hence no big surprise, though nonetheless
very interesting, to know that one can now already write in
nanometer scale. In the article
S. Hong et al., Multiple Ink Nanolithography: Toward a
Multiple-Pen Nano-Plotter. Science 286 (1999) 523-525.
see also 389-391.
there is shown that one can write with strokes that are only
15 nm wide and that in a few colours. A paragraph of Feynman's
speech was written in an area just one-thousandth the size of a
pinhead.
I guess that the technique is yet fairly expensive. With time
the cost will certainly come down. Then crypto software manufacturers
will be able, I believe, to use that technique to export strong
crypto in very secure (because escaping from the eyes of the
competitors) and legal (because being in 'printed form') manner.
The bureaucrats wanting to suppress the same being exploited
by criminals would be forced to install sophisticated equipments
at all the customs and minutely examine every surface on materials
carried in the luggages of travellers at the resolution of
one-thousandth the size of a pinhead. I predict that this will
entail a big boom of the industry that manufactures such special
detecting equipments and that current crypto regulations and
the crypto clauses in the Wassenaar Arrangements probably have
to be proportinately tightened up in order to be effective at all.
M. K. Shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: This compression argument must end now
Reply-To: [EMAIL PROTECTED]
Date: Mon, 25 Oct 1999 20:18:39 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: Ok the argument does 'p = compress(decompress(p))' make cryptanalysis
: has gone on too long now.
If you don't like it, killfile the relevant threads.
I observe that this is not the first thread you've started in this forum
to spread your naive views on the subject around - so you're contributing
significantly to the compression/encryption arguments.
: First off lets review the argument. The argument is if the above is
: true it will be harder to tell if a decryption is valid (via brute
: force) because any decryption is 'valid'. Second that since all
: decryptions are valid guessing the decryption output (what it should
: be) is just as hard guessing the amount of actual bits of info contain
: therein (obviously upto the block size or whatever).
That is /one/ aspect of the argument.
I observe you have somehow failed to mention that the opponents get less
cyphertext to base their attacks on, and what they do get has had it's
entropy-per-bit increased to the point where cryptanalysis is made much
harder.
: My original counter-argument. There are too many possible ascii text
: blocks and the ciphers are too hard to attack (to exploit the nature of
: the input) in a practical sense. I.e you would have to break the
: cipher to tell what the decryption could be. There was no counter
: argument to this argument.
It is not a good argument against compression in the first place.
It doesn't even address the issues above. Cryptanalysis based on
regulariries in the file does not rely on brute forcing the
keyspace, nor on having the whole message decrypted. You've been told
this before - it makes me wonder if you're paying attention ;-(
: My second counter-argument. Most compression algorithms such as LZ77
: and Deflate (belongs to the LZ77 family) have no 'invalid' code words
: in the data stream. What does this mean? It means you cannot just
: look at a code and say it's invalid. No counter arguement provided.
What??? LZ77 is one-on-one? I very much doubt it. To see if a code
has resulted from an actual compression, simply decompress it and
compress it again. If you get a different file, you know that it has
not been made with the specified (deterministic) compression program. If
you /never/ get such a file, the compressor is "one-on-one".
LZ isn't one-on-one - there's obviously more than one way to encode the
same file. LZ compression works by crudely identifying repeated strings.
I believe XXXXXXXX can be represented both as 8 x X and 5 x X + 3 x X
as far as the decompressor is concerned. No way is this compression
"one-on-one".
: We all know who will never agree or dismiss the argument.
Yes, um, anyone with more than two brain cells?
I'm sorry, Tom, but I fail to see where you fail to understand the
security benefits of compressing before encryption. This sort of post
from you does not help me form a positive image of you as an intelligent
creature.
: However I would like to live and see a day where this is dropped.
Then why not start by abandoning your pointless, illogical crusade against
compression in cryptography?
: Please consider the facts, make up your own mind (I am not saying which is
: right or wrong) and stop posting about this.
Why? Since this is a public forum devoted to cryptography, this seems by
far the best place to discuss the issue.
David Scott has recently invented perhaps the first compressioon system
suitable for cryptography known to man. Since *all* other known
compression routines potentially weaken your encypherment - and add
"unnecessary" information to the file - I believe this event should not be
under-estimated.
At the moment we have very few "one-on-one" compressors. Those that are
available are not likely to be suitable for all types of data. This means
that some people who recognise the security benefits of compression are
unable to properly exploit its benefits for lack of a suitable compressor.
Note (sorry if I've said this too often) that the most efficient
compressors are - in theory - one-on-one. This is a kind of double-whammy
as far as cryptography goes. Not only do they add the minimum of
information to the file (that cryptanalysis can potentially exploit), but
also, this class of compression entirely contains the class of compression
routines which offer the analyst the smallest possible quantity of
cyphertext (for any given finite input set, anyway).
I would urge others who have any theoretical understanding of the design
of bijective compressors to enter into the current vacuum in the area and
make some sort of positive contribution to the new field, in order to
benefit themselves and others.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
295,408,296 - the cube of the Beast.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Note on Feistel Ciphers
Date: Mon, 25 Oct 1999 20:29:08 GMT
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
> : My point is that your concern, attacks that exploit
> : a separation between the halves in Feistel ciphers,
> : is of no concern at all. The separation is only in
> : the process of computation; it is known not to limit
> : the resulting dependencies.
>
> Not in theory. However, perhaps when someone designs a Feistel cipher,
> those designs that produce effects like arbitrary bit permutations are
> very complicated and hard to achieve, and so in the space of "simple"
> Feistel designs that people are likely to actually come up with, there
> might be weaknesses, and it might be easier to remedy them by a
technique
> such as Mr. Shen suggests than to eliminate them while still having a
> Feistel cipher.
The theory of "constant separation" was the only
motivation for the permutation in the first place.
We have zero practical evidence in favor of adding
the permutation and now some theory indicating
that problems fixable by permutations are not
characteristic of Feistel ciphers.
If "perhaps when" and "might be easier" are the
level of justification we're looking for, then we
should each be able to write a hundred posts a day
proposing adding some kind of operation to some
class of cipher.
> [...] real-world designs, being limited in their
> complexity, might still have weaknesses influenced
> by the basic structure chosen, and it might be
> easier to remedy that by varying the structure
> than by exploiting the full possibilities of the
> structure.
I think "The Case for Multiple Round Structures"
could be a fine paper. One might compose rounds
from the AES finalists and apply the attacks the
authors tried. I think it plausible that the
composition might defeat the attacks with notably
less computation than any of the originals, which
would be a terrific result.
I do not see value in "A Note on Feistel Ciphers"
that contains no particular understanding of
Feistel ciphers, nor in the practice of re-designing
Don Coppersmith's ciphers without reading Don
Coppersmith's papers.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Crossposted-To: talk.politics.crypto
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E
Reply-To: [EMAIL PROTECTED]
Date: Mon, 25 Oct 1999 20:46:07 GMT
In sci.crypt Paul Koning <[EMAIL PROTECTED]> wrote:
: [EMAIL PROTECTED] wrote:
:> But what people have criticized about Original Absolute Privacy is that,
:> for various reasons, they feel they do not have adequate reasons to
:> believe that it will genuinely securely encrypt their messages. (I
:> understand that it may be frustrating to you that these reasons appear to
:> be chiefly _ad hominem_ reasons rather than technical ones.)
: I don't remember them that way. Or do you consider a statement
: of the form "a system that uses a PRNG to generate a pseudo one
: time pad and then claims this is good because of the strength
: of (real) one time pad is snake oil" to be an ad hominem attack?
They don't *actually* come out and say that. The relevant text from their
front page is:
``OAP-L3: ORIGINAL ABSOLUTE PRIVACY - LEVEL3 Version 4.1 ) (patent pending)
may be the best encryption software available today.
They said it couldn't be done! Well, everyone knows that only messages
encrypted using one-time pads are unbreakable. At its heart, Original
Absolute Privacy - Level3 is an automated pseudo one-time pad
generator.''
So while they *associate* their product with OTPs and their security, they
don't quite out-and-out say "using a PRNG with a OTP is AOK".
They're asking for trouble by putting the work "Absolute" in an
encryption product - but hey, it's /just/ a name.
Incidentally for anyone with any doubts, using a *P*RNG with a OTP
*completely* destroys the unbreakable security of any resulting encryption
scheme. The result is exactly as secure as the PRNG employed.
It doesn't matter if you supply a thousand bit seed, if you're using
(say) an LCG as your RNG, the security of your messages is toast.
RNGs have - if anything - received less study than other types of
encryption. Have Ciphile Software even published their RNG's algorithm?
Of course there's no need for them to bother since their product "Uses no
mathematical equations so there are none of the associated security
risks!"
Perhaps they believe keeping it secret helps with security. Or perhaps
they don't want competitors copying their algorithm and springing up with
their own "Original Absolute Privacy".
Calling the result a "pseudo-OTP" is positively nauseating. It's a stream
cypher. Full stop.
It seems likely that those at Ciphile Software are simply extremely
deluded about cryptography, and are probably not actively trying to
deceive the public about the security of their cyphers. From their
usenet posts it appears that they genuinely have no understanding of
the issues involved, and actually believe their own inflated security
claims.
I imagine they /really/ thought using a PRNG was OK with OTPs for a while.
The alternative - that they understood the security problems and
associated their product with OTPs for marketing reasons - is unpalatable.
Of course, whether they're being very naive, or actively trying to
deceive a gullible public by marketing their product using inane
techno-bullshit - this is still an *extremely* good reason for
giving the products of Ciphile Software a wide berth.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
10 PRINT "Waiter, there's a bug in my LOOP" : GOTO 10.
------------------------------
** 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
******************************
