Cryptography-Digest Digest #397, Volume #11 Thu, 23 Mar 00 04:13:02 EST
Contents:
Re: 2048 Bit Encryption? (Anthony Stephen Szopa)
Re: Gray Code like ([EMAIL PROTECTED])
Re: Factoring Large Numbers - I think I figured it out! (Johnny Bravo)
Re: Gray Code like ([EMAIL PROTECTED])
Re: ecc equation ("Joseph Ashwood")
Re: pgp key collision (Lutz Donnerhacke)
Re: pgp key collision (Lutz Donnerhacke)
Re: pgp key collision (Lutz Donnerhacke)
Re: 2048 Bit Encryption? ("Joseph Ashwood")
Re: Factoring Large Numbers - I think I figured it out! (Johnny Bravo)
Re: Factoring Large Numbers - I think I figured it out! (Johnny Bravo)
Re: Do you think I'm ready? What do I need? ("Joseph Ashwood")
nnqssqaa collection bandwidth estimate? (David Bernier)
experiences with cryptlib toolkit? (Wouter)
Re: NIST publishes AES3 papers ("Joseph Ashwood")
Re: Hashing Algorithms. (basic newbie question) ("Joseph Ashwood")
----------------------------------------------------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: 2048 Bit Encryption?
Date: Wed, 22 Mar 2000 22:17:00 -0800
[EMAIL PROTECTED] wrote:
>
> On Wed, 22 Mar 2000 12:47:47 -0600, James Felling
> <[EMAIL PROTECTED]> wrote:
>
> >
> >
> >Anthony Stephen Szopa wrote:
> >
> >> [EMAIL PROTECTED] wrote:
> >> >
> >> > Even with the NSA's new holographic computer technology?
> >> >
> >> > see -> http://www1.ekstrabladet.dk/VisArtikel.iasp?PageID=43390
> >> >
> >> > On Tue, 21 Mar 2000 21:41:55 -0800, Anthony Stephen Szopa
> >> > <[EMAIL PROTECTED]> wrote:
> >> >
> >> > >[EMAIL PROTECTED] wrote:
> >> > >>
> >> > >> Can the NSA break a 2048 bit encrypted email message? If they can,
> >> > >> is there anything out there that they can't break?
> >> > >
> >> > >I don't think they can break OAP-L3
> >> > >
> >> > >http://www.ciphile.com
> >>
> >> Let's start to address this point by asking this question:
> >>
> >> What is your wildest upper estimate as to how fast such a computer
> >> might be?
> >>
> >> Can it perform, maybe, 1E12 operations per second? Perhaps 1E24
> >> operations per second? How about 1E100 operations per second?
> >> Even 1E1000 operations per second?
> >>
> >> Even if this holographic computer can perform at 1E1000 operations
> >> per second (or faster), it will still be ineffective in cracking
> >> messages encrypted with OAP-L3 if the key were simply made long
> >> enough. And this key would not be difficult to process by a user
> >> of OAP-L3.
> >>
> >> OAP-L3 is not susceptible to factoring attacks.
> >
> >Nor is any other stream cypher (the family of cyphers that OAP-L3 fals
> >into). OAP-L3 has never been subject to any formal reviewal process, and its
> >algorithim has not been subjected to a public examination to determine its
> >quality. There are many other stream cyphers of which this is true.
> >
>
> So in other words OAP-L3 isn't official at all. Does this mean that
> it could have flaws?
>
> >> If you want to
> >> crack OAP-L3 encrypted messages you must guess a key, process
> >> it to generate OTPs, then attempt to decrypt the message using
> >> these OTPs.
> >
> >> This is quite a computationally intensive process
> >> for each and every possible key.
> >
> >Assuming you are attacking OAP-L3 by brute force, as opposed to a more
> >rational attack such as cryptoanalisys. Calling the bitstream it generates
> >an "OTP" is a misnomer. A stream cypher may have an exceptionally long
> >period, but it can and does repeat, and even if it does not have repeating
> >values there will be characteristics of the stream that prevent it from
> >generating truly random data( an absolute necessity in an OTP -- calling a
> >stream cypher an OTP is like calling a rusted out chevy with no wheels up on
> >blocks with a cracked engine block and no seats a car -- they are related
> >entities, and may look similar to the untrained eye, but one does the job,
> >and the other does not. )
> >
> >>
>
> What are some characteristics of a streams without repeating values?
>
> Are there ways to generate truly random data?
>
> >>
> >> If the OAP-L3 key length provides a security level of 1E100000
> >
> >1E100000 what? bits? possible keys?
> >
> >> and
> >> this holographic computer can perform 1E1000 operations per second
> >> then at a minimum it would take 1E99000 seconds to just generate all
> >> possible keys (not to mention all the time it would also take to
> >> generate the OTPs from each of these keys, etc.)
> >
> >Anyone worth their salt won't generate all keys, they will attack the
> >algorithim. In addition just because there are X many possible keys doesn't
> >mean that the algorithim used in key generation will select randomly from
> >that space -- attacks based on the fact that most people want a
> >password\phrase that is shorter than the Declaration of Independence will
> >limit that to a much smaller amount in practice, and that is assuming that
> >such a phrase is of good quality.
> >
>
> What are some steps that one would take to determine the algorithim?
>
> >>
> >>
> >> If you are a US or Canadian citizen currently residing in the US or
> >> Canada and your ISP is physically located in the US or Canada, you can
> >> get the OAP-L3 Shareware Version 4.1 via email. Go to
> >> http://www.ciphile.com and go to the Pricing and Ordering web page.
> >> Click on the blue underlined "email" anchor tag in the third paragraph.
> >> Send us this email.
> >>
> >> Or you can go to the web site and directly download the OAR-L3 random
> >> number generation software directly.
> >
Your first step should be to get the software and read the Help
Files then evaluate the software.
You might start by just reading the "Theory, Processes 1, and Processes
2" Help Files available at the web site.
These pages are simple and only about 3 legal size pages long.
Most all your questions will then be answered and you will have
acquired knowledge.
http://www.ciphile.com
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Gray Code like
Date: Thu, 23 Mar 2000 07:27:08 GMT
> I don't understand. You have given the order of the code symbols
> in your post. So, given a symbol, you already know its exact
> position in the column, don't you? That fact doesn't change if you
> turn that column into a circle.
>
> M. K. Shen
I think I'd better spell it out to avoid further confusion. I wrote that
_one_ column should be written in a circle to illustrate the properties
of this code...and there are three columns in the list of code words I
presented. Take for example all the righmost bits and write in a circle
as
010
0 1
011
With a circle of just 8 symbols I have described all eight 3-bit code
words and their relative distances from eachother. Moving a window of
width 3 one step in the circle will move you to an adjecent code word.
Not sure how to explain this particular property of the code any
clearer.
Laters,
/Tomas
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: Factoring Large Numbers - I think I figured it out!
Date: Thu, 23 Mar 2000 02:36:48 -0500
On Wed, 22 Mar 2000 18:34:23 -0500, "Richard Anthony Hein"
<[EMAIL PROTECTED]> wrote:
>
>"Richard Anthony Hein" <[EMAIL PROTECTED]> wrote in message
>news:1IcC4.5914$[EMAIL PROTECTED]...
>>
>I totally forgot about each combination of paths. That would add 1000^1000
>necessary strands, wouldn't it? Plus duplicates for reasons cited below.
>But a cube of DNA 1,000,000nm X 1,000,000nm X however much is enough extra
>would be enough for the paths. Well I am sure I am missing a lot here, so
>enlighten me please.
1000^1000 is 10^3000 strands, lets find out how much volume that would
require.
A cubic meter is 10^27 nm, each strand is 10^3 cubic nm. So each cubic
meter contains 10^24 strands. Not enough.
Pluto averages 5,913,520,000,000 meters from the Sun. Thus a cube the
size of the Solar System would contain 2.07*10^38 cubic meters or
2.07*10^62 strands. Not enough.
The nearest star to our Sun is Alpha Centauri C (Proxima Centauri) at a
measly 4.22 light years. Light travels 3x10^8 m/s so a light year is
9,461,000,000,000 km. A cube of this size is 8.47x10^47 cubic meters and
contains 8.47*10^71 strands. Not enough.
In 1997, the most distant object yet discovered, Galaxy 0140+326RD1, was
found to have a redshift of 5.34, giving it a distance of roughly 12.22
billion light years from us. A cube of 12.22 billion light years would
contain 1.55*10^102 strands. Not enough
6.45x10^2897 cubes roughly 12.22 billion light years across full of DNA
would be enough to factor a 1000 bit number. Finally enough.
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Gray Code like
Date: Thu, 23 Mar 2000 07:44:53 GMT
> > An example:
> >
> > 000
> > 001
> > 010
> > 101
> > 011
> > 111
> > 110
> > 100
>
> I don't like one step. 000, 001, 010, then 100. Why 101?
> If you are alternating 0 or 1 to rotate in, then the next
> step to 011 doesn't fit. An LFSR will give you a "random"
> looking sequence and go thru all possible combinations.
> (It's not random, just messed up.)
>
> Patience, persistence, truth,
> Dr. mike
Mike,
The only codeword that can preceed 000 in a code like this is of course
100 (a 1 shifted in from the left) since shifting in a 0 would give
exactly the same code word (000) again. Using up code word 100 somewhere
else would be impossible in this way of encoding.
The goal of this is _not_ to use this as a generator of code words if
your only aim is to produce all possible symbol combinations. The goal
in the example is to produce a code such that a cyclic stack of _only_ 8
bits will describe the complete selection of codewords and their
relative distances. The chain
010
0 1
011
is thus enough to describe all codewords.
Many thanks to Vincent for pointing me in the correct direction with
this. Codes like these are indeed based on deBruijn sequences. Thanks!
Take care,
/Tomas
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: ecc equation
Date: Wed, 22 Mar 2000 23:49:32 -0000
> Hmmm.... I wonder what elliptic curves over the complex
plain could
> do for crypto :-)
Since there are multiple planes that could be called complex
(my knowledge of the specific terminology in the realm is
not even shaky, so pardon if this is mistake). It seems to
me that in some of these planes, it is very simple to find a
solution, and in others I don't see a simple solution
existing, in a few planes I don't see a computationally
inexpensive way of performing the computations. I think it
is worth exploring though, and honestly I understand the
logistics (if not the terminology) of the complex plane
better than the Elliptic Curve planes. The generic a+bi
plane set seems safe, certainly no less safe than n.
I suppose if one were to create a collision equation between
two elliptic curves (or complex planes) it would be possible
to create a complicated plane (for lack of better
terminology, perhaps poly-elliptic?).
Joe
------------------------------
From: [EMAIL PROTECTED] (Lutz Donnerhacke)
Subject: Re: pgp key collision
Date: 23 Mar 2000 07:54:30 GMT
* Paul Koning wrote:
>So the question isn't whether you can find a key whose fingerprint
>begins with a given 32 bit value -- that's a simple 2^32 exhaustive
>search exercise. Entertaining when you display the keyring,
>but not important. The question is whether you can generate a key
>with a given 128 bit fingerprint. You claimed that you can.
>I don't believe it.
Of course. I only refered to a deadbeed attack as a attack to a given
section of the fingerprint.
------------------------------
From: [EMAIL PROTECTED] (Lutz Donnerhacke)
Subject: Re: pgp key collision
Date: 23 Mar 2000 07:55:46 GMT
* Daniel Hartmeier wrote:
>Type Bits/KeyID Date User ID
>pub 2048/19990101 1999/01/15 Root CA des Individual Network e.V.
> <[EMAIL PROTECTED]> (SIGN EXPIRE:2000-12-31)
> Key fingerprint = 19 99 01 15 02 B4 7A 6B 33 D9 58 EE FC 09 8C E6
>
>So, the first four bytes of the fingerprint resemble the creation
>date. I assume the date is part of the data that is being hashed,
>or is it not?
Date ist not hashed. But even if it is hashed the attack remains.
------------------------------
From: [EMAIL PROTECTED] (Lutz Donnerhacke)
Subject: Re: pgp key collision
Date: 23 Mar 2000 07:57:01 GMT
* [EMAIL PROTECTED] wrote:
>anyway, you need to fool whole fingerprint, not just begining, can you ?
Nope. To attack the v4 KeyID (= part of the fingerprint) only a short
portion must be attacked. This is easy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: 2048 Bit Encryption?
Date: Thu, 23 Mar 2000 00:02:54 -0000
Crossposted-To: talk.politics.crypto
> So in other words OAP-L3 isn't official at all. Does this
mean that
> it could have flaws?
Right OAP-L3 is merely a product by a specific person, who
is obviously mistaken about the difference between OTP and a
stream cipher, and has been told so on many occassions.
> What are some characteristics of a streams without
repeating values?
There are 2 primary ones.
1) they have less output space than a stream that can have
any values. A short example is binary, without possibility
of repeated values, your options are: 01, 10. Including
repeats your space is double; 00,01,10,11. The space
actually increases rather exponentially.
2)Stream with repeated values can be infinite in length,
streams without repeated values have an extremely finite
space.
> Are there ways to generate truly random data?
There are ways to generate data that is so random as to be
feasibly indestinguishable from random, but there is no
method that has been mathematically proven to generate
random numbers.
> What are some steps that one would take to determine the
algorithim?
Decompile the executable, outside of that you can only
guarentee that it is accurate to a certain placement. Of
course if Szopa ever actually reveals the algorithm, instead
of just doing some hand-waving, then we can not only know
the real algorithm with certainty, we cannot analyse the
algorithm, to determine it's weaknesses. However, that is
only if we chose to obey the rules, which an attacker
obviously does not.
Joe
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: Factoring Large Numbers - I think I figured it out!
Date: Thu, 23 Mar 2000 03:05:09 -0500
On Wed, 22 Mar 2000 21:04:12 GMT, [EMAIL PROTECTED] wrote:
> Regarding factoring on DNA computers, there
>is a different major problem- Using Adelman's
>original approach it would take 10^200000
>liters of DNA to factor a 1000 bit number.
That's all? That's only about 2.5x10^199988 cubic
miles of DNA. If nothing ever died we might have that
much DNA lying around for use by now. :)
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: Factoring Large Numbers - I think I figured it out!
Date: Thu, 23 Mar 2000 03:05:04 -0500
On Wed, 22 Mar 2000 14:26:51 -0500, "Richard Anthony Hein"
<[EMAIL PROTECTED]> wrote:
>A method does not always have an algorithm that can be modeled. For
>example, using DNA to factor is a method.
However you were talking about microchips. If you can put it on a
microchip you can model it with a computer. And no matter what you can
estimate the speed of the method. You've already been told that we have
factoring methods that work, there is no interest in a special machine
that does the same job at an equal or lesser speed.
> However there is no way to currently model that method using classical
>computers.
You can, but there would be little point as DNA is a very inefficient
method due to the extremely large space requirements.
>Same thing applies
>to quantum computation. The method in quantum computation utilizes the
>method of superimposing both the on and off states of a bit, thus making a
>qubit. Shor's algorithm would make use of this methodology. However, try
>to use that method on a classical computer and you'll find that it's
>impossible - at least it seems to be impossible.
You would be wrong, Shor's algorithm has long been implemented on
"classical" computers. It is slow, takes exponential time, but it does
work.
>I would like to comment one more time on the commercial value of a method
>that can be used with today's technology:
I don't care about the possible value of a quantum computer, I want to
know the specific value of your factoring machine. Or is your factoring
machine a general purpose quantum computer and your "method" is Shor's
algorithm?
>When the idea of quantum computers was conceived, no one really thought that
>it would be much more than a really fast computer.
Which is exactly what it would be, assuming anyone ever manages to solve
all the problems involved with building one.
> There really wasn't much
>interest except by academics to try to actually MAKE one of these machines,
>because it would take a long time, and lots of work, and money to build one,
>and it might be impossible to do it.
This is all still true.
>However, when Shor's algorithm was introduced, people realized the potential
>of a quantum computer and now they are working their collective butts off to
>try to build one.
They are building one to build a quantum computer, they are not
expecting to get rich because they can factor numbers fast. A working 10
qbit quantum computer would be the fastest machine on the planet, for any
large scale multi-processing that regular computers would perform. This
has quite a few uses besides factoring numbers; perfectly secure
cryptography and searching, especially algorithmic searching (Grover's
algorithm) being two of them.
> They obviously believe there is commercial value now, all
>because of Shor's algorithm.
Scientists build many things, regardless of commercial value. They are
doing it to push the boundary of knowledge, not to make money. What is
the commercial value of the Hubble Space Telescope, or the subsequent
discovery of a galaxy 12.22 billion light years from Earth?
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Do you think I'm ready? What do I need?
Date: Thu, 23 Mar 2000 00:27:15 -0000
I didn't really get a chance to jump in on this earlier, but
I think I speak for all of us when I say that we always
welcome people with an interest in genuine cryptography, and
we're always willing to help.
Joe
ICQ: 4107766
AIM: holomntn
All are welcome
"RecilS" <[EMAIL PROTECTED]> wrote in message
news:8bbju9$k2h$[EMAIL PROTECTED]...
>
> RecilS wrote in message
<8b9l12$og7$[EMAIL PROTECTED]>...
> >I'm presenting my situation to everyone with hopes that
someone can steer
> me
> >to a good path.
>
>
> Hey thanks for the support. I've been driving my own
crypto-train for a few
> years now and I'm just begining to find people interested
in it. If anyone
> would like to help me out, I'd REALLY like some sample
source in either vb
> or c++ (nothing obfuscated [however it's spelled ;)] but
simple to read).
> The good news is I'm good with communications already and
creating user
> interfaces, so if anyone has an algorithm they need to
implement let me
> know.
> BTW - I misstyped Vernam I guess =) It was late when I
posted ;)
>
> My ICQ # is 10454728
> My AIM SN is RecilS
>
>
------------------------------
From: David Bernier <[EMAIL PROTECTED]>
Subject: nnqssqaa collection bandwidth estimate?
Date: Thu, 23 Mar 2000 08:28:17 GMT
Any estimates on said collection bandwidth in bits per second?
ddqbb
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Wouter <[EMAIL PROTECTED]>
Subject: experiences with cryptlib toolkit?
Date: 23 Mar 2000 08:43:45 GMT
I was wondering if anyone has experience with the cryptlib
toolkit (http://www.cs.auckland.ac.nz/~pgut001/cryptlib/)
Is it any good/reliable/easy to use?
It it better or worse then the PGP SDK?
What are the strengths and weakenesses?
--
Wouter
wouterke at xs4all.nl
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: NIST publishes AES3 papers
Date: Thu, 23 Mar 2000 00:44:14 -0000
I still have my doubts about triple-DES, there has been very
little analysis done on it, relative to the AES finalists. I
feel it is well established that changing the slightest
thing about a cipher voids all prior assurances of strength.
In the case of triple-DES , you have tripled the number of
rounds, exponentially increasing the odds of a reduction
algorithm. Also the maximal strength of 3DES if 112 bits,
best attacks on the AES finalists put the strength in excess
of 127 bits. I find little reason to go with 3des over an
aes finalist.
Joe
"David A. Wagner" <[EMAIL PROTECTED]> wrote
in message
news:8bcco2$17b$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>,
> Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
> > "Resolved, that if NIST selects multiple cipher
"winners" then the candidate with the largest margin of
strength should be one of them even if it is not close to
_optimal_".
>
> You mean, Triple-DES?
> (It's hard to imagine how any of the AES candidates
> can be considered to have a larger margin of strength than
> Triple-DES, at least if one considers assurance of
security
> today and amount of analysis done to date.)
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Hashing Algorithms. (basic newbie question)
Date: Thu, 23 Mar 2000 00:38:55 -0000
"@" <[EMAIL PROTECTED]> wrote in
message news:8baobf$791$[EMAIL PROTECTED]...
> Why are there no hashing algorithms using Pseudo-Random
number generators?
It all depends on how you view the algorithm. If you view
them correctly, a hash function takes an input seed and uses
that seed to generate a pseudo-random number, making it a
pseudo-RNG.
> Why not perform a simple little digest on the message and
use it to seed a
> random number generator, then produce a random stream of
160bits?
It can only be as secure as your simple little digest. If
your SD() is say 40-bits (or the equivalent), I can check
all 2^40 inputs in a fair amount of time, and see if the
output matches the pRNG.
> How secure is this approach?
Only as secure as your SD.
However your first question bears some investigation. I
suppose it would be possible to create a pRNG that can
accept any size input, where each bit of that input
influences each bit of the output stream. However making
this cryptographically sound would be quite a feat, as I
recall there is an example of something similar, but the
name escapes me at the moment.
Joe
------------------------------
** 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
******************************
