Cryptography-Digest Digest #861, Volume #8 Thu, 7 Jan 99 16:13:05 EST
Contents:
Re: On leaving the 56-bit key length limitation (Jim Felling)
Re: On the Generation of Pseudo-OTP (R. Knauer)
*** Position Available - Security Assurance Specialist *** (Ezzy Dabbish)
Re: Help: a logical difficulty (John Savard)
Re: Highly structured info. (XML) and decryption (wtshaw)
Re: What is left to invent? (Mok-Kong Shen)
Re: Cryptography FAQ (01/10: Overview) (Anthony Naggs)
Re: New Twofish Source Code Available (R. Knauer)
Re: On leaving the 56-bit key length limitation ([EMAIL PROTECTED])
*** Position Available - Secure Systems Architect *** (Ezzy Dabbish)
Re: On the Generation of Pseudo-OTP (R. Knauer)
----------------------------------------------------------------------------
Date: Thu, 07 Jan 1999 11:33:43 -0600
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: On leaving the 56-bit key length limitation
[EMAIL PROTECTED] wrote:
> Ed Gerck wrote:
> > Bryan Olson wrote:
> > > Ed Gerck wrote:
> > > > 1. First, I wish to point out that Theoretically-Secure Cryptographic
> > > > Systems (hereafter TSCS) do not depend on key-length for secrecy --
> > > > in their design region. In fact, Shannon already showed 50 years ago
> > > > that a TSCS does not depend on key-length when one works within the
> > > > system's "unicity distance".
> > >
> > > Staying within the unicity distance only ensures that
> > > more than one possible decryption exists. A cryptanalyst
> > > may still get large amounts of useful information.
> >
> > No, you are mistaken -- if you mean the plaintext (but, what else would you
> > mean?).
>
> I mean what I wrote. The information obtained from ciphertext
> is the reduction in equivocation of the plaintext. There's no
> rule requiring cryptanalysts to make no use of this information
> until the equivocation drops close to zero.
>
Another example if you are encrypting alphanumeric text then if one decryption is
'Dxc99OVq3 rzx$jP=W' and the other is 'Steal the plan now'. Both are valid decrypt
ions, but I'll bet that the analyst will discard the former posiblity and believe
that the message sent was 'Steal the plan now' Just because multiple decryptions
exist does not mean that they will be multiple ambiguous decryptions. In addition
even if there are such this still does not eliminate the possibility of a brute
force search revealing the proper message amidst the potential garbage messages.
Alpha text is especially bad as the odds of an ambiguous decryption being even
vaguely of the form of text is vanishingly small. This allows the analyst to
unambiguously reject all but a vanishingly small fraction of the ambiguous
decryptions.
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: On the Generation of Pseudo-OTP
Date: Thu, 07 Jan 1999 19:10:56 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 07 Jan 1999 18:00:11 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>An ideal OTP is totally secure but,
>as I said above, is unfortunately an unobtainable theoretical
>concept.
I disagree. A TRNG can be made to crypto-grade specifications in that
it would take more energy than exists in the Universe to break the
OTP.
>Thus, since exact proofs cannot be done, one has to resort
>to more or less heuristic arguments.
Quantum Mechanics is not hueristic.
>In the present case, if
>n texts are used to construct a psudo-OTP using an adequate
>combination of the techniques such as those I mentioned, then it is
>intuitively quite clear (though NOT a rigorous proof) that, as n
>becomes larger, the sequence obtained should be increasingly harder
>for the analyst to infer.
Famous last words.
The main question is whether the text stream outputs all possible
sequences of a given length equiprobably. Without that, all the
antiskewing and decorreleation in the world will not patch it up.
If for example you want to generate a pad with n bits, then the text
stream generator must be capable of outputting all 2^n sequences
equiprobably. If for some reason the output of a major fraction of
those sequences is not possible due to some inherent limitation on
natural language, then the text stream generator is unsuitable as a
TRNG substitute.
BTW, I assume you would use the LSB of the ACSII characters from the
text source and then remove bias and correlation from that preliminary
sequence. If you use higher order bits then you are gonna have real
problems because now you are getting closer to the patterns inherent
in natural language.
Why not just use music instead. Rap music should be completely random,
even to higher order bits.
Bob Knauer
"The American Republic will endure, until politicians realize they
can bribe the people with their own money."
--Alexis de Tocqueville
------------------------------
From: Ezzy Dabbish <[EMAIL PROTECTED]>
Subject: *** Position Available - Security Assurance Specialist ***
Date: Thu, 07 Jan 1999 12:45:48 -0600
*** Position Available - Security Assurance Specialist ***
Motorola's Chicago Corporate Research Laboratories in Schaumburg,
Illinois, is seeking an individual to participate in the specification,
design, and development of secure communication systems.
Responsibilities: Perform design, analysis, simulation and
prototyping of secure circuits and communication systems.
Develop and implement secure communication protocols. Participate
in the design and development process in key areas such as:
Smart Card Systems Security, Electronic Commerce, Internet Security,
Secure email, Secure Multimedia Communications..etc.
Requirements: BSEE or BSCE or BSCS or equivalent is required;
an MS or PhD degree is a plus. Educational background must provide
a strong foundation in engineering, advanced math and computer
courses. A minimum of two years experience in some of the following
areas
is required: Vulnerability assessment of secure products and systems,
security assurance methodology, Public Key Crypto Systems,
Elliptic Curve Cryptography, circuit design, system design,
computer simulation, security protocol development.
Applicant should be interested in secure system design and development.
This includes dealing with system level design issues as well as small
details of the design process. Knowledge of c or c++ and assembly
language
programming preferred.
MUST be US citizen or Permanent Resident.
The search will continue until the position is filled, but first
consideration will be given to resumes received by February 15, 1999.
The reference number for this position, SCI10278, should be included in
any correspondence. Please send resume and cover letter to:
Ezzy Dabbish
Motorola, Inc.
IL02/2712
1303 E. Algonquin Road
Schaumburg, IL 60196
Fax: (847) 576-8378
Motorola is an equal opportunity/affirmative action employer. We
welcome and encourage diversity in our workforce.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: sci.math
Subject: Re: Help: a logical difficulty
Date: Thu, 07 Jan 1999 19:26:19 GMT
Mark Ingram <[EMAIL PROTECTED]> wrote, in part:
>This is waaaaay off topic, but I could not resist, and [EMAIL PROTECTED] is not
>accepting my mail ...
>Nicol So wrote:
>> On the other hand, a finite binary string can be interpreted as encoding a
>> natural number. If we order all finite binary strings in lexicographical
>> (dictionary) order, we can interpret the i-th string as encoding the integer i.
>> It is easy to see that the set of all finite binary strings has the same
>> cardinality as the set of natural numbers.
>Dictionary order, you say. So '0' comes before '00', which comes before '000', ...
>. What integer does the string '1' encode in this ordering?
>I think that this has just shown that the set of all finite strings of '0's has the
>same cardinality as the set of natural numbers. Proving your claim, while of course
>possible, is actually a leetle bit trickier -- and I would respectfully suggest that
>lexicographic ordering is NOT what you want to use.
>I've cross-posted this to sci.math, not that that is going to make you crypto dudes
>any happier ...
>Anyways, thanks for your time,
It is trivially obvious that the set of all finite binary strings has
the same cardinality as the set of integers. You are correct that
lexicographic ordering will produce a different "order class" for that
set - one which, in the ordinary view, doesn't make much sense, since
it contains ellipses within it. (So the "sequence" doesn't exist, but
the set still does...)
One ordering that will give the proof nicely is to order first by
length, and then lexicographically within each length: e.g.:
0 : the null string
1 : 0
2 : 1
3 : 00
4 : 01
5 : 10
6 : 11
7 : 000
8 : 001
9 : 010
et cetera
This ordering can be produced by slapping a 1 in front of your
message, interpreting the result as a number, and subtracting 1 from
it.
In fact, this sort of technique is even used in cryptography ... for
example, look at the way SHA-1 and other techniques pad messages so
they occupy an integral number of blocks.
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Highly structured info. (XML) and decryption
Date: Thu, 07 Jan 1999 11:20:11 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
....
>
> I guess that you mean that the presence of much structures would
> render an algorithm weaker than when applied to normal messages.
> I believe that a simple scrambling, e.g. blockwise permutation,
> applied before the algorithm suffices to destroy such structures
> and thus renders such concerns unnecessary. A good encryption
> algorithm shouldn't however be affected by the presence of such
> structures in any significant way.
>
One could look on redundant headings as simply known plaintext, so an
algorithm that cannot withstand known plaintext attack is simply out of
the picture.
--
If government can make someone answer a question as they want him to, they can make
him lie, then, punish him for not telling the truth. Such an outrage constitutes
entrapment.
In Base 81: y\7RBRNBN 6*1O+aDR* QBOMR1OhE \*/XtS4+~ ;g/4,Y=Jn 6)IL;OC;H o93bR?bk\
v+/G(J=lE Ni@8L*x)I L(!\+O6;E Hu~u;Ho;R 9lX=g3x*n :Y(Yce;w~ 3l(9kS;NT YfmnPX=ya
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: What is left to invent?
Date: Thu, 07 Jan 1999 19:00:43 +0100
R. Knauer wrote:
>
> What is wrong with using a key of length greater than 56 bits that
> changes each day, one that is constructed from items published world
> wide such as daily closing market averages?
>
> A few least significant bits from the DJIA, the S&P, currencies, etc,
> plus the use of a hash algorithm should give you a nifty random key
> for today's encryptions (or yesterday's to make sure all the numbers
> have been propogated worldwide).
I believe that there are indeed an almost infinite number of
ingeneous ways to devise session keys that are changed as often
as needed and that are safe from prediction by the analyst. The
56-bit restriction then doesn't hurt very much since the message
length encrypted by a particular key is small. Perhaps one
should not follow 'standard' (commonly known) ways of generating
keys but better use one's own 'invention'.
M. K. Shen
------------------------------
From: Anthony Naggs <[EMAIL PROTECTED]>
Subject: Re: Cryptography FAQ (01/10: Overview)
Date: Thu, 7 Jan 1999 17:57:36 +0000
[Sorry for the late reply, I still have a glut of unread news from being
away at Christmas.]
After much consideration John Savard decided to share these wise words:
>[EMAIL PROTECTED] (Bruce Schneier) wrote, in part:
>
>>This FAQ is over four years old.
>
>>It seems reasonable to update it. Is there a cabal in charge of the
>>FAQ, or has it been orphaned? Is anyone interested in working on an
>>update?
Orphaned, it appears.
>It occurs to me that since "[EMAIL PROTECTED]" is not only
>identified in the text of the FAQ as the E-mail address of its editor,
>to whom comments should be directed, but it is _also_ the E-mail
>address by which the FAQ is posted, it can't have been *truly*
>abandoned.
It is auto-posted from MIT, as is the FAQ I maintain for another group.
The "[EMAIL PROTECTED]" email address was no doubt setup at
some point to collect FAQ feedback on behalf of "The Crypt Cabal".
So far as I can see there is no copyright message, though there is a
list of contributors:
:Many people have contributed to this FAQ. In alphabetical order:
:Eric Bach, Steve Bellovin, Dan Bernstein, Nelson Bolyard, Carl Ellison,
:Jim Gillogly, Mike Gleason, Doug Gwyn, Luke O'Connor, Tony Patti,
:William Setzer. We apologize for any omissions.
Anyone updating the FAQ will need the password used to submit it to
MIT's auto-poster. Even if the original compiler can be tracked down
they may well have forgotten the password by now. :-( Multi-part FAQs
are not fun to post manually, and the password is needed even to just
switch off the auto-poster.
I shall try to investigate this further ...
I may be able to help with getting a new FAQ (or supplement) through
approval for *.answers and fiddling with the auto-poster stuff. But I'm
not qualified to contribute much to the content.
Tony
--
BAD COMPUTER! That's my registry file you've trashed.
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: New Twofish Source Code Available
Date: Thu, 07 Jan 1999 18:06:22 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 07 Jan 1999 16:59:22 GMT, [EMAIL PROTECTED] wrote:
>> They might be if they are greater than 40 bits in length.
>Huh? You missed a smiley, right?
I usually don't do smileys. :-)
Especially when there is a double meaning intended. The second meaning
I intended has to do with the fact that the filespec could be seen as
a key that provides an encryption indirectly in the sense that the
file it points to contains an algorithm that is but one step removed
from an actual encryption itself - so in that sense the filespec is a
key for the resultant forbidden encryption.
Never mind - if you have to explain it, it loses something. :-(
Bob Knauer
"The American Republic will endure, until politicians realize they
can bribe the people with their own money."
--Alexis de Tocqueville
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: On leaving the 56-bit key length limitation
Date: Thu, 07 Jan 1999 19:58:26 GMT
In article <7719b8$qnt$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Ed Gerck wrote:
> > Bryan Olson wrote:
> > > Ed Gerck wrote:
> > > > 1. First, I wish to point out that Theoretically-Secure Cryptographic
> > > > Systems (hereafter TSCS) do not depend on key-length for secrecy --
> > > > in their design region. In fact, Shannon already showed 50 years ago
> > > > that a TSCS does not depend on key-length when one works within the
> > > > system's "unicity distance".
> > >
> > > Staying within the unicity distance only ensures that
> > > more than one possible decryption exists. A cryptanalyst
> > > may still get large amounts of useful information.
> >
> > No, you are mistaken -- if you mean the plaintext (but, what else would you
> > mean?).
>
> I mean what I wrote.
I note that you wrote:
"...unicity distance only ensures that more than one possible decryption
exists"
and, also:
"A cryptanalyst may still get large amounts of useful information."
BOTH are wrong. Since both comprise 100% of what you wrote first, you may also
wish to reconsider what you just wrote:
"I mean what I wrote."
As a side remark, when I first read your reply to my original message I
recalled how often I am still amused by the "hollier than thou" attitude I
can see on the Internet...the same feeling I had when I read another reply of
yours, also in this forum.
I say this because IMO, in a public debate by e-mail one should very seldom
declare that something is "wrong", since there are always so many
things the sender did not perhaps say and so many things I could not ask right
then. So, I seldom find myself in a position where I feel justified in all
fairness to say that something is "wrong" -- I will rather say "misleading",
"confusing", "obscure" or even "ambiguous".
So, please see my remark above -- when I affirmed that your declarations were
"BOTH wrong" -- as an exception, which I only use when the mistake is twice
confirmed. Please do not see it as a sign of unpolitedness or arrogance.
If you browse to http://www.mcg.org.br/uncity.txt you will see the new version
of the posting (list: thanks for all comments and also those in private) and
there you will be able to read what Shannon actually wrote, and my comments on
it:
|Shannon [Sha49] defined "unicity distance" (hereafter, "n") as the
|least amount of plaintext which could be uniquely deciphered from the
|corresponding ciphertext -- given unbounded resources by the
|attacker. The "amount" of plaintext (i.e., "n") can be measured in any
|units the user may find convenient, such as bits, bytes, letters,
|symbols, etc. Actually, Shannon used "letters" in his paper.
|
| NOTE: Please note that "unicity distance" is actually not a
| "distance". It is not a metric function and does not satisfy the
| intuitive properties we ascribe to distance. Thus, to reduce
| confusion, from now on I will only use the term "unicity".
|
|In few words, "unicity" is the least message length that can be
|uniquely deciphered. As we will see, this number depends on several
|factors -- some explicit, most implicit.
Thus, for the sake of dialogue, it might be better for you to get in synch
with Shannon before we talk about what I am revisiting in that exposition.
Before you do that, I better stop here since I have already exhausted my quota
of "wrongs" that civil rules of dicourse tell me should be employed in a
mutually profitable dialogue.
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck [EMAIL PROTECTED]
http://novaware.com.br
--- Meta-Certificate Group member -- http://www.mcg.org.br ---
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Ezzy Dabbish <[EMAIL PROTECTED]>
Subject: *** Position Available - Secure Systems Architect ***
Date: Thu, 07 Jan 1999 12:47:40 -0600
*** Position Available - Secure Systems Architect ***
Motorola's Chicago Corporate Research Laboratories in Schaumburg,
Illinois, is seeking an individual to lead and participate in the
specification, design, and development of secure communication systems.
Responsibilities: Lead and participate in the design, analysis,
simulation and prototyping of secure circuits and communication systems.
Develop and implement secure communication protocols. Lead and
participate
in the design and development process in key areas such as:
Smart Card Systems Security, Electronic Cash, Internet Security,
Secure e-mail, Secure Multimedia Communications..etc.
Requirements: BSEE or BSCE or BSCS or equivalent is required;
an MS or PhD degree is a plus. Educational background must provide
a strong foundation in engineering, advanced math and computer
courses. A minimum of 5-8 years of experience in some of the
following areas is required: Vulnerability assessment of secure
products and systems, security assurance methodology, Public Key
Crypto Systems, Elliptic Curve Cryptography, circuit design, system
design, computer simulation, security protocol development.
Applicant should be interested in secure system design and development.
This includes dealing with system level design issues as well as small
details of the design process. Knowledge of c or c++ and assembly
language
programming preferred.
MUST be US citizen or Permanent Resident.
The search will continue until the position is filled, but first
consideration will be given to resumes received by February 15, 1999.
The reference number for this position, SCI10277, should be included in
any correspondence. Please send resume and cover letter to:
Ezzy Dabbish
Motorola, Inc.
IL02/2712
1303 E. Algonquin Road
Schaumburg, IL 60196
Fax: (847) 576-8378
Motorola is an equal opportunity/affirmative action employer. We
welcome and encourage diversity in our workforce.
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: On the Generation of Pseudo-OTP
Date: Thu, 07 Jan 1999 18:58:04 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 07 Jan 1999 17:37:37 GMT, Darren New <[EMAIL PROTECTED]>
wrote:
>Heck, SGI (if I remember who properly)
Yes it is SGI, although I cannot find it anymore.
>even has a patent on using lava
>lamps to generate random numbers.
A patent? Hmm... Is that how our tax dollars are being wasted?
Turbulence in a bulk fluid is not quantum mechanical at the
macroscopic level, so I question whether it is random on that basis.
Chaotic, yes, but is it really random? There could be long wavelength
correlations inherent in the geometry of a lava lamp that would
introduce non-random features.
>If you use electronics, yes.
Radioactive measurements use electronics, unless you want to use a
fluoroscope. :-)
>I don't think you'd need to worry as much
>if you used radioactivity.
The detection electronics could be affected by ambient noise, however
slightly. The extent of the effect would depend on the kind of
detector. But I agree - radioactivity is a prime candidate for a TRNG.
Bob Knauer
"The American Republic will endure, until politicians realize they
can bribe the people with their own money."
--Alexis de Tocqueville
------------------------------
** 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
******************************
