Cryptography-Digest Digest #115, Volume #9 Sun, 21 Feb 99 04:13:07 EST
Contents:
Re: True Randomness (Michael Sierchio)
Re: security? (Ben McGinnes)
Current SSZ mailing lists (Jim Choate)
Another extension to CipherSaber (Anonymous)
A place like the ones the oil FAQ warn about ... ([EMAIL PROTECTED])
Re: Snake Oil (from the Feb 99 Crypto-Gram) (Mark Andreas)
--- sci.crypt charter: read before you post (weekly notice) (D. J. Bernstein)
Re: True Randomness ("Douglas A. Gwyn")
Bigger variables... ("D")
Re: Standard fileheaders for encrypted files (wtshaw)
Unicity of English, was Re: New high-security 56-bit DES: Less-DES
([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Subject: Re: True Randomness
Date: Sat, 20 Feb 1999 16:35:12 -0800
Reply-To: [EMAIL PROTECTED]
"Douglas A. Gwyn" wrote:
>
> "R. Knauer" wrote:
> > Yet a true random number by definition is one which has NO regularity
> > of any kind.
>
> Thus *your* notion about what constitutes a "true random number"
> is a meaningless "floating abstraction".
That's a little harsh. There are problems with the semantics of
"true" and "random" (and apparently forms of the verb "to be" for
certain public figures). But the assertion
> Randomness is not a property of individual numbers anyway.
is false.
It depends on the definition of randomness. ONE definition is
that a number n (represented by a finite bit-string) is "random"
if it is incompressible -- if there is no binary representation of n
shorter than floor(lg(n+1)). This is probably what Knauer means
when he says that it has no regularity.
For the purposes of crypto -- OTP or the generation of keys -- I
will attempt once more to articulate what I believe to be the
requirements for a random number generator:
Consider a random bit generator G to be the source of a one-way
infinite sequence of bits b[0] b[1] .. . We would like the sequence to have
the following properties:
1) the behavior of G leads us to expect that all finite strings of
length n will occur with equal probability (this is a fairly
strong requirement that will make G pass all of the FIPS-140
statistical tests, for example);
2) no finite string (subsequence) b[k] b[k+1] .. b[k+n] of the
one-way infinite sequence is of any value in predicting b[k+n+1]
(this requirement eliminates linear and polynomial congruential
generators and other algorithmic methods);
3) nothing about the externally-observable behavior of G (e.g.
consumption of system resources and time) will leak any
information about the output of G.
------------------------------
From: [EMAIL PROTECTED] (Ben McGinnes)
Subject: Re: security?
Date: Mon, 15 Feb 1999 16:58:51 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
On 15 Feb 1999 04:54:54 GMT, David A Molnar <[EMAIL PROTECTED]>
wrote:
>John Doe <[EMAIL PROTECTED]> wrote:
>> What is the most secure encryption scheme as viewed by you? OTP's are
>> excluded. Also.. 3DES is not included.. So with the exception of
those..?
>Define "secure".
Security is a state of mind, a feeling. One feels secure (or
insecure)
about thing or situation.
Regards,
Ben
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use
<http://www.pgpi.com>
iQA/AwUBNsfFnTcaxb+gSuMTEQItIwCgoFnyEhfc8mBglvPQbayIcMTowYUAoPLo
utwsPe6DYde3wZB0ePTGKgy3
=Nfco
=====END PGP SIGNATURE=====
"God created Arruckus to irritate humanity." -- _Doon_ by Ellis Weiner
=======================================================================
Benjamin D. McGinnes E-mail : [EMAIL PROTECTED]
web site : http://www.alphalink.com.au/~benmcg/intro.htm
PGP public keys at : http://www.alphalink.com.au/~benmcg/pgp-keys.htm
PGP DH/DSS ID : 0xA04AE313 PGP RSA ID : 0xA4E8732D
------------------------------
From: [EMAIL PROTECTED] (Jim Choate)
Subject: Current SSZ mailing lists
Date: 21 Feb 99 00:11:54 GMT
Welcome to the Austin Perl Mongers ([EMAIL PROTECTED])
This mailing list is for the discussion and propogation of Perl as a
programming language. The Austin Perl Mongers have monthly meetings which
are announced on the mailing list.
If you have questions about APM please contact [EMAIL PROTECTED]
If you have problems with apm.ssz.com contact [EMAIL PROTECTED]
Welcome!
-----------------------------------------------------------------------------
Welcome to the Cliology mailing list ([EMAIL PROTECTED]).
Cliology is the study of history and civilizations with the goal of
understanding them from an analytical and predictive perspective. The idea
is that societies and human history have patterns that are mediated and
resultant from human psychology, situational boundary conditions, and
physical laws of nature.
This field is very lightly studied because of the broad range of fields of
study it requires. It is only now becoming possible to collect the necessary
historical data, current data, and computational power to approach even the
most simple problems.
Should you have any problems or questions please contact [EMAIL PROTECTED]
Welcome!
-----------------------------------------------------------------------------
Welcome to Conflict Simulation of Austin ([EMAIL PROTECTED])
This mailing list is for the discussion of wargames, rpg's, and other games
related to conflict simulations. It is open to all. We ask that all comments
of a personal or flame-bait nature be avoided.
If you have any questions or problems please contact [EMAIL PROTECTED]
Enjoy yourself!
-----------------------------------------------------------------------------
Welcome to the Cypherpunks Distributed Remailer ([EMAIL PROTECTED])
The Cypherpunks mailing list discusses cryptography, economics, civil
liberties and related topics. The discussion can range over a very large
area and many off-topic posts are submitted. The mailing list itself
consists of 7 hub repeaters, any of which a potential user can subscribe
to. The mailing list has an international user base and has been in
existance approximately 7 years.
If you have any problems please contact [EMAIL PROTECTED]
Welcome!
-----------------------------------------------------------------------------
Welcom to the Science - Technology mailing list ([EMAIL PROTECTED]).
This mailing list is for the dissimenation and discussion of science and
technology. It consists of original dialog as well as on-topic forwards
from other sources. Discussion of UFO's, Zero-Point Energy, etc. will be
met with the standard conservative views of traditional science. We may
have an open mind, but it's not so open we're going to let it slosh out
on the floor. Participation in this mailing list is open to all but it is
important to recognize that many topics and devices are very dangerous to
deal with and we seldom discuss the specific safety precautions necessary
to insure no harm to participants. The range of topics is very wide and as
a result it is probably not appropriate for children without direct and
immediate parental supervision.
This is a hard science and technology focused list. The social, political,
cultural, and economic impact of technology should NOT be discussed here. If
you wish to delve into those topics please consider subscribing to the
Cliology mailing list ([EMAIL PROTECTED]).
Experimental Science Instrumentation ([EMAIL PROTECTED]), Amateur & Experimental
Rocketry ([EMAIL PROTECTED]), Advanced Computer Experimentation ([EMAIL PROTECTED]),
and the Data Haven ([EMAIL PROTECTED]) mailing lists have been replaced by this
mailing list. Discussion and support of actual experiments and projects is
strongly supported. Subscribers to these lists were NOT automaticaly
subscribed to this mailing list because of the change in topics.
We do NOT provide answers for homework assignments, though we will help in
providing discussion and references.
Personal comments and flame-bait submissions are strongly frowned upon.
If you have problems please contact [EMAIL PROTECTED]
Welcome!
--
The Armadillo Group James Choate
SOHO & Internet Consulting and Technical Support 512-451-7087
Linux - Unix - Microsoft - Plan 9 - BeOS - Amiga [EMAIL PROTECTED]
Cypherpunks - Cliology - ConSim - Rocketry - Robotics www.ssz.com
------------------------------
From: Anonymous <[EMAIL PROTECTED]>
Subject: Another extension to CipherSaber
Date: Sun, 21 Feb 1999 05:28:21 +0100
In December 1998 I built myself a CipherSaber-1 program as per the specs
on the CipherSaber site (http://ciphersaber.gurus.com). One of the
suggested non-standard improvements on that website was to add a variable
number of mixing rounds in the RC4 key initialization phase, so I threw
this in as an option.
Another improvement I implemented consists of a second number, which I
call the "discard count." It is a 32-bit value that specifies how many
cipher bytes to discard before beginning to encipher/decipher. I suppose
this number is a "key" of sorts as well. It would seem to make the
searchable keyspace larger by a factor of 2^32, assuming you were choosing
"discard counts" that used the full span from 0 to 2^32-1.
Intuitively I cannot see that this weakens CipherSaber in any way.
Comments? Thoughts?
K
------------------------------
From: [EMAIL PROTECTED]
Subject: A place like the ones the oil FAQ warn about ...
Date: Sun, 21 Feb 1999 02:09:06 GMT
Visit this adress for a quick laugh.
http://www.montana.com/rmrc/padhole.htm
In it you will find misinformation about OTP and a little bit of paranoia.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Mark Andreas <[EMAIL PROTECTED]>
Subject: Re: Snake Oil (from the Feb 99 Crypto-Gram)
Date: Sat, 20 Feb 1999 23:24:01 -0600
Bruce Schneier wrote:
> Some companies claim "military-grade" security. This is a meaningless
> term. There's no such standard. And at least in the U.S., military
> cryptography is not available for non-government purposes (although
> government contractors can get it for classified contracts).
The first time I remember seeing this phrase was when using the
command-line version of PGP 2.6 using the -kg switch to generate a key.
Choice #3 was:
3) 1024 bits- "Military" grade, slow, highest security
--
=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/=/
Mark Andreas <[EMAIL PROTECTED]> http://www.sky.net/~voyageur
PGP key 77EF76B1 available via key server, finger or webpage
=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Crossposted-To: talk.politics.crypto
Subject: --- sci.crypt charter: read before you post (weekly notice)
Date: 21 Feb 1999 06:00:35 GMT
sci.crypt Different methods of data en/decryption.
sci.crypt.research Cryptography, cryptanalysis, and related issues.
talk.politics.crypto The relation between cryptography and government.
The Cryptography FAQ is posted to sci.crypt and talk.politics.crypto
every three weeks. You should read it before posting to either group.
A common myth is that sci.crypt is USENET's catch-all crypto newsgroup.
It is not. It is reserved for discussion of the _science_ of cryptology,
including cryptography, cryptanalysis, and related topics such as
one-way hash functions.
Use talk.politics.crypto for the _politics_ of cryptography, including
Clipper, Digital Telephony, NSA, RSADSI, the distribution of RC4, and
export controls.
What if you want to post an article which is neither pure science nor
pure politics? Go for talk.politics.crypto. Political discussions are
naturally free-ranging, and can easily include scientific articles. But
sci.crypt is much more limited: it has no room for politics.
It's appropriate to post (or at least cross-post) Clipper discussions to
alt.privacy.clipper, which should become talk.politics.crypto.clipper at
some point.
There are now several PGP newsgroups. Try comp.security.pgp.resources if
you want to find PGP, c.s.pgp.tech if you want to set it up and use it,
and c.s.pgp.discuss for other PGP-related questions.
Questions about microfilm and smuggling and other non-cryptographic
``spy stuff'' don't belong in sci.crypt. Try alt.security.
Other relevant newsgroups: misc.legal.computing, comp.org.eff.talk,
comp.org.cpsr.talk, alt.politics.org.nsa, comp.patents, sci.math,
comp.compression, comp.security.misc.
Here's the sci.crypt.research charter: ``The discussion of cryptography,
cryptanalysis, and related issues, in a more civilised environment than
is currently provided by sci.crypt.'' If you want to submit something to
the moderators, try [EMAIL PROTECTED]
---Dan
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: True Randomness
Date: Sat, 20 Feb 1999 23:02:05 GMT
karl malbrain wrote:
> I'm a little rusty after 30 years, but wasn't EISENBERG's point that
> <<perfect>> results are absolutely/completely distorted??? Karl M
Werner Heisenberg's point to which you presumably are referring
was that some pairs of quantum operators (notably, "complementary"
observations) do not commute, thus the corresponding observations
interact. If one of a complementary pair of observables has its
value "nailed down" very precisely, its complement's value has a
very broad probability distribution. This is the same phenomenon
as in Fourier transforms (not surprisingly, when you look at the
mathematics), wherein localization of a pulse in time gives it a
broad frequency spectrum and vice versa.
------------------------------
From: "D" <[EMAIL PROTECTED]>
Subject: Bigger variables...
Date: Sat, 20 Feb 1999 19:06:05 -0500
I think that if very secure encryption is necissary, it is simply a
matter of adding enough key variables. I believe that it is possible to
describe whole algorithms with keys in some kind of programming language
thingy. This language would create a variable cipher. This variable cipher
could be implemented in small operations such as xors, modular
multiplications, additions, moving bits around, etc. The operations could
be numbered and indexed. The cipher would require a running keystream and
would relate to the indicies on the operations, preforming them on the
current block.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: talk.politics.crypto
Subject: Re: Standard fileheaders for encrypted files
Date: Sun, 21 Feb 1999 00:45:48 -0600
In article <7an45j$[EMAIL PROTECTED]>, "Jay" <[EMAIL PROTECTED]> wrote:
> Kiril Kesarev wrote in message <[EMAIL PROTECTED]>...
> >Is there any standardized fileformat for encrypted files which
> >indicates whether the file is encrypted? The standard I am looking
> >for should not be application-specific, but an official government
> >standard.
> >
> >The reason for the above question is that exportable crypto should
> >not be easily modifiable to support longer keys. This implies that
> >multiple encryption must be blocked. The problem is that if I write
> >exportable software which blocks multiple encryption, the blocking
> >does not extend to other encryption software. An encrypted file can
> >be encrypted a second and third time with other programs.
> >
> Why on earth are you adding restrictions to yourself?? I have never heard of
> a case where the gov required this, why are you trying to add it?
>
> There is no such standard (thankfully) and hopefully will never be. Even if
> there were, a user need only do a simple XOR or similar operation to hide
> the header, to be reversed at decrypt time. This is, of course one of the
> unworkable problems that is not discussed in the 'crypto limits' crowd,
> but, hell, that's their problem, not mine.
>
You are both partially right; funny isn't it? The government mandates do
not make sense: It is not problem to edit out headers, specific
application used or something like a word processor; for the later, it
helps if characters are screenable, prefer lower ascii.
And, it is easy enough to use false headers to hide the true algorithm
behind the ciphertext, even make MIME look first glance like PGP, etc.
Those in government who do these things dream of the good old days just a
bit too much, so much that reality is not appropriately considered, just
that they want what they want, and imagine that that is sufficient, which
it isn't. Standard, there is no standard except what might be currently
used to prod you about.
--
A much too common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
From: [EMAIL PROTECTED]
Subject: Unicity of English, was Re: New high-security 56-bit DES: Less-DES
Date: Sun, 21 Feb 1999 04:13:25 GMT
In article <[EMAIL PROTECTED]>,
Bryan Olson <[EMAIL PROTECTED]> wrote once:
> > |The unicity distance of English without any key is zero.
which I disagreed with and pointed out that such result would make us all
telepaths as we would have to receive zero letters in order to uniquely know
any messages -- at least in English ;-)
As I commented, Shannon provided a value for English without any encipherment
-- and, it is not zero as He already declared :-)
But, since Bryan requested help to find this passage, in his good-natured way:
> Granted, I cannot find it. Give me a citation and win the point.
I will present it here, with a new subject as above. In a nutshell: English
unicity is certainly not zero, as given in Shannon's Table I, first line,
first column, but some comments may be helpful to see other aspects of it --
also correcting a misprint in Shannon's paper.
First, I note that Shannon uses an English alphabet with 26 letters, all
upper-case. This was entirely justified in those days and he thus considered
the alphabet so limited and number-coded from A=0 to Z=25. This information
was also known to the attacker. For a printable ASCII alphabet of 95 one
should expect different results -- but not much since the language's
redundancy is approximately the same either way.
In page 684 [Sha49, page 684 scanned at
http://www3.edgenet.net/dcowley/shannon/shannon15.jpg], Table I lists the
English word segment "CREAS" with a list of a posteriori probabilities for
1-letter, 2-letter, etc. when a simple substitution cipher (Caesar type) is
used.
Let me analyze only the first line of that table given by Shannon -- which is
in pure English, as we need. In this case, key equivocation is exactly zero
since I *know* the key: A --> A, B--> B, .... Z --> Z, which is simply "no
substitution".
Thus, we (the attacker) know the key (no substitution), know the message is
in English and know that we only receive upper-case letters A-Z. Now, we
intercept the letter "C". Do we know what to expect for that English message
-- *after* that letter? Can we at least say what we can expect for the
message block which includes that "C", such as which word it probably is?
No. The English word that includes that "C" can be almost anything in English
as it may even begin within a word. Thus, we cannot yet define what the
message block is *after* that letter, even though key equivocation is zero.
Unicity has not been reached for just one letter, not even for one a word
block, in a pure English message. BTW, this further shows why unicity cannot
defined by the condition of "zero key equivocation" alone -- here, we have
zero key equivocation for one intercepted letter but not zero message
equivocation and thus no unicity.
To be quantitative, what is the message equivocation (nowadays, conditional
entropy) of the yet unknown message *after* we intercept "C"? The conditional
entropy of the message M given the intercepted E is *mistakenly* given by
Shannnon in his 1949 paper cited above but can be corrected by reading his
1948 paper on Communication Theory [Sha48, see
http://cm.bell-labs.com/cm/ms/what/shannonday/paper.html] and so recuperated
from that later obvious misprint:
H(M|En) = SUM_over_e,m [ P(e,m)*log2(1/P(m|e)) ], where the sum is done over
all possible messages "m" and a set of a priori intercepted "e" of length "n"
at most, and:
H(M|En) is the conditional message entropy given En, where "En" is the a
priori set of intercepted "e" of length at most "n",
P(e,m) is the joint probability of e and m, and
P(m|e) is the conditional (ie, a posteriori) probability of m given e.
Now, let me apply this corrected formula and Shannon's data, asking for the
conditional entropy of a generic English message that begins with "C" -- by
considering a special case of a Caesar cipher with the known key: "no
substitution".
As Shannon writes in *the case* of a Caesar cipher: "For one intercepted
letter the a posteriori probabilities are equal to the a priori probabilities
for letters [ref. 10, for English messages]". He then gives the a priori
probability of the letter "C" in any English message of 26 letters to be
P("C") = 0.028, in the first line of his Table I.
Thus, since we know the key we are using ("no substitution"), so that "C" -->
"C" and all possible messages must begin with a "C", we can immediately write:
SUM_over_m [ P("C",m) ] = 1,
where the sum is over all possible messages. Further, with P(m|"C") = P("C")
for one intercepted letter "C", we can write:
H(M,"C")= SUM_over_m [ P("C",m) ]*log2(1/P("C")) = log2(1/0.028) ~ 5 bit
So, the equivocation of English with a 26 letter alphabet is 5 bit when the
first intercepted letter is "C". This result follows directly from Shannon's
data in Table I and shows that the unicity of English is certainly higher
than 1 letter -- even when key equivocation is zero. Which is BTW a pretty
obvious result but shows that the unicity formalism does not lead to
absurdities even for the extreme case of zero key equivocation.
I guess I can stop the reply right here -- since the answer is already given
as directly provided by Shannon in that paper, Table I: the unicity of pure
English is higher than one letter and certainly NOT zero.
But, let me open another can of worms ;-)...leveraging on the above
exposition.
What is the unicity of an English message? In other words, when do we expect
to reach unicity for a generic English message, so that given "n" intercepted
letters of English we know what to expect *afterwards* with high probability?
Of course, this question only makes sense within a given history statistics
-- if we have just unigram (one letter) frequencies then we cannot hope to
derive digram behavior and so on. In his paper Shannon used trigram
frequencies and estimated 4-gram and 5-gram frequencies. However, could one
obtain a unique solution or at least a near-unique solution to a generic
English text using only such statistical information? How many letters do we
need to render an English message identifiable -- say, at least within a word
block? Or, for some set of tentative words?
Following up on Shannon's Table I first line (English), whe can see that the
equivocation decreases for two intercepted letters "CR" and so on, until the
last case of his Table -- in the last column, for 5 letters. As we can see,
the a posteriori probability is 1 for this 5-letter case -- while it is
smaller than 1 for the 4-letter case. The five-letter case is thus uniquely
identified in the case considered -- ie, among those options that were
considered possible.
NOTE: Even though Shannon's normalization units in Table I are different than
the one we need to consider here, the values for the *first* and *last*
columns can be used as given in his paper. And, since the a posteriori
probability must be a non-decreasing function of message length, it cannot
decrease after it is unity.
Then, using Shannon's data, I may expect the unicity of a generic English
message to be around 5 letters at least word-wise -- ie, after 5 letters I
should be able to tell what English word **will be transmitted** even if the
word is longer and even if the intercepted message caught just part of that
unknown word (a practical case in cryptanalysis).
But, for 1 or 2 letters I expect the English language to still allow
considerable freedom word-wise.
For furher discussions, also considering other modes of unicity (ie, not just
unique detection but also ambiguous or obscure detection) pls see
http://www.mcg.org.br/unicity.htm#6
Last, sorry for the message length but I used the opportunity also to correct
that misprint in Shannon's paper -- unfortunately not the only one.
Cheers,
Ed Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
** 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
******************************
