Cryptography-Digest Digest #912, Volume #8 Fri, 15 Jan 99 19:13:04 EST
Contents:
Re: Cayley-Purser algorithm? (Doug Stell)
Re: Cayley-Purser algorithm? (David P Jablon)
Re: Visual Basic Cipher ("Oliver Keeling")
Re: SSL - How can it be safe? (Doug Stell)
Re: Some Non-Random DES Characteristics ([EMAIL PROTECTED])
Re: New Twofish Source Code Available (Medical Electronics Lab)
Re: searching protocol (Medical Electronics Lab)
Too simple to be safe ("almis")
Re: Practical True Random Number Generator (Patrick Juola)
Re: On the Generation of Pseudo-OTP (Snowhare)
Re: Contents of server gated certificates (Eric Norman)
The 'Panama' crypto function (Dale R Worley)
Re: Cayley-Purser algorithm? (John Savard)
Re: New Twofish Source Code Available (Mr. Tines)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: Cayley-Purser algorithm?
Date: Fri, 15 Jan 1999 17:38:58 GMT
On Fri, 15 Jan 1999 15:16:45 GMT, [EMAIL PROTECTED] wrote:
>Sorry. Once the method has been published, it CAN NOT be patented in
>the US.
Have the rules changed? Wasn't RSA patented in the U.S. after it was
published, else publication would have been squashed? Isn't RSA's
publication also the reason that it isn't patented outside the U.S.?
At least this is what I thought Ron and Jim both told me.
------------------------------
From: [EMAIL PROTECTED] (David P Jablon)
Subject: Re: Cayley-Purser algorithm?
Date: Fri, 15 Jan 1999 19:46:39 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>> For what it's worth, here's an unsolicited open letter to Sarah:
>> [First, publish, then ...]
>> If all goes well, you can then consider applying for a US patent.
In article <77nm4j$b9h$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>Your advice shows gross ignorance of patent law.
>Sorry. Once the method has been published, it CAN NOT be patented in
>the US.
I think you'll have to eat those words. :-)
U.S. law permits up to a year from date of first publication to filing.
In this regard, it is still different than other countries.
But don't trust me. Read the second paragraph of:
<http://www.uspto.gov/web/offices/pac/doc/general/novelty.htm>
-- dpj
------------------------------
From: "Oliver Keeling" <[EMAIL PROTECTED]>
Subject: Re: Visual Basic Cipher
Date: Fri, 15 Jan 1999 18:44:07 GMT
Errr nope - ya got 3 now!! Most of the stuff I have tried with VB works
(although my knowledge of encryption techniques is still at the bottom of
the learning curve) BUT it is soooooooooo slow!!
Any information going on VB I would be grateful to be part of!
All the best
Olly
Jessica Anderson <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>Yes. Well, I guess it depends on how secure/fast you want it. With my
limited
>knowledge, I've made some pretty hefty byte/bitwise encryption schemes.
None
>as sophisticated as having asymetrical keys or even large primes. Ive found
>ways of doing hefty things with xors but those are relatively insecure.
>
>If someone could maybe help me find a way to generate large primes in vb
>using eulers method maybe then we could start a sci.crypt.vb or just have a
>thread in here for VB stuff. I have to believe that there are more than two
>people trying.
>
>Best of luck to you and any questions can be emailed to me at
>[EMAIL PROTECTED]
>
>-Jess
>
>CYFer wrote:
>
>> Is it possible to make a secure encryption system using VB, without using
>> any outside ActiveX?
>
>
>
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: SSL - How can it be safe?
Date: Fri, 15 Jan 1999 17:33:51 GMT
On Fri, 15 Jan 1999 10:39:54 -0500, "Joseph Suriol" <[EMAIL PROTECTED]>
wrote:
>If there is a public key system at work, why does it need random component?
It doesn't need a random component. However, you would like a
different key and different cipher for each connection. This helps
thwart a number of attacks against both the cryptography
(cryptanalysis) and the protocol (replay and other attacks).
>Why can't the system just use the target's public key, obtained from a key
>bank?
A long-term public key is used also for authentication, where the key
and its owner are bound together in a trusted manner. You also want
something short-term or ephemeral for the reasons described above.
> Each node must then keep its private key secure,
>is there a way to do that other than file permissions?
Encryption. The private key can be stored in "black" by encrypting it
with a key derived from the password. Here again, you will want to
append a random component to the password, hash the concatenation to
make the encryption/decryption key and store the random component.
This will help thwart dictionary attacks against the password.
>I know use and know PGP (read the O'reilly book); have read a good part of
>Schneier's book, but I am no expert.
That's a good start for sure, but it is a very big field. I'm still
learning at a terrific pace after being at it for 20 years.
> My company cannot afford to buy the Oracle SSL
>product and want me to write an encryption module to insert suitably between
>Oracle based applications clients and servers. I am starting from first
>principles.
Be sure to read such papers as "Why Crypto Systems Fail" which is
available on the Counterpane web site. Good implementation is as
important as good cryptography. This is where one needs a lot of
experience playing "Spy vs. Spy," to borrow a term from Mad Magazine.
Also read some texts on network security, look at the IETF's work in
the IPSEC, PKIX and SMIME working groups, get some security tutorials
and course material from any of the many web sites people in this
newgroup maintain.
>If two independent system can compute the same session key, doesn't then the
>secrecy of the key reside in keeping the algorithm and its seeds secret? I
>thought this was a bad thing to do.
The algorithm should not be considered to be secret. "Security by
obsecurity" is not worth much and all security is lost once the
details become known. You must assume that the adversary has the
details of your system. It's the math that protects the shared secret
from any third parties.
In such a system, the only things that need to be highly protected are
the following for the reasons stated.
1. long-term private keys, which enable a third party to masquerade as
a legitimate party
2. any seed/state of a pseudo-random number generator, which enables
one to guess future random numbers. Use a cryptographically strong
source, not rand().
3. short-term session keys and other random components, which would
allow an attack against that session.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Some Non-Random DES Characteristics
Date: Fri, 15 Jan 1999 19:08:13 GMT
In article <77ml4o$9ip$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Matthew Skala) wrote:
> In article <77ietq$rh0$[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]> wrote:
> >Further, due to its mathematical generality, I suppose that the
> >"hash-function" argument advanced in item (d) and applied also in item
> >(g) would be valid to a broad range of plaintext statistics, not just
> >English and not just natural languages.
>
> >Further application of these results are reported in [Ger99], using
>
> As far as I can tell, the result presented in this document is that if you
> mount a brute-force attack, you can break DES - noting that you only have
> to brute-force the 56-bit key space, not the 64-bit space of possible
> blocks. That's hardly news.
Sure, this much is no news and also of no use to help break DES by
brute-force.
>Or am I misunderstanding the document?
Yes -- or, perhaps I was not clear enough. What I am saying is:
1. DES is not a random-cipher, not even within one 8-byte block, so
theoretical derivations that depend on this assumption need to be
reconsidered, specially unicity and those that try to define what is a
correct (yet, a priori unknown) key.
2. The important question in a brute-force attack is "What is a correct
key?". This question is usually answered either by looking to the set of
possible decipherments or to the set of impossible decipherments -- or, to
both. However, the exposition shows that almost ALL decipherments done with
wrong keys are impossible for natural or compressed English (as an example)
statistics. If DES would be a random-cipher -- even within 56-bits -- one
could expect to have at least 2^8 times more possible decipherments. A large
difference and a large ambiguity which is "avoided" by DES 56: 64 ratio.
3. The first "help" from DES is thus that by pre-selecting the keys with just
one DES block, it is expected to arrive at a few possible keys -- between 3 to
300. If DES would be a random cipher -- even with 56 bits -- this would have
been 256 times larger.
4. By using the expected language statistics, even within compression since
compression is just a code translation, one should be able to use the
language's unicity (eg 5 letters, for English) and uniquely decide which of
the 3 ~ 300 wrong keys are wrong.
5. The second "help" from DES is that if more than one key is left at step
(4) above, it can be shown that using just one more block just for those keys
should allow an unambigous decision with pratically unity probability.
There are other points, but these are the main ones. The bottom-line is that
one can decide when to stop the search by using just one block of DES (over
the currently quoted value of three) and that the number of possible messages
that need to tested is very small -- since the majority is just clear
garbage.
Thus, DES brute-force attacks can be 3x faster than hitherto imagined.
BTW, a newer version is available at http://www.mcg.org.br/nrdes.txt
Thansk for some comments received in private. I will incorporate some of the
above in the text, to address your questions.
Comments?
Thank you,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck [EMAIL PROTECTED]
http://novaware.com.br
--- Meta-Certificate Group member -- http://www.mcg.org.br --->
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: New Twofish Source Code Available
Date: Fri, 15 Jan 1999 12:57:26 -0600
Bruce Schneier wrote:
> No. It makes no sense to. These are all performance improvements,
> and there's really no such thing as good performance in Java (for
> pretty much of anything). Any application that needs good encryption
> performance won't do it in Java.
I whole heartedly agree with this! Thanks Bruce, I'm glad I'm not
the only one who thinks this way.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: searching protocol
Date: Fri, 15 Jan 1999 13:04:53 -0600
[EMAIL PROTECTED] wrote:
> i am searching for a protocol to be carried out by 2 parties with the
> following properties:
>
> both A and B know some (short, approx 8 byte) private secret.
>
> A and B want to verify that they both got the same secret - without revealing
> any information to the partner what the secret is when the protocol says
> 'different'.
>
> there is no secure channel between A and B.
>
> an eavesdropper must not learn anything when listening to the messages
> exchanged by A and B.
>
> the protocol must not depend on a third party.
>
> any suggestions ?
Do a web search on "zero knowledge". You may want to add the words
"proof" and "protocol" to that. The basic idea is that they trade
random numbers and use the secret to generate some other random number.
The random numbers can be transmitted in the clear, and unless there
is a match, both sides don't know what the other side has.
Patience, persistence, truth,
Dr. mike
------------------------------
From: "almis" <[EMAIL PROTECTED]>
Subject: Too simple to be safe
Date: Fri, 15 Jan 1999 13:11:47 -0600
For a symmetric (shared) key cryptosystem there are many complicated
schemes.
I thought of one that seems too simple to be safe.
The basic idea is the conjecture that the square root of a prime number is
always irrational.
If the above is true then ...
1. Generate a large prime p. (the shared key)
2. Calculate the irrational number n = SQRT(p)
3. N is the fractional part of n. that is N = n - Floor(n)
N is a sequence of non-repeating numbers.
4. Chose an index pointer, x.
5. Encode the message with N starting at x.
6. Send the encoded message and the pointer.
7. Decode the message by recalculating N and start at x.
That's it!
The concept begs two questions:
(1) How difficult is it to find the square root of a prime to an arbitrary
length?
(2) Given a sequence of digits of a known length and starting at a given
position how difficult would it to be to recover the prime number that
generated it?
Fud for thought ...al
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Practical True Random Number Generator
Date: 14 Jan 1999 11:30:15 -0500
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>On Tue, 12 Jan 1999 20:42:30 +0100, Mok-Kong Shen
><[EMAIL PROTECTED]> wrote:
>
>>Sorry to say that after having read in another thead many occurences
>>of the term 'Bayesian Attack' I still have yet no concrete idea of
>>an implementation of such an attack. I mean I am still ignorant of
>>literatures that enable me to try to lauch such an attack on
>>a given cipher.
>
>That makes two of us. You might want to read the post from Patrick
>Juola today.
>
>I also asked him to give us some introductory text book references.
...
So it took me a few days. I've gotten several independent
recommendations for Gelman, et al. (1995) _Bayesian Data Analysis_,
published by Chapman and Hall. I've also gotten a recommendation
for Donald Berry's new textbook, although I don't have a title
for that. he's currently at Duke (stat.duke.edu) and it's probably
listed on a web page or something recently.
In terms of literature relevant to Bayesian methods of cryptanalysis --
well, I probably *could* write such a textbook, and I might be able
to see three copies to my IMMEDIATE circle of friends, and my mother
might buy one if she could find a magnet strong enough to hold it
onto the refrigerator. You see the problem; there's just not enough
of a market for such literature outside of the specialist journals.
Mr. Shen is, of course, correct that to apply a Bayesian attack
to a stream cypher, the analyst must be aware that a biased generator
is being used and have some idea of what sort of bias is likely
to be present. However, this isn't that difficult to believe if
one is, for instance, using a stream cypher generated from a known
transcendental number.
-kitten
------------------------------
Subject: Re: On the Generation of Pseudo-OTP
From: [EMAIL PROTECTED] (Snowhare)
Date: Fri, 15 Jan 1999 16:26:44 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Nothing above this line is part of the signed message.
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>Propositions:
>
>1) If you can generate a number algorithmically, then it is
>non-random.
Ok.
>2) If you operate algorithmically on a random number generated by a
>TRNG, it is no longer random.
Not ok. Trivially disprovable. I algorithmically XOR a random bit
stream with '1'. It is just as random as the original bit stream.
Benjamin Franz
=====BEGIN PGP SIGNATURE=====
Version: 2.6.2
iQCVAwUBNp9st+jpikN3V52xAQGoWAP8Dq4haYU3JoEu4YxECnbH0vJeyTRm/t43
LkGPxLsP/Y+pXow7lRKVsiIi1oR5838naWp1JdkEBnfHjyAw6EhOFuXMzg+6SQTu
VeTQs2bxbuFMOfNskI+4wRUyUcn5gZEpYa7qI08CR1MBSi4DHmOwp2TGPAyskrbS
Tz2ffMmFA9Q=
=f88+
=====END PGP SIGNATURE=====
------------------------------
From: Eric Norman <[EMAIL PROTECTED]>
Subject: Re: Contents of server gated certificates
Date: Fri, 15 Jan 1999 16:37:28 -0600
Paul Rubin wrote:
> So can you load new SGC roots into the browsers???
Well if you can't, then why bother with the certificate
extension at all? Why not just wire the public key into
the code?
--
Eric Norman
"Congress shall make no law restricting the size of integers
that may be multiplied together, or the number of times that
an integer may be multiplied by itself, or the modulus by
which an integer may be reduced".
------------------------------
From: [EMAIL PROTECTED] (Dale R Worley)
Subject: The 'Panama' crypto function
Date: Fri, 15 Jan 1999 23:23:06 GMT
I've been looking at the 'Panama' cryptographic function. It is
described in the Dec 98 issue of Dr. Dobb's Journal, page 42. But
beware that there are some non-trivial errors in the article; look at
the articles at http://standard.pictel.com/ftp/research/security. The
following discussion assumes that you have the diagrams from the
article in front of you.
Now I am no cryptographer (though I do have a Ph.D. in math) but
looking at the Panama algorithm, it seems week to me. Assuming that
one is using it as a keystream generator, or crypto RNG, there is a
central function which iterates on a variable of 17*32 bits, and which
feeds bits to and is fed bits from a 32-stage by 8*32 bit LFSR.
But at each iteration, 8*32 bits of the variable are directly output
as the next increment of the keystream. This seems very insecure,
since the central function has only moderate diffusion and
nonlinearity, and we get to peek at a lot of the feedback loop.
Looking at the iteration function more carefully, I see that output
word 12 of the function (which becomes word 3 of the block that is
output to the keystream) is:
a_new[12] :=
b[16,3] (a word from the LFSR) +
rotate(a[9] + (a[10] OR NOT a[11]), ???) +
rotate(a[14] + (a[15] OR NOT a[16]), ???) +
rotate(a[12] + (a[13] OR NOT a[14]), ???)
(The ??? represent constants in the Panama design which I'm too lazy
to calculate right now.)
The point being that all of the input a[] values were output as part
of the last block of the keystream, and a_new[12] is in the current
block of the keystream, so one can calculate the 3rd word in each
block pulled from the LFSR.
This means that if we have a long segment of the keystream, we know
what the 3rd words are in each block in the first part (stages 0 to
24) of the LFSR. And since the other tap from the LFSR into the
iteration function is from stage 4, we also know its 3rd word in all
cases.
At this point, I'm past my knowledge of cryptography, but it means
that (1) we have complete knowledge of another word that goes into the
iteration function, and (2) we can probably learn the value of
a_new[4] because that word is fed back from the iteration function
into the LFSR in a way that will affect the 3rd words that we read off
the tap.
Seeing as how I'm not a cryptographer, and have managed to unravel the
system this far with only a couple of hours' work, I suspect that
Panama isn't secure against serious cryptographic attack.
Anybody else have information on Panama?
Dale
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Cayley-Purser algorithm?
Date: Fri, 15 Jan 1999 22:26:59 GMT
[EMAIL PROTECTED] wrote, in part:
>Sorry. Once the method has been published, it CAN NOT be patented in
>the US.
Although in the US, you get one year to file after publication, in
most countries outside the US, you must file for a patent prior to
publication, IIRC.
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
From: Mr. Tines <[EMAIL PROTECTED]>
Subject: Re: New Twofish Source Code Available
Date: 15 Jan 1999 22:53 +0000
###
On Fri, 15 Jan 1999 12:05:48 GMT, in <[EMAIL PROTECTED]>
[EMAIL PROTECTED] (Bruce Schneier) wrote.....
> On Thu, 14 Jan 1999 17:14:16 -0500, Uri Blumenthal
> <[EMAIL PROTECTED]> wrote:
> >code for C and Asm - so my question is: are there
> >any IMPROVEMENTS to Java code yet, similar to
> >the C code improvements maybe?
>
> No. It makes no sense to. These are all performance improvements,
> and there's really no such thing as good performance in Java (for
> pretty much of anything). Any application that needs good encryption
> performance won't do it in Java.
A (for the sake of argument) 10% speed improvement from a
larger base will save a lot more time, though. And it's
not as if Java is that far adrift from C - admittedly this is
not a best-vs-best comparison, but the IDEA code from PGP 2.6ui
compiled debug under BC++5.02 only ran 3 times faster than
a non JIT-ed Java version of the same code (using the test
harness there) in JDK 1.1.6.
-- PGPfingerprint: BC01 5527 B493 7C9B 3C54 D1B7 248C 08BC --
_______ {pegwit v8 public key =581cbf05be9899262ab4bb6a08470}
/_ __(_)__ ___ ___ {69c10bcfbca894a5bf8d208d001b829d4d0}
/ / / / _ \/ -_|_-< www.geocities.com/SiliconValley/1394
/_/ /_/_//_/\[EMAIL PROTECTED] PGP key on page
### end pegwit v8 signed text
1c0260115ad7c0f58b888a93e02cbae35e0d8549864d04ef5584995d6ea7
8b57cce11365615182cc8079560f0e5bb4cfe7fbdfd9862132e3469b4999
------------------------------
** 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
******************************
