Cryptography-Digest Digest #190, Volume #14 Fri, 20 Apr 01 10:13:01 EDT
Contents:
Re: First cipher (Mark Wooding)
Re: "I do not feel secure using your program any more." (Paul Crowley)
Re: Minimal Perfect Hashing (Paul Crowley)
Re: Basic AES question (Paul Crowley)
Re: ANOTHER REASON WHY AES IS BAD ("Tom St Denis")
Re: NON SECRET ENCRYPTION (AKA RSA) ("Tom St Denis")
Re: First cipher ("M.S. Bob")
Re: Minimal Perfect Hashing ("Tom St Denis")
Re: A practical idea to reinforce passwords (Shai Halevi)
Re: Minimal Perfect Hashing ("Francois St-Arnaud")
Re: Basic AES question (Lou Grinzo)
Re: ANOTHER REASON WHY AES IS BAD (SCOTT19U.ZIP_GUY)
Re: AES poll (SCOTT19U.ZIP_GUY)
Re: ANOTHER REASON WHY AES IS BAD (SCOTT19U.ZIP_GUY)
Re: NON SECRET ENCRYPTION (AKA RSA) (SCOTT19U.ZIP_GUY)
DSS and patents. ("Christophe Meneboeuf")
Re: DSS and patents. (Volker Hetzer)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: First cipher
Date: 20 Apr 2001 10:13:59 GMT
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Mark Wooding wrote:
> >
> > [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> [snip]
> >
> > > 2.) Key schedule to create 16 64-bit subkeys
> > > a. Split key into two 64-bit subkeys (k1, k2).
> > > b. To generate the next two subkeys, permute
> > > k1, k2 then left circular shift (LCS)
> > > the result of each permutation. The number of
> > > shifts is determined by the value of two bits
> > > (say b1,b0 for example) from the permutation output.
> > > The result of the k1 permutation, LCS(b1,b0) becomes k3.
> > > The result of the k2 permutation, LCS(b1,b0) becomes k4.
> > > c. Repeat (b) until 16 64-bit subkeys are obtained.
> > >
> > > Is the LCS(b1,b0) necessary? I wondered if a simple permutation
> > > would be sufficient since the key is assumed to be random and
> > > secret...
> >
> > This is not a good idea. The problem is that you're using real key bits
> > in the cipher. If an attack discovers some bits of a round key, it's
> > actually found some real bits of the key, and therefore bits of other
> > round keys. The rotations make life a little more difficult but not a
> > lot. I think you want something with more one-wayness.
>
> How does one find key bits in a certain round? The cryptanalyst doesn't
> get to observe the results of the round. Even if he gets to choose
> plaintext,
> all he sees is the result of 16 rounds of this "dinosaur". Why isn't a
> simple key schedule sufficient given that the key is assumed secret, and
> the cryptanalyst must solve the entire problem at once (he can't look at
> the result of individual rounds)?
Your cipher contains 16 rounds. If I can find a way to distinguish 15
rounds of your cipher from a random permutation, then I can use my
distinguisher to find the key for the last round only. I do this by
guessing the last round key: I check my guess by peeling back the last
round using the guessed round key and seeing whether my distinguisher
tells me that the remaining 15 rounds look random -- I chose the wrong
key -- or like 15 rounds of your cipher -- I guessed correctly. An
example of such a distinguisher is a differential.
In many cases, my job is easier, since I don't have to guess all the
bits of the round key at once. Indeed, in your cipher I don't.
(Don't take the dinosaur comment *too* seriously. I meant it as a joke,
referring to (a) DES's origins in an IBM research lab, and (b) the fact
that we don't tend to make ciphers like this any more because they're
rather slow in software.)
I have the feeling that I could get something like a related-key slide
to work against this key schedule, but I've not worked out the details.
Certainly, given a k_1, k_2 pair, there exists a k'_1, k'_2 pair such
that k'_3 = k_1 and k'_4 = k_2 (so k'_5 = k_3 and so on) -- this gives
us an opportunity to slide two rounds of the cipher, which isn't ideal.
Hmm. If the *same* transformation is used to derive k_3 from k_1 as to
derive k_4 from k_2 then I can find a k_0 such that encryption with k_0,
k_1 was slid one round from k_1, k_2. I think I can break this in
2^{64} requests to a device which lets me encrypt plaintext of my choice
under either your k_1, k_2 or a k_0, k_1 where I choose k_0.
> > Don't choose the S-box mappings completely at random. You need to
> > design the S-box and permutation at the same time. The most difficult
> > problem is that the F function as a whole can't be bijective. You need
> > to ensure that the maximum probability of a differential x -> 0 through
> > F is 2^-10 or less. That's a tall order. The fact that the expansion
> > gives complete overlap (unlike DES, which has only 50% overlap) protects
> > your cipher from t_i -> t_j differentials which are usually an inherent
> > problem with DES-style S-P networks. A single-bit change in the input
> > to F will definitely affect the input to two S-boxes.
>
> It seems like an S-box design would have to be optimized against a
> certain type of attack and weak against other attacks, or is the S-box
> only meant to thwart a differential attack?
The S-box is meant to provide nonlinearity. It's the main source of
`confusion' in a DES-like cipher. With small S-boxes, getting the right
trade-off between the various attacks is a little tricky (but possible).
> Why must an S-box be bijective given that the F function needn't be
> reversible?
Crash course intro to differential cryptanalysis. Let E be some block
cipher. I'll write XOR as + here, because it's easy. Choose some (any)
input, and a difference d. Now, look at d' = E(x) + E(x + d) as we vary
x (leaving d constant) -- we'll get any particular d' out with some
probability (maybe 0 if it never happens). I tend to write this as
d -> d' [p] for some probability 2^{-p} (so p might be infinite if the
differential is impossible).
It's obvious that, for any function, we have 0 -> 0 [0] (read: if we
feed in two things that aren't different to this function, the outputs
aren't different with probability 2^0 = 1; i.e., it's certain that when
we put two equal things in, we get two equal things out).
A nonbijective function whose domain isn't strictly larger than its
range must have a collision: i.e., two inputs x and x' where F(x) =
F(x'). This means that the differential d -> 0 [p] holds for some
finite p.
Once you have a collision in Feistel network's F function, something
interesting happens. Here's a diagram of a Feistel networks with
XOR-differences labelled on it:
d 0
| |
|-d->F-0->+ [ probability 2^{-p} ]
| |
d 0
| |
+<-0-F<-0-| [ probability 1 ]
| |
d 0
So we've manufactured a 2-round iterative characteristic with
probability 2^{-p}. This is precisely the structure that broke DES.
If I could find a structure like this in your cipher, I could break 12
rounds with 2^{6p} chosen plaintexts. I suspect that the two rounds at
the beginning and end can be disposed of fairly easily. (For example,
given a guess at some key bits in the last round, there are only 2^5
possible bit patterns for the key in the second round.) So you need to
ensure that 2^{6p} plaintexts is more than the cipher can produce --
i.e., that 6 p > 64. (That's where I got the 2^{-10} figure in my last
article from.)
Now, your F structure is nonbijective as it is. However, making it less
bijective (e.g., by choosing unbalanced S-boxes) will just increase the
probabilities of collisions, and make defending against the above attack
harder.
[Another bit of notation: t_i is a word with just bit i set.]
-- [mdw]
------------------------------
Crossposted-To: talk.politics.misc,alt.hacker
Subject: Re: "I do not feel secure using your program any more."
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Fri, 20 Apr 2001 11:30:28 GMT
Anthony Stephen Szopa <[EMAIL PROTECTED]> writes:
> "I do not feel secure using your program any more."
>
> You sure jumped to a hasty conclusion.
No, that's the position we always automatically start from, with any
new program. We don't start from feeling secure unless something
bothers us: we start off feeling insecure, and look for something to
give us confidence in the security.
If you understood this, perhaps you'd approach cryptology and security
altogether differently.
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
Subject: Re: Minimal Perfect Hashing
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Fri, 20 Apr 2001 11:30:28 GMT
"Scott Fluhrer" <[EMAIL PROTECTED]> writes:
> > The Discrete Logarithm Problem can be used for this.
> >
> > y = a ^ x mod p
>
> At 48 bits, the Discrete Log problem is hardly "one way"...
At 48 bits, nothing is truly "one way" - with some weeks of
precomputation, you could use the Hellman time/memory tradeoff to
build a store that would answer any preimage query in milliseconds. If
I'm thinking about this right, it should be especially easy to use
this on a bijective function.
Discrete exp is the only bijective function I can think of which isn't
straightforward to invert given the forward function. It might be
that what this inquirer wants can't be done.
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
Subject: Re: Basic AES question
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Fri, 20 Apr 2001 11:30:29 GMT
[EMAIL PROTECTED] (Lou Grinzo) writes:
> I'm just starting to learn about AES, and I was wondering:
> Why does the AES standard support only the key sizes of
> (I think) 128, 192, and 256 bits? Is it purely to keep
> the specification and logistical issues simple?
Yes.
> Or is there
> a technical reason, such as increasing the key size doesn't
> make AES any more difficult to attack? (I know that last
> one sounds goofy, but in a world where PKI works, almost
> anything is possible. <g>)
Since the most effective attack known against AES at any key size is
brute force, the larger keys are believed to increase the security.
Rijndael can be used with block and key sizes that vary in jumps of 32
bits between 128 and 256 bits, but it isn't AES unless you use a 128
bit block and one of the key sizes you list. Sufficiently confusing?
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: ANOTHER REASON WHY AES IS BAD
Date: Fri, 20 Apr 2001 11:57:06 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I don't think I mentioned this. This way but I feel another
> reason that the AES method has lead to a poor security solution
> is as follows.
>
> If one looks at the ideas in Kolmogov Complexity thoery
> where one tries to determine how random a string is by the
> length of shortest "program" that can generate the string.
> I think one can apply the same thoery to crypto. Since
> the idea is to take a low entropy string and make it appear
> to be random. It should take a fairly long program it achive
> this. But the goal of AES is to make a short program that can
> even be used on smartcards. I believe one measure of the
> potential worth of an encrytion program is the length of the
> smallest program to do the required encryption.
This is just so wrong. Look at an OTP? It's a small program yet can be as
secure as the entropy in the key. Low and behold so can a block cipher.
Plus you don't back up your thoughts with any proofs. RC5 is a small code
footprint cipher, why not find a "complexity" attack against that?
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: NON SECRET ENCRYPTION (AKA RSA)
Date: Fri, 20 Apr 2001 11:57:18 GMT
"Frank Gerlach" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> see www.cesg.gov.uk
>
No.
------------------------------
From: "M.S. Bob" <[EMAIL PROTECTED]>
Subject: Re: First cipher
Date: Fri, 20 Apr 2001 12:54:59 +0100
[EMAIL PROTECTED] wrote:
>
> "M.S. Bob" wrote:
> >
> > [EMAIL PROTECTED] wrote:
> > >
> > > Here's my first attempt at a block cipher. Please critique
> > > and explain WHY as well as where I'm going wrong.
> >
> > Short (pointers to more) reading list:
> >
> > Memo to the Amateur Cipher Designer
> > <http://www.counterpane.com/crypto-gram-9810.html#cipherdesign>
> >
> > Self-Study Course in Block Cipher Cryptanalysis
> > <http://www.counterpane.com/self-study.html>
>
> Parroting what Schneier says isn't necessary. I have a web browser and
> get the Crypto-GRAM like everyone else. How about something a little
> more
> useful, like pointers on how to cryptanalyze my cipher so I don't bug
> the
> group with the obvious?
Perhaps "Self-Study Course in Block Cipher Cryptanalysis"?
Sorry, I don't want to sound condescending, because I have no reason to
be.
If you read Schneier's first mini-essay ("memo"), I though it would be
clear that reading the materials in his "self-study course" would follow
as being a good next step. Being the suggestion on the last line of his
mini-essay.
As his says in his self-study course, there is no one good text on
cryptanalysis of modern ciphers. The CD he mentions is worth getting
BTW.
> I found a paper in the Springer-Verlag Lecture Notes in Computer Science
> Cryptography Proceedings (1982) which analyzed random, reversible
> S-boxes.
> Supposedly, if the S-box is reversible and the number of bits per table
> entry is large, then the probability of a random S-box having one or
> more bits that are linear functions of the address bits is low.
>
> So, for whatever reason, reversible S-boxes seem to be the way to go.
Remember this paper pre-dates the (re-)discovery of differential
cryptanalysis (by Biham and Shamir) at the Crypto '90 conference.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Minimal Perfect Hashing
Date: Fri, 20 Apr 2001 12:00:41 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Francois St-Arnaud) wrote in
> <ChHD6.599615$[EMAIL PROTECTED]>:
>
> >First, not that I am not at all versed in the math involved in
> >sophisticated cryptography, so please bear with me...
> >
> >I have been looking at Minimal Perfect Hashing algorithms
> >(http://burtleburtle.net/bob/hash/perfect.html in particular) in a
> >attempt to find an algorithm that fulfills the following requirements.
> >Note that MPH is probably overkill for what I need to do, but this was
> >my starting point. The fact that Bob's algorithm above requires a list
> >of all the keys to hash as a input is not viable for my application.
> >
> >I'm looking for a simple C algorithm for a function y = f(x) that would
> >take a 48-bit number x and return another 48-bit number y. f should map
> >x to y in a one-to-one fashion. f should be one-way, or at least, it
> >should not be trivial to calculate x knowing y and the algorithm used.
> >
> >Any thoughts, code snips, links?
> >
>
> Actually scott16u in the mode where no random data is used for
> padding would map a 48 bit number to 48 bit number. Based on
> some secret key. There would be no collisions.
Simpler use GF(2^48) inversion followed by some operation in Z.... That
would be highly non linear, have a low dp-maximum and have a 1-1 property.
Tom
------------------------------
From: Shai Halevi <[EMAIL PROTECTED]>
Subject: Re: A practical idea to reinforce passwords
Date: Fri, 20 Apr 2001 09:12:11 -0400
This is known as "password stretching". See, for example, a TR by Abadi
et al., available from
http://gatekeeper.dec.com/pub/DEC/SRC/technical-notes/abstracts/src-tn-1997-033.html
-- Shai
Harald Korneliussen wrote:
> I've come up with a way to reinforce passphrases
> against brute-force attacks without memorizing longer
> ones [...]
> My idea is that upon selecting a password, X bits of
> random data is added to the password. You are not
> informed of what these bits are, nor does the computer
> store them. [...]
------------------------------
Reply-To: "Francois St-Arnaud" <[EMAIL PROTECTED]>
From: "Francois St-Arnaud" <[EMAIL PROTECTED]>
Subject: Re: Minimal Perfect Hashing
Date: Fri, 20 Apr 2001 13:25:31 GMT
"Anders Thulin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Francois St-Arnaud wrote:
> >
> > I'm looking for a simple C algorithm for a function y = f(x) that would
take
> > a 48-bit number x and return another 48-bit number y. f should map x to
y in
> > a one-to-one fashion. f should be one-way, or at least, it should not be
> > trivial to calculate x knowing y and the algorithm used.
>
> Your subject says *Minimal*, but that requirement is not repeated in
> the body. Is the minimality criterion important?
Yes. I neglected to repeat this important criterion in the requirements. It
should be "minimal", meaning that n plaintexts will map to 0..n-1 ciphers
with no collisions at all. For my application, n = 2^48, x and y in
[0..2^48-1].
Regards,
Francois St-Arnaud
------------------------------
From: [EMAIL PROTECTED] (Lou Grinzo)
Subject: Re: Basic AES question
Date: Fri, 20 Apr 2001 13:23:51 GMT
Thanks to Paul and the others for responding.
As best I can tell from the replies, there doesn't seem to
be a technical reason for limiting keys to those three
sizes. General crypto theory strongly implies that using
other key sizes would have the predictable effect on the
strength of the encryption (longer == stronger), but that
hasn't been tested and proved to be the case. Correct?
Take care,
Lou
In article
<[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> [EMAIL PROTECTED] (Lou Grinzo) writes:
>
> > I'm just starting to learn about AES, and I was wondering:
> > Why does the AES standard support only the key sizes of
> > (I think) 128, 192, and 256 bits? Is it purely to keep
> > the specification and logistical issues simple?
>
> Yes.
>
> > Or is there
> > a technical reason, such as increasing the key size doesn't
> > make AES any more difficult to attack? (I know that last
> > one sounds goofy, but in a world where PKI works, almost
> > anything is possible. <g>)
>
> Since the most effective attack known against AES at any key size is
> brute force, the larger keys are believed to increase the security.
>
> Rijndael can be used with block and key sizes that vary in jumps of 32
> bits between 128 and 256 bits, but it isn't AES unless you use a 128
> bit block and one of the key sizes you list. Sufficiently confusing?
> --
> __ Paul Crowley
> \/ o\ [EMAIL PROTECTED]
> /\__/ http://www.cluefactory.org.uk/paul/
>
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: ANOTHER REASON WHY AES IS BAD
Date: 20 Apr 2001 13:38:42 GMT
[EMAIL PROTECTED] (John Savard) wrote in
<[EMAIL PROTECTED]>:
>On 20 Apr 2001 02:45:35 GMT, [EMAIL PROTECTED]
>(SCOTT19U.ZIP_GUY) wrote, in part:
>
>> If one looks at the ideas in Kolmogov Complexity thoery
>>where one tries to determine how random a string is by the
>>length of shortest "program" that can generate the string.
>>I think one can apply the same thoery to crypto. Since
>>the idea is to take a low entropy string and make it appear
>>to be random. It should take a fairly long program it achive
>>this. But the goal of AES is to make a short program that can
>>even be used on smartcards. I believe one measure of the
>>potential worth of an encrytion program is the length of the
>>smallest program to do the required encryption.
>
>Actually, from the information-theoretic point of view - and
>Kolmogorov complexity has to do with information theory, not
>complexity theory - the complexity of the algorithm is irrelevant if
>the description of the algorithm is public.
No I disagree all that making it public does is to level
the playing field.
>
>Of course, a simple algorithm *does* reflect on the work factor, but
>even if your conclusions are valid, using Kolmogorov complexity in the
>argument is incorrect.
John I am saying to expand the concept to encryption. I am not
trying to stuck to exactly the same thing. I am saying the same
concepts can be used to give a possible meansure on the security
of encryption systems.
>
>John Savard
>http://home.ecn.ab.ca/~jsavard/crypto.htm
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: AES poll
Date: 20 Apr 2001 13:31:48 GMT
[EMAIL PROTECTED] (Paul Crowley) wrote in
<[EMAIL PROTECTED]>:
>[EMAIL PROTECTED] (David Wagner) writes:
>> For what it's worth, the "polls" of the research community showed
>> a significant leaning towards Rijndael even before it was selected
>> by NIST. I, for one, think they made a fine choice, and I'm very
>> pleased with the results of the standards process.
>
>...and remember, this is one of the Twofish authors writing. In fact,
>the extended Twofish team officially endorsed three of the final five
>(Rijndael, Serpent, Twofish) in their final presentation. They are
>the people who did the most cryptanalysis of the AES candidates.
Are you attempting to say the endorsement was real and not just the
poltically correct thing to do. If the TWOFISH team actaully made
an honest statement saying please pick Rijndael its better than
TWOFISH I would call that an endorsement any thing short of that
sounds FISHY.
Besides part of the game is to pretend you like some of the competition
so that you can fake the moral high ground. You pick the one that
you think your better than so if another product is far better people
will exculde looking at it. That way your product may only be
compared by others to the one you sort of liked. People will falsely
assume the possible far better product was not very good. "Since
you seem to be fair" since you said one was sort of good so the others
must not be so good. It really a very clever business trick.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: ANOTHER REASON WHY AES IS BAD
Date: 20 Apr 2001 13:35:48 GMT
[EMAIL PROTECTED] (Tom St Denis) wrote in
<muVD6.7256$[EMAIL PROTECTED]>:
>
>"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> I don't think I mentioned this. This way but I feel another
>> reason that the AES method has lead to a poor security solution
>> is as follows.
>>
>> If one looks at the ideas in Kolmogov Complexity thoery
>> where one tries to determine how random a string is by the
>> length of shortest "program" that can generate the string.
>> I think one can apply the same thoery to crypto. Since
>> the idea is to take a low entropy string and make it appear
>> to be random. It should take a fairly long program it achive
>> this. But the goal of AES is to make a short program that can
>> even be used on smartcards. I believe one measure of the
>> potential worth of an encrytion program is the length of the
>> smallest program to do the required encryption.
>
>This is just so wrong. Look at an OTP? It's a small program yet can be as
>secure as the entropy in the key. Low and behold so can a block cipher.
>
Actaully Tom as usually your quite wrong. If one looks at an OTP
you would have to think of the OTP data itself as part of the
encryption program or the program nesicessary to make the OTP sting.
So it would be it least the sixe of the data encrypted. Assuming
your using a random comples string.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NON SECRET ENCRYPTION (AKA RSA)
Date: 20 Apr 2001 13:46:19 GMT
[EMAIL PROTECTED] (Tom St Denis) wrote in
<yuVD6.7259$[EMAIL PROTECTED]>:
>
>"Frank Gerlach" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> see www.cesg.gov.uk
>>
>
>No.
>
>
>
Yes I read the article very interesting however.
Having worked for the government for 26 years. I can
honestly say it could be pure crap. Only a fool should
ever belive what is relived about secrets. Its is equally
likely that either the secret community descovered public
key encryption in the 50's or maybe they stumbled on it
after it was out in the public, We will never know the
truth. The only truth that you can be sure about is they
we spin a story that makes the black agencyes of governemnt
look good from a historical perspective. But if the spun
story has any relationship to truth it is purely accidental.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: "Christophe Meneboeuf" <[EMAIL PROTECTED]>
Subject: DSS and patents.
Date: Fri, 20 Apr 2001 16:01:12 +0200
Hi,
I am a French engineer student and I have to develop a C++ program in order
to sign binary messages.
I think I will use algorithms I found in DSS specifications in order to be
"DSS compliant". Now, I would like to know if these technologies (described
in FIPS PUB 186-2 and FIPS PUB 186-1) are patented and, of course, if the
small company I work for will have to pay royalties (it is not a US
company).
If the answer is yes, do you know some free "hashing" and other useful
algorithms, I could use to implement a DSA or RSA signature scheme ?
In fact, I do not know were I could find this information, that is why I ask
here.
Thanks,
Christophe Meneboeuf
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: DSS and patents.
Date: Fri, 20 Apr 2001 16:20:02 +0200
Christophe Meneboeuf wrote:
>
> Hi,
>
> I am a French engineer student and I have to develop a C++ program in order
> to sign binary messages.
> I think I will use algorithms I found in DSS specifications in order to be
> "DSS compliant". Now, I would like to know if these technologies (described
> in FIPS PUB 186-2 and FIPS PUB 186-1) are patented and, of course, if the
> small company I work for will have to pay royalties (it is not a US
> company).
> If the answer is yes, do you know some free "hashing" and other useful
> algorithms, I could use to implement a DSA or RSA signature scheme ?
IANAL, but Fipses don't require a license.
Don't worry about it. Worry instead about what your government has
to say about you providing a product with DSS.
Greetings!
Volker
--
They laughed at Galileo. They laughed at Copernicus. They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
