Cryptography-Digest Digest #592, Volume #10 Fri, 19 Nov 99 16:13:03 EST
Contents:
Re: AES cyphers leak information like sieves (Tim Tyler)
GT-1 Consortium (MikeAt1140)
Re: AES cyphers leak information like sieves (Anne & Lynn Wheeler)
Re: technical writing skills required! (Medical Electronics Lab)
Re: Public Keys Comparison (David A Molnar)
Re: GT-1 Consortium ("Michael Scott")
Re: Bypass analysis of cipher machines (Troed)
Apparently, Hushmail does work (John Savard)
Re: rotors (Tom St Denis)
Re: Ultimate Crypto Protection? (John Savard)
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Reply-To: [EMAIL PROTECTED]
Date: Fri, 19 Nov 1999 17:12:04 GMT
Jerry Coffin <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
:> Jerry Coffin <[EMAIL PROTECTED]> wrote:
:> : Those who really believe that simply re-transmitting a message is
:> : reasonable if it doesn't come through intact should read _Between Silk
:> : and Cyanide_ continuously until they learn better.
:>
:> What are you talking about? Retransmitting a cyphertext presents
:> practically no security risk at all.
: I'm not talking about a risk of security due to the message being
: intercepted. I'm talking about a risk (in some cases quite extreme
: risk) of the person sending it being found and killed, for one
: example.
I see. /Sometimes/, there are problems with sending more than one
message. /Sometimes/ the message content may be so critical that
your recipient must get it first time for it to be of use.
However, resending messages, is not /necessarily/ unreasonable.
In fact resending entire messages is often the best way of coping
with garbles.
I'd wholeheartedly agree that resending messages can be dangerous
*in some circumstances*. However, that is no reason to malign
resending messages in general - as often there is no problem with
doing so, and it is the correct thing to do.
[snip]
:> Keeping compression separate is a good idea. However, a "chaining mode"
:> is not a necessary component of a cypher. For one thing it necessarily
:> introduces a serial component to encyphering. If you have a parallel
:> machine available, introducing something like this may kill performance.
:> My code is mainly targetted at FPGAs. In such domains, "chaining modes"
:> are not really on the menu.
: I think I pointed out that ECB can be useful in this sort of
: situation. I'll also point out, however, that ECB is NOT the only
: solution. Another possibility would be for each device to use CBC,
: and simply have a number of interleaved streams, each encrypted by one
: device. Each device (and therefore each stream) uses a separate IV.
: Unless you're using such massive parallelism that you expect each
: device to encrypt only a very small number of blocks [...]
That's the situation I'm thinking about. In fact, no blocks are involved,
but if they were, each "device" would be handling one block.
Basically, having a chain of operations means that each must be performed
in sequence. Your proposal about employing multiple streams would
certainly reduce chain length and speed things up. However, might
it not also adversely affect the overall security, to have all these
messages encrypted with the same key, and only different IVs?
It appears to me that suddenly you need to pay attention to any patterns
in the generation of the IVs - an issue that was of diminished relevance
when each IV came under a separate key...
:> This is a virtue of using error-correction technology. No matter /how/
:> noisy a channel you are faced with you can still get a 99.99% chance of
:> successful transmission if you throw bandwidth at the problem.
: Yes, if you have sufficient bandwidth to spare you can overcome almost
: any amount of noise. Sometimes you just don't have that kind of
: bandwidth though...
If your problems are that big you either are sending a *very* large file,
or are extremely likely to get errors in each 128-bit block *anyway*.
If you have a probability of error in each bit of approx 1/128, it does
not take much extra bandwidth to give a very high probability of
successful transmission - unless the messages are *very* long.
:> Under the *insanely*-infrequent conditions where you have limited
:> bandwidth, high error rates, no chance of resending a failed message, and
:> you /must/ get some fragments of your message across, this can /still/ be
:> done by splitting the message up. This reduces it to a cookbook-mode
:> block cypher. You can /still/ apply block chaining to consecutive
:> messages if you /really/ want.
: IOW, with enough kludges, you can overcome the inherent shortcomings
: of the particular chaining mode you're advocating...
I'm not advocating *any* sort of chaining mode - I'd prefer no blocks and
no chaining at all most of the time.
Nor were my suggestions above "kludges". They were a description of how
to reduce a variable-length-block system to a fixed-length-block system
if and when the occasion demanded it.
In those rare circumstances where externally-applied error recovery is not
sufficient, by all means use block-chaining - if you think it will help.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
If you're afraid of being lonely, don't try to be right.
------------------------------
From: [EMAIL PROTECTED] (MikeAt1140)
Subject: GT-1 Consortium
Date: 19 Nov 1999 17:31:41 GMT
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: AES cyphers leak information like sieves
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Fri, 19 Nov 1999 17:51:10 GMT
a lot of hardware transmission gear currently incorporates various
kinds of FEC ... typically something like reed-solomon or
viturbi. long ago & far away we worked on doing standard hardware
15/16ths reed-solomon & then on selective resend, transmit the 1/2rate
viturbi ... instead of the original block.
on links with bit-error-rate (BER) of 10-**9, 15/16ths reed-solomon
can give six orders of magnitude correction ... i.e. resultiing in BER
10-**15.
by sending the 1/2rate viturbi on selective resend ... instead of the
original message ... there is still high probability of message
recovery even if both individual messages have uncorrectable
transmission errors (also the total number of bits transmitted is the
same as in the simple selective resend protocol).
this was applying FEC to the encrypted message. wouldn't work in the
simple hardware link encrypter desings ... since the selective resend
logic wouldn't have access to the original encrypted message for
calculating the 1/2rate viturbi FEC.
monitoring the frequency of transmission errors ... the process could
decide to switch from selective resend of the 1/2rate viturbi ... to
alwas transmitted the 1/2rate virturbi with the original message
(pretty lossy conditions ... say BER 10-**2). Trade-off of loosing
half the effective thruput vis-a-vis overhead of doing selective
resend.
--
--
Anne & Lynn Wheeler | [EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: technical writing skills required!
Date: Fri, 19 Nov 1999 12:20:17 -0600
Tom St Denis wrote:
>
> I want to write a technical 'data book' on peekboo [my neato crypto
> program] in which I want to document how peekboo works [every nitty
> detail] and attack trees.
>
> What I would like [pretty please with a cherry on top] is someone[s]
> with technical writing skill [or just time to waste] to help write this
> thing. I would imagine it would be a rather large document ...
>
> Anyways takers? [please?] This is the sort of thing sci.crypt should
> be perfect at!
As a high school student, you have more time than all the rest
of us combined! Your best bet is to write up sections and post them
here for comments. Work on each section until you're tired of the
rants you get back :-)
Writing anything to explain something is hard, technical writing
is really hard. The hardest part is to prevent boredom. The basic
rule is to tell 'em what you are going to say, say it, and tell 'em
what you said (abstract, body, summary). You need to do that for
the whole thing, for each section and for each subsection.
"Practice makes perfect", so start practicing. The skills you
learn will include writing, learning (because you learn more when
you try to explain things) and politics (because you have to deal
with criticism).
Patience, persistence, truth,
Dr. mike
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Public Keys Comparison
Date: 19 Nov 1999 18:38:19 GMT
Justin <[EMAIL PROTECTED]> wrote:
> On 19 Nov 1999, UBCHI2 wrote:
>> Has anyone mounted an effort to download all the public keys posted on the
>> internet to see how many of them exhibit similarities? If there are similar
>> public keys, that would prove damning evidence that a backdoor was in use.
> e-mail MIT or some other PGP key server organization, and get them to
> offer all public keys in one giant archive, or publish stats on them.
or just start running your own keyserver and synchronizing with the
others out there that have gigabytes and gigabytes of keys. they'll
send 'em to you for free, if you can handle it. :-)
Also, what do you mean by "similar" ? and how "similar" do keys have
to be before you conclude something is fishy? and what if some
subset of people are using software with a backdoor, but most
aren't ?
-David
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: GT-1 Consortium
Date: Fri, 19 Nov 1999 19:07:49 -0000
>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
------------------------------
From: [EMAIL PROTECTED] (Troed)
Subject: Re: Bypass analysis of cipher machines
Reply-To: [EMAIL PROTECTED]
Date: Fri, 19 Nov 1999 19:16:14 GMT
Sundial Services <[EMAIL PROTECTED]> wrote:
>I agree with all the points. In fact my experimentation with the PKZip
>stream-cipher .. with a "no known plaintext attack" .. was based on the
>notion of statistically-more-probable bytes or combinations of bytes.
>This is analogous to using predictable characteristics of (say) English
>plaintext. But I also note that the number of possibilities is still
>huge and that my experiments produced decidedly mixed results.
Ah yes, what's the latest on zip encryption?
Last thing I heard (several years ago now) was that it was broken by a
group of persons frequenting a mailinglist called *censored* since
they wanted to know what was inside a zip file called *censored*. It
turned out that the contents were fake, but to find that out at least
two different programs were written that cracked the encryption.
I believe both of them targeted (and excuse me if my facts are wrong
now) the 3 different 32-bit keys that are used internally, instead of
the actual password. I do think they needed around 14 bytes of
cleartext, which would mean that your thinking above would have been
even better. (But aren't there always 14 bytes that don't change
between zip-archives?)
___/
_/
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Apparently, Hushmail does work
Date: Fri, 19 Nov 1999 19:25:59 GMT
A posting in
jyu.ohjelmonti.coderpunks
mentions
http://www.hushmail.com/how_it_works.htm
which seems to indicate that the resident application from Hushmail
works basically the same way that PGP did; thus, except for the fact
that its source isn't available, and worries of that nature, there is
no reason to believe that it doesn't "work".
John Savard (don't snooze, don't snore)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: rotors
Date: Fri, 19 Nov 1999 19:22:56 GMT
In article <8147mi$479$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <812h48$svu$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > Blush ... I messed up oh well.
> >
> > it's 128 / log2(26!) for the num of rotors, or 2 rotors. Assuming
all
> > permutations are secure. At any rate rotors were not attacked via
> > brute force so this line of thinking is moot.
> >
> > I apologize for this error...
>
> Wow I suck this week... it's actually closer to
>
> 128 / log2(x!(26!)) or about x=15 rotors...
Oops... that shouldn't that be
128 / (x * log2(26!) + log2(x!))
Arrg...I can't think this week... sorry all. I am gonna take a few
days off, let my mind come together,
cheers!
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Ultimate Crypto Protection?
Date: Fri, 19 Nov 1999 19:36:09 GMT
amadeus @0SPAM.netcomuk.co.uk (Jim Dunnett) wrote, in part:
>How do you go about cryptanalysing a properly-implemented one-time-pad?
That's classified.
:)
Actually, the source of this confusion is that a one-time pad can be
_improperly_ implemented even if pads are never reused.
If the pads were generated algorithmically, the phrase "stream cipher"
suggests itself.
But the Russian one-time pads were apparently generated "at random" by
armies of human typists trying to generate random digits. Apparently,
they weren't even given special typewriters where the letter keys all
had digits assigned to them in a haphazard arrangement (that would
have helped!). Hence, things like the rarity of sequences of repeated
digits, alternation between right and left hands, and so on, existed
to be exploited.
John Savard (don't snooze, don't snore)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
** 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
******************************
