Cryptography-Digest Digest #761, Volume #9 Thu, 24 Jun 99 15:13:03 EDT
Contents:
Re: 1024-bit block cipher ([EMAIL PROTECTED])
Re: Secure broadcast ([EMAIL PROTECTED])
Re: one time pad ("Tony T. Warnock")
Re: one time pad ("Tony T. Warnock")
Re: Possible stream cipher? (Barry Herman)
Re: one time pad (Patrick Juola)
Re: card shuffling related to rc4? (John Myre)
Re: Encryption Algorithm Functional? (Medical Electronics Lab)
Re: one time pad ("Tony T. Warnock")
Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length? (Medical
Electronics Lab)
Re: one time pad (Greg Ofiesh)
Re: Encryptor that fits on a disk? (Fauzan Mirza)
Re: Kryptos article ("Renegade")
Re: Kryptos article (Jim Gillogly)
Re: On an old topic of internet publication of strong crypto ("Brian Gladman")
Re: one time pad (Greg Ofiesh)
Re: one time pad (Greg Ofiesh)
Re: card shuffling related to rc4? ([EMAIL PROTECTED])
Re: one time pad (Greg Ofiesh)
Re: RC4 Susectability (Fiji)
Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length? (DJohn37050)
Re: one time pad (Greg Ofiesh)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 1024-bit block cipher
Date: Thu, 24 Jun 1999 14:48:21 GMT
Tom,
some more remarks.
>2. 1024-bit blocks are only good for static objects (or small
> objects). Consider a 'difficult' problem like RSA, ElGamma, etc...
With regard to my algorithm I would like to have the same problems
with money as RSA.
There are a lot of bad RSA-key pares.
Some RSA-keys transform plain text in to the same plain text.
This means that in PGP certificate under Base64 encoding can be
sent information in plain text.
Some RSA-keys do symmetric encryption.
As I know no implementation of RSA-key generator checks if a
key may be assigned for usage.
For more details please take a look at my RSA study at
www.online.de/home/aernst
The link is 'RSA-null security'
Regards
Alex
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Wed, 23 Jun 1999 23:00:44 -0400
From: [EMAIL PROTECTED]
Subject: Re: Secure broadcast
Gene Sokolov wrote:
>
> Medical Electronics Lab <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > I'd push real hard for more bits now. A 1 GHz computer for US$500 is
> > only 2 years away.
>
> Customers are already screaming bloody murder over 10 char passwords. About
> 15% of support calls are "my password does not work". It's just hard to tell
> 0 from O and l from 1 or I. Then 60% of the customers change passwords to
> something short and easy.
This isn't a crypto issue, it is a human factors issue. Two
suggestions: First, use character set mapping to eliminate character
confusion (both O and 0 become 0; both l and 1 become 1). This will
cost you a fraction of your key space.
Second, present the passwords in blocks of 5 characters or less. Three
blocks or four or five characters is much easier to remember, enter, and
read than a single block of 10. It also gets you a key space "big
enough" for 5 years <SWAG flag>.
>
> > > On the other hand, use of RSA would require key management &
> royalties.
> > > That's something to be avoided. Is there a known way to convert
> > > password->symmetric key?
> > > How about hashing user id + password + random number and using the
> hash
> > > as a key to symmetric cypher to encrypt the session key? Individually
> > > encrypted session key and random number(s) would be transmitted openly
> with
> > > the stream.
> >
> > Public key isn't needed. If you have each clients private key,
> > you can broadcast the session key to all clients, encrypted with
> > each clients private key. Only the client with a good private key
>
> Ok, that's what I thought too. Except I wanted that private key to be
> calculated from the user password. Originally I wanted to xor a one way hash
> of password + user ID + random number with the session key. But then if the
> session key is encrypted instead of xored, random number would not be
> needed.
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Thu, 24 Jun 1999 10:09:35 -0600
Reply-To: [EMAIL PROTECTED]
Patrick Juola wrote:
> In article <7kskco$tou$[EMAIL PROTECTED]>,
> Greg Ofiesh <[EMAIL PROTECTED]> wrote:
> >
> >I thought Statistical randomness ment:
> >
> >> >is ment that the digits are generally well distributed, and that they
> >> >occur approximately as often as each other- that 1' occur as
> >> >frequently, as 2's which occur as frequently as..., you get the idea.
> >
> >
> >Are you certain that this definition is not correct? Is this not what
> >you call statistical trends? i.e.- even distribution.
>
> It's correct as far as it goes, but it's not sufficient.
>
> For example, the sequence
>
> 0.1234567891011121314151617181920212223...
>
> has provably uniform distribution... about as many 1's as 2's, &c,...
> but is also very easily predictable, in the sense that if I am
> given the previous digit (or several digits), I can easily guess
> what the next one is.
>
> Statistical randomness for the purposes of the OTP requires not only
> uniform distribution, but also independence -- each digit is
> independent of every other and knowing a particular number doesn't
> help you guess its neighbors. Pi doesn't have this independence.
>
> -kitten
Also, the pairs have uniform distribution, etc. All n-tuples have uniform
distribution for any finite n. Its a Normal Number.
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Thu, 24 Jun 1999 10:01:03 -0600
Reply-To: [EMAIL PROTECTED]
Greg Ofiesh wrote:
> Predictability-
>
> A true random bit generator (RBG) can produce 400 zeros, but this is
> undesireable. Therefore, a true RBG is not desired.
>
Why do you say that this is undesirable? The probability of 400 zeros is
small.
>
> Predictability can be hampered by limitations, but it turns out that
> predictability is not an issue. The issue is minimizing patters while
> maximizing message candidates that the opponent must choose from. And
> every message candidate must be given the illusion of having the same
> probability of being correct as the correct message has.
>
It is not an illusion with an OTP.
------------------------------
From: Barry Herman <[EMAIL PROTECTED]>
Crossposted-To: alt.security
Subject: Re: Possible stream cipher?
Date: Thu, 24 Jun 1999 11:30:20 -0400
Okay... let's begin
The problem with the design is the definition of "random". If something
is truly random, then it cannot be reliably reproduced.
A random number generator is incredibly difficult to build. Requires much
hardware and engineering know-how to avoid introducing bias in the system.
What you've described is more accurately called a Pseudo-Random Number
Generator (PRNG). A PRNG is essentially a mathematical formula that
takes a number (seed) as it's input, produces an output, and uses that
output as the next input. The problem with PRNGs is that they *all*
cycle. By cycling I mean it returns to a state where the output is the
input.
Assume the PRNG is (seed * 10) mod 7 seed=5
50 mod 7 = 1 (50 - 1 = 49 mod 7 = 0) 1 is used as the next seed
10 mod 7 = 3 3 is used as the next seed
30 mod 7 = 2
20 mod 7 = 6
60 mod 7 = 4
40 mod 7 = 5 notice that this is the initial state
50 mod 7 = 1 and the chain continues
The length of the cycle (in this case 6, because it cycles on the 7th
step) is dependent on the formula used in the PRNG. PRNGs used in actual
programs are much more complicated, and longer, but still cyclic.
Can it be broken? Yes.
By figuring out the length of the cycle, redundancies can be exploited and
the text broken (search for references on the "two-time pad")
Comments and criticisms appreciated.
- Barry
+------------------------------------------------------------------------+
| Barry C. Herman "If after every tempest came such calms, may the |
| [EMAIL PROTECTED] winds blow till they have wakened death" - Skspre |
| http://www.umbc.edu/~bherma1 PGP key available from web site |
| PGP fingerprint: F8 F6 87 EC 58 C3 5C 3A 20 2A F6 4F 95 3E B7 7B |
+------------------------------------------------------------------------+
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: one time pad
Date: 24 Jun 1999 12:48:56 -0400
In article <[EMAIL PROTECTED]>,
Tony T. Warnock <[EMAIL PROTECTED]> wrote:
>
>
>Patrick Juola wrote:
>
>> In article <7kskco$tou$[EMAIL PROTECTED]>,
>> Greg Ofiesh <[EMAIL PROTECTED]> wrote:
>> >
>> >I thought Statistical randomness ment:
>> >
>> >> >is ment that the digits are generally well distributed, and that they
>> >> >occur approximately as often as each other- that 1' occur as
>> >> >frequently, as 2's which occur as frequently as..., you get the idea.
>> >
>> >
>> >Are you certain that this definition is not correct? Is this not what
>> >you call statistical trends? i.e.- even distribution.
>>
>> It's correct as far as it goes, but it's not sufficient.
>>
>> For example, the sequence
>>
>> 0.1234567891011121314151617181920212223...
>>
>> has provably uniform distribution... about as many 1's as 2's, &c,...
>> but is also very easily predictable, in the sense that if I am
>> given the previous digit (or several digits), I can easily guess
>> what the next one is.
>>
>> Statistical randomness for the purposes of the OTP requires not only
>> uniform distribution, but also independence -- each digit is
>> independent of every other and knowing a particular number doesn't
>> help you guess its neighbors. Pi doesn't have this independence.
>
>Also, the pairs have uniform distribution, etc. All n-tuples have uniform
>distribution for any finite n. Its a Normal Number.
... and STILL fcsking useless for cryptographic purposes.
Which was the original point about the incompleteness of Mr. Ofiesh's
definition, of course.
-kitten
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: card shuffling related to rc4?
Date: Thu, 24 Jun 1999 09:40:20 -0600
[EMAIL PROTECTED] wrote:
>
> Eyal Soha wrote:
> > The RC4 expansion is similar to the shuffling of a deck of cards
> (128).
> > So if RC4 has a skew toward some shufflings more than others, then
> you can
> > might know in what order to perform a brute-force attack on rc4.
> Which
> > makes it weaker, yes?
>
> No. The RC4 key schedule uses an 8-bit feedback with 2^8 steps so that
> each card is shuffled with a random card. The code resembles
>
<snip>
I'm sorry, Tom, but Eyal Soha has a point. Not all RC4 shufflings
are equally likely. You'd have to be a lot smarter than me,
however, to turn this weakness into an attack. The possible
number of states of RC4 is so huge that I suspect there is no
*practical* problem.
A simple argument shows that there *must* be some shufflings
that are more likely than others. There are 256! possible
orders. This number is divisible by 3 (and by every other
prime number less than 256). The number of possible keys
for RC4 is 256^n, for any given key length (n bytes). Every
key is equivalent to some 256 byte key, so there are 256^256
possible keys altogether. All of these numbers are just
powers of 2. It cannot come out evenly.
Of course, the above argument says nothing about how far out
of balance the probabilities are. It is possible that each
shuffling is just about as probable as any other. Maybe RSA
Labs knows the answer.
John M.
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Encryption Algorithm Functional?
Date: Thu, 24 Jun 1999 11:48:11 -0500
Nathan A. Baker wrote:
> My background is in scientific computing and some applied
> math, but all on the PDE/integral equation side of things.
> I know very little about the harder stuff of math. As such,
> this question is most likely very poorly posed and probably
> rather ignorant -- please forgive me in advance. :)
Number theory isn't "harder" than PDE, but it's surely
different.
>
> I was wondering how cryptanalysis problems are formulated.
> Given a nonlinear partial differential equation,
>
> N(u) = f
> [....]
> Is there a similar formulation for cryptographic problems?
> In other words, if my encryption algorithm is some nonlinear
> operator on the vectors P (plaintext) and K (key) to give
> a ciphertext C
>
> N(P,K) = C
>
> is it possible to define a functional with respect to
> P or K whose minimizer/maximizer corresponds to the solution?
> Would such a (free energy?) functional even be bounded?
In the functional abstract, yes there are similar ways of
doing things. But you don't usually use derivatives, you
use differences.
My bet is you'd have a blast learning the number theory and
cranking on some functions. Check out Koblitz' book "A Course
on Number Theory and Cryptography".
Patience, persistence, truth,
Dr. mike
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Thu, 24 Jun 1999 10:06:01 -0600
Reply-To: [EMAIL PROTECTED]
Greg Ofiesh wrote:
> > Not true -- utter urban legend. PI has noticable statistical trends,
> and
> > it's very well approximated by very simple functions.
>
> I thought Statistical randomness ment:
>
> > >is ment that the digits are generally well distributed, and that they
> > >occur approximately as often as each other- that 1' occur as
> > >frequently, as 2's which occur as frequently as..., you get the idea.
>
> Are you certain that this definition is not correct? Is this not what
> you call statistical trends? i.e.- even distribution.
>
Identical and independent distribution. (Actually this doesn't guarantee
non-predictability.) Independence in more inportant.
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length?
Date: Thu, 24 Jun 1999 12:18:48 -0500
Robert Harley wrote:
> Yes, I am aware of your program! It is great that something is
> available, but it is not nearly enough to really solve the problem, IMO.
>
> Ideally one would like to pick a size like 256 bits or 400 or
> whatever, and run through a bunch of random curves of that size until
> one (or its quadratic twist) has almost prime order, and do so in a
> reasonable amount of time. It would also be nice to be able to pick
> curves defined over fields of characteristic 2.
There are several papers that describe how to do this. I wouldn't
mind some help in understanding them so I can write the code. Send
me e-mail via [EMAIL PROTECTED] and lets get the job done!
Patience, persistence, truth,
Dr. mike
------------------------------
From: Greg Ofiesh <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Thu, 24 Jun 1999 16:42:54 GMT
> > How many aeons did you say you had to look through this list?
>
> It's irrelevant. The point is that as long as 100 0xa7's in a row is
> exactly as likely as any other sequence of 100 characters, the
> attacker has no better idea that this particular decryption is valid
> compared to all the others that his criteria says are plausible.
This is exactly what I disagree with. First, the odds that 100 0xa7's
would occur are astronomical. Then the fact that a valid candidate
would math anything is astonomical (since they all have 1 in
astronomical chances). But then you combine the two and you have
astronomical squared. That has got to give weight, don't you think?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Fauzan Mirza <[EMAIL PROTECTED]>
Subject: Re: Encryptor that fits on a disk?
Date: 24 Jun 1999 17:48:02 GMT
Reply-To: [EMAIL PROTECTED] (Fauzan Mirza)
[EMAIL PROTECTED] wrote:
> Hello,
> I am looking for an encryptor that could be used from a single floppy
> disk. I wish I could use PGP but unfortunatly its just to big.. plus
> the system I am working on gives me limited admin.. no installs
> basicaly. I remember seeing once a program that did a number of
> algorithms and had high bit keys.. but I forgot the name.. If you know
> of one.. that fits my bill.. please let me know.. Thanks
A few years ago, I wrote a free small encryption program based on the
IDEA cipher. It was designed to be small enough to fit on a single disk
sector (ie, under 512 bytes). There's more information at:
http://fermat.ma.rhbnc.ac.uk/~fauzan/tinyidea/index.html
There is a newer version, written by Mark Andreas, which can be found
from his home page:
http://www.sky.net/~voyageur
His version is subject to ITAR.
Fauzan
------------------------------
From: "Renegade" <[EMAIL PROTECTED]>
Subject: Re: Kryptos article
Date: Thu, 24 Jun 1999 12:24:54 -0500
> > Renegade wrote:
> > > This is another example of how the NSA/IC is years ahead of the
> > > private sector, ...
> >
> > While I would agree with that in many cases, I suspect the Kryptos
> > cracking was done with pretty much the same technology and skills
> > that were applied by Gillogly. The CIA cracker is said to have
> > done it as mainly a pencil-and-paper exercise, and perhaps the NSA
> > cryppies tackled it on the same terms. (That would explain why it
> > took them so long!)
What I really meant was not the technical ability, but the fact that they
did it and chose to remain silent for years, on a clearly unclassified
problem.
>
> I think in this case, their cracking it long before the rest of us
> mostly had to do with their having easy access to it before the rest
> of us did
Yes, this is true. And from what I recall, Jim solved it in less than 10
days, quite an accomplishment, and "10 days" is the better number to use as
a reference.
During the NBA game I saw reference to a possible Today Show segment that
would air this am, but missed it. Did anyone see it?
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Kryptos article
Date: Thu, 24 Jun 1999 11:31:12 -0700
Renegade wrote:
> Yes, this is true. And from what I recall, Jim solved it in less than 10
> days, quite an accomplishment, and "10 days" is the better number to use as
> a reference.
Four evenings, actually. I've spent quite a few hours since then trying
to solve the fourth segment, with no progress worth noting... just a few
possible statistical anomalies for which I'm trying to construct models.
The danged thing is so short!
> During the NBA game I saw reference to a possible Today Show segment that
> would air this am, but missed it. Did anyone see it?
They bumped it because of a KKK trial that ended recently. The current
tentative air date is tommorow (Friday); no more specific time yet. With
any luck my Dundee Marmalade crock will be visible next to my elbow. No,
I'm not a member of the Dundee Society -- this was a case of "If you buy
an outfit you can be a cowboy too."
My wife thought the gorilla banging on the window at the Bronx Zoo on the
Today Show looked rather like me. I acknowledged the resemblance, but
pointed out that it had more hair on top than I do, and she was forced to
recant.
--
Jim Gillogly
1 Afterlithe S.R. 1999, 18:25
12.19.6.5.9, 13 Muluc 17 Zotz, First Lord of Night
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: On an old topic of internet publication of strong crypto
Date: Thu, 24 Jun 1999 19:37:30 +0100
Mok-Kong Shen <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] wrote:
> >
>
> > The way ITAR was implemented, importation from outside UKUSACAN
> > didn't matter; what mattered was whether or not strong crypto
> > was available from a US-based webserver to non-UKUSACAN nationals,
> > wherever they happened to reside or to be when they obtained the
> > strong crypto. This is from memory, of course, and so I Could
> > Be Wrong. But I think I got the main part right.
>
> What if the author does not have the text of his paper at his site
> but simply provides a link to the page on the foreign server (which
> in this case has to keep the material for longer time)? For access
> by the reader it makes no difference at all whether what the link
> points to is stored locally or remotely, thanks to the design of
> the world wide web. Should even that be objected to, he can simply
> write that a paper is available overseas at www.xxx.yyy (i.e. without
> the mouse click functionality). Now this last is a pure reference,
> like any literature references found at the end of a scientific paper.
> I doubt whether even an authority of a country under the worst
> dictatorship of the modern world could forbid such references.
> Any nation claiming to be democratic certainly could not afford that
> kind of censorship.
>
> M. K. Shen
I might point out that the US government in the form of NIST has a link on
the NIST AES page to my page at:
http://www.seven77.demon.co.uk/cryptography_technology/Aes/index.htm
where there is a lot of crypto source code so I don't think that this can be
illegal in the US! There are also links to other pages with source code as
well.
And I have a letter from a uk government official indicating that my page is
quite legal.
Brian Gladman
------------------------------
From: Greg Ofiesh <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Thu, 24 Jun 1999 18:26:59 GMT
> > I wish my
> > correspondences to remain at the highest technical level possible.
>
> How ironic...
Actually, there are a lot of good posts that have made me think
critically of my initial approach. As a result I have really driven
down the issues for myself.
> No, suppressing "patterns" *reduces* the randomness of the keystream.
And this is one good example. In another post, I point out that I
realize now that randomness is not the issue but building a pad without
any long term patterns is important.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Greg Ofiesh <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Thu, 24 Jun 1999 18:36:28 GMT
> I disagree. If, for example, 0x00 appears 20 times
> in a row, then the plaintext for those 20 characters
> will show up in the ciphertext. The problem is that
> the attacker has NO way of guessing that this is
> really the correct plaintext. Without knowing
> up-front that there's a 20-byte run of zeros in
> the key, he has no more reason to guess the
> plaintext is showing through unchanged than any other
> run of 20 characters.
Given the message and the cipher stream, one can derive the pad segment
between them. Examining the pad segment, one would immediately realize
that the odds of 20 0's are astronomical. The plain text as well is an
equally astronomical candidate (all candidates have same astronomical
odds of being correct). But when you have one astronomical event
coincide with another, that cannot be coincidence. Thus patterns to
the naked eye must be avoided in the pad.
What say you?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: card shuffling related to rc4?
Date: Thu, 24 Jun 1999 18:40:48 GMT
In article <[EMAIL PROTECTED]>,
John Myre <[EMAIL PROTECTED]> wrote:
> I'm sorry, Tom, but Eyal Soha has a point. Not all RC4 shufflings
> are equally likely. You'd have to be a lot smarter than me,
> however, to turn this weakness into an attack. The possible
> number of states of RC4 is so huge that I suspect there is no
> *practical* problem.
>
> A simple argument shows that there *must* be some shufflings
> that are more likely than others. There are 256! possible
> orders. This number is divisible by 3 (and by every other
> prime number less than 256). The number of possible keys
> for RC4 is 256^n, for any given key length (n bytes). Every
> key is equivalent to some 256 byte key, so there are 256^256
> possible keys altogether. All of these numbers are just
> powers of 2. It cannot come out evenly.
>
> Of course, the above argument says nothing about how far out
> of balance the probabilities are. It is possible that each
> shuffling is just about as probable as any other. Maybe RSA
> Labs knows the answer.
Well if the RC4 key schedule is complete (as a whole of the valid
inputs) then there are 2^1683.99628722421461940614767931775 possible
states which equates to a key of 210.499535903026827425768459914719
bytes. You are correct to say that if you shuffle the deck 256 times
with a 256 byte key some states will repeat. However this is not true
for keys <= 210 bytes so is not an issue. When you use a n <= 210 byte
key there are 2^8n possible states. If the schedule is complete each
of the 2^8n states are unique.
The arguement should be whether it's complete or not, but I have good
reason to think it is (or pretty darn close). Let's take this for
example
y = 0
for i = 1 to 210
x = key[i]
y = (y + state[x]) mod 256
swap (state[x], state[y])
next i
This would be complete for 210 byte (random non repeating) keys only.
If the key repeats it will not work. The current key schedule repeats
the keys but uses the index i (0 < i <= 256) as the second shuffling
index. It relies on the fact y will be random for each iteration per
key.
I would have to sketch it out (I am confusing myself) but I think all
keys <= 210 bytes should produce unique states, and the frequency of
repeat states is probably sufficiently low as not to be a break.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Greg Ofiesh <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Thu, 24 Jun 1999 18:38:00 GMT
> What does this mean? If by ``maintaining statistical randomness''
> you mean ``drawing without replacement from a uniform pool,''
> then I'd just like to point out that drawing without replacement
> isn't a good model for the phenomena under discussion.
Yes, this is all it can mean.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Fiji <[EMAIL PROTECTED]>
Subject: Re: RC4 Susectability
Date: Thu, 24 Jun 1999 14:33:07 -0400
On Tue, 22 Jun 1999 [EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> fungus <[EMAIL PROTECTED]> wrote:
> > Completely secure (in the sense that "a brute force search
> > is the best known attack").
>
> If using the same key twice is insecure then the algorithm is not
> bullet proof.
hmm does that mean then that an OTP is insecure? It is best not to use the
same key twice for an OTP. So by your logic, an OTP in inherently not
bullet proof. Now I realize that an OTP is difficult to use but difficult
to use is not the same as not being bullet proof.
-Fiji
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length?
Date: 24 Jun 1999 19:04:04 GMT
Note that the NIST curves fall into 3 groups:
1. Random over Fp
2. Random over F2**p
3. Koblitz over F2**p
where p is a prime.
This says to me that these specific curves are "good".
Don Johnson
------------------------------
From: Greg Ofiesh <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Thu, 24 Jun 1999 18:54:56 GMT
> > ... If a pure and perfect (okay, theoretical) random generator
> > can produce any sequence of bits, and no bit is dependent on any
> > other, then you could theoretically produce streams of obvious
> > patterns. ... And this should produce weaknesses in the pad.
>
> No, it doesn't.
You have a candidate message for which the odds are (equal to all other
candidates) one in astronomical odds and the pattern of the pad segment
that is required from the cipher stream is all 0's, also one in
astronomical odds. Does this seem to you more than a coincidence? And
therefore a weakness?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
