Cryptography-Digest Digest #595, Volume #10 Sat, 20 Nov 99 01:13:06 EST
Contents:
Re: A Random Key Cipher Machine (Mark Adkins)
Re: A Random Key Cipher Machine (Mark Adkins)
Re: What part of 'You need the key to know' don't you people get? (Tom St Denis)
Re: AES cyphers leak information like sieves (Tom St Denis)
Re: AES cyphers leak information like sieves (Jerry Coffin)
Re: What part of 'You need the key to know' don't you people get? (Tom St Denis)
Arithmetica Inc Website (was GT-1 Consortium) (MikeAt1140)
----------------------------------------------------------------------------
Date: Fri, 19 Nov 1999 20:41:57 -0500 (EST)
From: Mark Adkins <[EMAIL PROTECTED]>
Subject: Re: A Random Key Cipher Machine
Tom St Denis <[EMAIL PROTECTED]> wrote:
> Typing for the most part is too regular to use as 'random' sampling
> points along a smooth sine wave. You would be sampling at common
> points during 'typing bursts'.
>
> Neat idea otherwise.
>
> Tom
I don't think so. Even the most "regular" typing only *seems*
regular, and even then only because the standards used by the
perceiver are coarse and inadequate. As I said before, if the
frequency of the sine wave is sufficiently fast (and this need
not be that fast even with respect to the fastest human typist)
no two consecutive keystrokes will fall within the same sample
sector, or even consecutive sample sectors, and even the smallest
irregularities (which always exist) will be randomized.
Look at it this way: a sine wave is mathematically equivalent
to a radius sweeping the circumference of a circle at constant
speed. If you divide the circle into sectors the sweep spends
the same amount of time in each sector (the exact time depending
upon the speed of the sweep). The circle is divided into 26
sectors, each of which corresponds to a different digital code
and hence also to a different key letter through the
programmable translation table. Which sector is selected
depends upon which sector the radius sweep is in at the time
a plaintext key is pressed.
Now, it's obvious that if the sweep is fast enough, no two
consecutively typed keys will select the same sector, or
for that matter two consecutive sectors. Furthermore, only
if the typed keys were separated by *exactly* identical
temporal intervals would the sweep select sectors separated
even by a constant distance. Even the most regular human
typing during "typing bursts" is not separated by identical
temporal intervals. The variations in the temporal intervals
between keys may be small or non-existent by the human
standard of someone using their ears to listen, but
the smallness of these variations in the present case is
a function of the speed of sampling. If the sweep is
sufficiently fast then these "small" variations in the temporal
interval between typed keys become *large* variations because
the sampling mesh (so to speak) is much finer. The
irregularities become *magnified* by the high frequency of
the sweep.
The nice thing about this is that the sweep is out of synch
with the typing and *stays* out of synch with the typing,
because the sweep is always regular but the typing is always
irregular if the frequency of the sine wave generator is
sufficiently fast. This is what provides the randomization
effect. Even if some irregularity (within specified tolerances)
exists in the frequency of the sine wave generator, this
irregularity does not match the irregularity in typing or
permit a synch.
--
Posted for my own amusement, since you are all figments.
Mark Adkins ([EMAIL PROTECTED])
------------------------------
Date: Fri, 19 Nov 1999 21:15:07 -0500 (EST)
From: Mark Adkins <[EMAIL PROTECTED]>
Subject: Re: A Random Key Cipher Machine
A couple of additional points.
The fact that the digital codes corresponding to key letters are
transmitted with the ciphertext is of no value to the unauthorized
receiver, since from his perspective each digital code could
represent any of the 26 key letters, and without the translation
table (which is programmable) he has no idea which one. Thus,
to the unauthorized receiver, no more information is present
than if the ciphertext alone were received. Since the key
letters are random, the digital codes corresponding to them
are also random (as are the ciphertext letters produced from
the random key letters). Frequency analysis is therefore
useless.
Thus, the possibility of a variable weaving scheme (for the
weaving of the digital codes into the ciphertext in the
transmitted signal) is merely an extra layer of security,
and really superfluous. But note that if the ciphertext
letters are digitally encoded for transmission, then all
the unauthorized receiver will see is one big stream of
numbers, and will have no idea how to unweave these even
if he knew that unweaving was necessary. (Not that it
would do him any good even if he did know the correct
unweaving scheme for that message!)
Finally, though I originally conceived of the programmable
translation table entries as consisting of a single digital
code corresponding to a single random key letter (since this
would simplify the change of digital codes over time),
there is no reason why each random key letter could not have
any number of different digital codes assigned to it in the
table. These could then be used in turn, whenever that
particular random key letter was selected. However, I see
no real advantage to this.
--
Posted for my own amusement, since you are all figments.
Mark Adkins ([EMAIL PROTECTED])
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Sat, 20 Nov 1999 02:36:26 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Johnny Bravo) wrote:
> On Fri, 19 Nov 1999 15:23:02 GMT, [EMAIL PROTECTED]
> (SCOTT19U.ZIP_GUY) wrote:
>
> > You asshole he messed his math up and admitted it so shut the fuck
up.
>
> His math was correct, he stated that 28 wheels with 26 positions
> each had more than 2^128 states. The fact that you still can't figure
> it out speaks volumes for your mathematical ability.
Whoa pause.... were the permutations on the wheels random? Or was it
just a rotation of A..Z for example a rotation by one would permute A
to B, B to C ... etc..
If that is the case log2(26^x) is correct. Otherwise xlog2(26!) + log2
(x!) is correct.
>
> >The argument really is over wheather one just considers the starting
postions
> >of 3 or more fixed wheels as the key. Or if the actuall order of the
> >characters on the wheels should count as part of the key. I prefer
to count
> >the wheel types possible it seems you and tom only want to use fixed
wheels.
>
> That's because the Enigma did use fixed wheels, we were talking
> about what the Enigma actually was, not a hypothetical system that
> never existed.
Hmm any good details online? I may have been right all along and not
knew it... wowy...
>
> >Which greatly reduce the key space. But face it one is simulating
the engima
> >the order of characters on the wheels would be part of the key space.
>
> Since the order of characters on the wheels is fixed and cannot be
> changed by the users, then you are not simulating the Enigma if you
> allow the users to change the wiring on the wheels. If you do, you
> are no longer talking about Enigma, but some hypothetical variant that
> was never used.
>
> Johnny Bravo
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Date: Sat, 20 Nov 1999 02:43:46 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> wtshaw <[EMAIL PROTECTED]> wrote:
> : In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> :> The problem about failure to diffuse information through the
message could
> :> be solved by applying diffusion before encrypting (though this
would
> :> destroy any error - recovery ability, of course).
>
> : It need not as a hologram is recoverable even with loss of part of
the
> : media. Redundancy is still an answer to error recovery, if you
want it.
>
> Indeed. My comments above were directed at block cyphers with or
without
> block-chaining, not at systems in general.
Block ciphers don't encapsulate systems. You can't for example encode
messages with RC6. You have to use the RC6 function in a program that
handles plaintext/ciphertext/keys as well..thus being called a
cryptosystem.
>
> : Most text is entirely recoverable with minor misspellings, so why is
> : diffusion so important.
>
> Diffusion helps defeat analysis. In particular, lack of diffusion
> helps facilitate various types of attack. This is the point that
much of
> this thread has been discussing.
Who is saying there is not enough diffusion and *confusion* (the term
which is more important here, note OTP have zero diffusion but are
completely secure...) in common modern ciphers?
> : Where length is flexable, only the last block might be short.
>
> Where length is completely flexible, there's no need for any block
> to be short.
>
> I understand that not everyone thinks that the technical problems with
> variable length blocks have been resolved, and not everyone agrees
that
> larger block sizes are better today. However - in principle - larger
> blocks (not necessarily with accompanying larger keys) seem to me to
be a
> good idea.
Yeah increase the work load linearly not exponentially. That makes
sense to me. You could for example simply add a single bit to a key
instead of 'double' encryption. Also if you assume a single encryption
is not strong why should double? [consider Schneiers comment on toy
DES ciphers with 128 rounds ... etc]
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: AES cyphers leak information like sieves
Date: Fri, 19 Nov 1999 19:55:12 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> You /have/ to try and make things as secure as you possibly can, within
> the constraints laced on you. This means making things as hard as you can
> for the analyst. Letting him know that there's an almost one to one
> relationship between bits of text and bits of cyphertext is not a good
> start.
If there's anywhere close to a 1:1 relationship between bits of
ciphertext and bits of plaintext, then your underlying cipher is so
poorly designed that NOTHING you can do with the chaining mode is
going to do any good at all.
> :> Look even PGP use a weak chaing mode with compression. Most
> :> people don't have the software to recover the real file
> :> if a change occurred in the middle of the compressed encrypted
> :> text. So what fuckin good does this error recovery do anyone
> :> who depends on PGP. It does them no fucking good it can
> :> only be of use to a dedicated attacker.
>
> : For those looking on, I'll translate this into understandable (and
> : civil) English: you're just as clueless as ever...
>
> You disagree?!
Well, at least you have a grasp of the exceptionally obvious.
> You think (for example) that people do generally have the
> software to recover from such a mess? Or perhaps you think that hardly
> anybody uses the software in question, so it doesn't matter? Or perhaps
> you think that there's no possible way knowledge that certain small
> regions of cyphertext correspond with certain regions of plaintext can
> help attackers? Perhaps you would like to clarify which, if any, of
> these false views do you hold?
Perhaps instead of trying to put words into my mouth, you should
actually pay attention to what's being said. First of all, consider
David's reasoning here: he says that since _most_ people lack the
software to recover from such a situation that the fundamental
capability "can only be of use to a dedicated attacker." This is
nearly a textbook example of fallacious reasoning. To say it can only
be of use to a dedicated hacker he has to prove that _nobody_ but a
hacker can make use of the information. He hasn't, he won't and he
can't, for the simple reason that it's dead wrong.
Second consider that even though the discussion was of CBC, he used
PGP as his example, and it (at least normally) seems to use CFB
instead. Since he apparently doesn't even know the difference between
CFB and CBC, how are we supposed to believe that he has a clue about
what and/or how either one contributes anything to security?
In one paragraph he managed to display a _complete_ failure to grasp
the simplest requirement of logic AND a profound ignorance of chaining
modes. How could that be called anything short of a display of
complete and unmitigated cluelessness?
> :> That is also way intelligent people should have the option
> :> of using something like "wrapped PCBC" when they want
> :> a far higher degree of security than the NSA 3 letter blessed
> :> mods that you foolish think is safe.
>
> : If you want to claim that one thing is more secure than the other, you
> : need to quantify the security of each and then compare the two. [...]
>
> No you do not.
Why not? You're doing nothing but making unsupported assertions. I'm
not asking for a precise quantification of security or anything close.
I'm simply saying that you have to make some attempt at looking at two
complete systems and compare their overall security -- without that,
trying to compare their security based on a few bits and pieces
results in nothing useful at all.
> Quantifying security in absolute terms is diffucult. However, seeing
> (for example) that adding known plaintext before direct encryption with
> a block cypher weakens the resulting system does not require this.
Quite the contrary. For known plaintext to weaken the system,
somebody has to invent an attack that makes use of the known
plaintext that's easier than something like key-exhaustion. While
having known-plaintext _seems_ like a useful thing, and certainly is
against some ciphers, you're simply accepting it as always being
useful with no proof of that at all.
> This case is directly analogous.
How? Again, you're simply accepting something without proof, and then
stating it as if it were a proven fact.
If you want to know the truth though, my own opinion is that you're
right on this particular point: I honestly believe they are closely
analogous. I also believe that neither one is going to benefit an
attacker to any significant degree against any of the ciphers in
question.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Sat, 20 Nov 1999 02:55:35 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Johnny Bravo <[EMAIL PROTECTED]> wrote:
> : (SCOTT19U.ZIP_GUY) wrote:
>
> :> are you a complete fool where did you get such a rediculus
number.
>
> : He used math moron, something you seem totally incapable of.
> : Each wheel has 26 positions, ln(26^26) is 131 bits [...]
>
> Are you perhaps forgetting that the wheels could be interchanged with
one
> another - and that this was a component of the key?
Depends... If there are 26 possible wheels total and the key is just
the order of x rotors, or 26! / (26 - x)!x!, if you had 4 rotors for
exmaple you would have a 14 bit keyspace.
If for example the rotor permutations are not fixed you get x(26!) +
x!, for 4 rotors this would be log2(4(26!) + 24) ~ 90 bits.
If anyone is good a finite and could collaborate or correct or
something. I haven't taken finite yet so I am just shooting in the
dark here....
> Perhaps you are neglecting the fact that there was a plugboard in
> front of the machine where a number of cables could connect any letter
> to any other letter?
The keyspace would be the permutations involved in
encryption/decryption. This is primarly the rotors [hence the term
rotor cipher].
> There are /many/ possible figures you can get for the keyspace of the
> Enigma machine, depending on which combination of components you
consider
> to be part of the key.
The rotor.
> There were a number of different types of wheel employed over a
period of
> time, with differing arrangements of letters. Do you count this? Or
not?
See my second expression.
> Let's not get into a flame festival over this issue.
And why not. At first I thought I was right, then I posted I thought I
was wrong... now I haven't a clue... but keeps the conversation going.
What we need is a url to one of John Savards cool cipher links ... He
has a ton of info and this may end the thread...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (MikeAt1140)
Subject: Arithmetica Inc Website (was GT-1 Consortium)
Date: 20 Nov 1999 04:17:45 GMT
The comments about the Arithmetica Inc Website make their point. Although I
teach courses at The CUNY Graduate School on
34 th Street the 'miracles' cited on the Arithmetic Website just didn't happen.
The researchers will try to have the media and marketing people make changes.-
Michael Anshel (CCNY/CUNY)
__________________________________________________________________________
__________________________________
Subject: Re: GT-1 Consortium
From: David A Molnar <[EMAIL PROTECTED]>
Date: Fri, 19 November 1999 08:21 PM EST
Message-id: <814t21$qnv$[EMAIL PROTECTED]>
Michael Scott <[EMAIL PROTECTED]> wrote:
> Well there you have it from these "experts". Your 1024 bit PGP key can be
> factored in 4 milli-seconds...
Looks like someone screwed up in writing the ad copy. It happens (for
a while, the NTRU site claimed that "no one has ever tried to parallelize
lattice basis reduction algorithms" -- thankfully they've fixed that) and
doesn't say much for whomever wrote it. Even so, it could be the case that
the ad copy and the algorithm were designed by two different people.
I just wish they'd post their papers on the web site. Seriously. At least
references.
-David
____________________________________________________________________
Subject: Re: GT-1 Consortium
From: "Michael Scott" <[EMAIL PROTECTED]>
Date: Fri, 19 November 1999 02:07 PM EST
Message-id: <0ehZ3.819$[EMAIL PROTECTED]>
>From the Web page...
"Security for the most common commercial systems, one-way multiplication
functions, is based on the difficulty in factoring the product of two
primes. Utilizing the most advanced algorithm, this requires a number of
calculations equal to 2^(N^.5) where N is the number of digits in the
decryption key. For example, a 1024 bit key based on the product of two 512
digit primes could be broken with 2^32 calculations. The world's fastest
computers can now operate at 2^40 calculations per second."
Well there you have it from these "experts". Your 1024 bit PGP key can be
factored in 4 milli-seconds...
Mike Scott
MikeAt1140 <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Arithmetica to Introduce Next-Generation Encryption Technology at
Consortium
> Hosted by StorageTek
>
> DALLAS--(BUSINESS WIRE)--Nov. 17, 1999--
>
> GT-1 Consortium to Demonstrate How Algorithms Developed With Symbolic
>
> Computation Can Meet Market's Need for Increasingly
>
> Fast, High-volume Transactions
>
> Arithmetica, Inc., an encryption technology company, has launched
GT-1, a
> consortium to advance next generation security algorithms for the emerging
> digital economy. StorageTek(tm) (NYSE:STK) will host the first meeting at
its
> New York City location on Dec. 15, 1999. Cryptographers and cryptanalysts
from
> numerous firms will participate.
>
> Arithmetica's technology was developed from contemporary research in
> advanced mathematics -- group theory arising from geometric topology. Its
> symbolic computation requires less processing resources than arithmetic
> computation.
>
> Mathematical science scholars who developed Arithmetica's technology,
Dr.
> Michael Anshel, Dr. Iris Anshel and Dr. Dorian Goldfeld (winner of the
American
> Mathematical Society's Cole Prize in Number Theory and the Vaughn
Foundation
> Prize) will present at GT-1.
>
> "If proven secure, Arithmetica's innovative new public key method
holds
> promise in many areas of interest to StorageTek including encrypted
storage and
> data and access to networked storage," said Dr. Aloke Guha, vice president
of
> corporate architecture for StorageTek. "What particularly interests us is
that
> the algorithm is linear to the key size. Being linear to the key size
implies
> that the implementation can be potentially hundreds of times faster than
> existing public key methods. We expect this consortium to move this
technology
> forward towards adoption." StorageTek has been examining this algorithm
for the
> past two years.
>
> According to Richard Aguirre, president and CEO of Arithmetica, GT-1
will
> educate technical experts in the industry about Arithmetica's new public
key
> system. He projects that increased awareness will generate more
performance
> testing in different environments -- and facilitate its introduction to
various
> standards bodies.
>
> "Arithmetica has privately shown this algorithm to some of the top
> cryptographers and cryptanalysts in the industry. With our positive
feedback we
> want to move forward with the consortium to advance its development for
> electronic commerce, secure data storage, and wireless applications," said
> Aguirre. "Our goal is to gain market acceptance for the algorithms."
>
> About StorageTek
>
> StorageTek is the preeminent provider of network storage. The
company's
> strategy is to provide "Open, Intelligent and Integrated"(tm) solutions
that
> combine storage products, storage management software and storage
services.
> StorageTek solutions help customers collect, move, store, share and
protect all
> types of digital content on platforms ranging from laptops to enterprise
> servers. The company, with headquarters in Louisville, Colo., reported
revenue
> of $2.3 billion in 1998. Information on StorageTek is available on the
World
> Wide Web at www.storagetek.com or phone 800/786-7835.
>
> About Arithmetica
>
> Arithmetica is a next-generation encryption technology company that
was
> founded in 1993. Its scientists -- who have expertise in cryptography,
number
> theory and fast algorithms -- have applied revolutionary mathematical
> discoveries to reduce computational complexity and increase processing
volume
> and speed. Arithmetica's products provide high performance secure
> communications for electronic commerce applications and for enterprise,
> wireless, broadcast and broadband networks. Arithmetica's cryptographic
> research and product development is based in Tenafly, N.J.; its
headquarters is
> in Dallas. For more information see www.arithmetica.com.
>
> Editor's note: The GT-1 Consortium will take place at StorageTek's New
York
> location -- 10 a.m., Dec. 15, 1999. For more information call Rick Aguirre
> 972/857-8909. One World Financial Center 200 Liberty Street 21st floor New
> York, NY 10281 212/416-0700
>
> CONTACT:
>
> Teq Marketing, Dallas
>
> Susan Huber, 972/231-1973
>
> [EMAIL PROTECTED]
>
> or
>
> Arithmetica, Dallas
>
> Rick Aguirre, 972/857-8909
>
> [EMAIL PROTECTED]
> __________________________________________________________________________
> __________________________________
>
> Professor Michael Anshel
> Department of Computer Sciences R8/206
> The City College of New York
> New York,New York 10031
***************************************************
Subject: Re: GT-1 Consortium
From: David A Molnar <[EMAIL PROTECTED]>
Date: Fri, 19 November 1999 08:21 PM EST
Message-id: <814t21$qnv$[EMAIL PROTECTED]>
Michael Scott <[EMAIL PROTECTED]> wrote:
> Well there you have it from these "experts". Your 1024 bit PGP key can be
> factored in 4 milli-seconds...
Looks like someone screwed up in writing the ad copy. It happens (for
a while, the NTRU site claimed that "no one has ever tried to parallelize
lattice basis reduction algorithms" -- thankfully they've fixed that) and
doesn't say much for whomever wrote it. Even so, it could be the case that
the ad copy and the algorithm were designed by two different people.
I just wish they'd post their papers on the web site. Seriously. At least
references.
-David
___________________________________________________
------------------------------
** 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
******************************
