Cryptography-Digest Digest #958
Cryptography-Digest Digest #958, Volume #13 Wed, 21 Mar 01 07:13:01 EST
Contents:
Re: Strong Primes (Peter Engehausen)
Re: A future supercomputer (Frank Gerlach)
Re: Defining a cryptosystem as "broken" (Mok-Kong Shen)
Re: Codes that use *numbers* for keys (Daniel)
Re: A future supercomputer (Mok-Kong Shen)
Re: looking for "Crowds" (Mok-Kong Shen)
Re: NSA in the news on CNN ("Mxsmanic")
Re: NSA in the news on CNN ("Mxsmanic")
Re: Is Evidence Eliminator at all useful ?? (David Schwartz)
What happens when RSA keys don't use primes? ("Mxsmanic")
Re: What happens when RSA keys don't use primes? (Mok-Kong Shen)
Re: What happens when RSA keys don't use primes? ("Mxsmanic")
Re: I encourage people to boycott and ban all Russian goods and services, if the
Russian Federation is banning Jehovah's Witnesses ... ("")
Hours of work done on RSA, ECC or NTRU ? (Jyrki Lahtonen)
Re: How to eliminate redondancy? (moving steadily towards being computer science
terminology) (those who know me have no need of my name)
Re: = TV detection (was: FBI easily cracks encryption ...?) (Richard Herring)
Re: What happens when RSA keys don't use primes? (Hard)
From: Peter Engehausen [EMAIL PROTECTED]
Subject: Re: Strong Primes
Date: Wed, 21 Mar 2001 07:03:29 -0100
Reply-To: [EMAIL PROTECTED]
Dear Joseph!
Thanks for your reply!
The move to lambda(N) is necessary for the proof because the short cycles
are not a result of p or q, but of the lambda reduction of them. This stems
from the inversion of RSA (aka decryption) which requires, not knowledge of
p or q, but knowledge of lambda(N).
Actually it's my belief, that what a "complete" argumentation should discuss
not only the order of e modulo \lambda(N) (it should be small, if you like to
mount the attack, see equation 16), but also the order of e modulo \lambda(p)
(see equation 18 19).
I just realized, that I had a typo in my last mail: I wrote ord (e) mod p
instead of ord (e) mod \lambda(p) = ord (e) mod p-1. Strange ... The authors
wrote mod p on page 17 too. Do I miss something? Isn't the order of e mod p
irrelevant? I need to know, when the exponent of C is equal to 1, therefore I
need to know the order e mod p-1 and/or the order of e mod \lambda(N).
I'm really lost! HELP!
Everything else is just argument for that statement.
But is the arguemntation correct?
Best wishes,
Peter
PS: And I still don't understand this part:
"Suppose r does not divide ord(e) mod \lambda(N). It follows immediately
that e must be an r-th power mod p. This follows form Lagrange's
Theorem: ord(e) must divide p-1, and we have assumed that r divides p-1
but r does not divide ord(e). Hence e must be an r-th power mod p."
ord(e) mod \lambda(N) must divide p-1? Im not sure if I remember
Lagrange's Theorem well... The order of a subgroup divides the order of
its group. Hence for every e which is coprime to \lambda(N) the order
of e mod \lambda(N) must divide the order of (Z/\lambda(N)Z)^*. This is
\phi(\lambda(N)), isnt it? I cant see why ord(e) divides p-1...
And further on: You say, if r and ord(e) divide both p-1 and r doesnt
divide ord(e) than e must be an r-th power.
Sounds obvious, but why? Im still too blind to see through.
--
From: Frank Gerlach [EMAIL PROTECTED]
Subject: Re: A future supercomputer
Date: Wed, 21 Mar 2001 10:11:15 +0100
Mok-Kong Shen wrote:
BTW, I read that ASCI White has about 1/1000th of the estimated
computational power of the human brain. So with Blue Gene a
machine could have a solid foundation to attempt to compete
with a human being.
If anybody comes up with a brain simulation of a mouse, then it makes
sense to talk about that at all.
M. K. Shen
--
From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: Defining a cryptosystem as "broken"
Date: Wed, 21 Mar 2001 10:14:45 +0100
Joseph Ashwood wrote:
Of course the user will have problems. That's where well paid cryptanalysts
come in :) I think I can say safely that we all agree that most systems
simply haven't been designed with security in mind (I point to MS insert
name here/ as an example). The difference is that I did not say this is a
countable set, only you have made that assumption about what I have said.
What I have said is that a threat/attack model needs to be made, I have
never said that it is an easy problem, I have never said that the set of all
models is countable (although because I expect that they will all be finite
in length they are not only countable but finite), I have only said that one
needs to be constructed for the situation. Choosing the right model should
be done for the user, in fact the programmer will fix the threat/attack
model whether he/she knows it or not. The only decisi
Cryptography-Digest Digest #958
Cryptography-Digest Digest #958, Volume #11 Tue, 6 Jun 00 16:13:01 EDT
Contents:
Re: Question about recommended keysizes (768 bit RSA) (David A. Wagner)
Re: A Family of Algorithms, Base78Ct (wtshaw)
Re: Some citations (wtshaw)
Re: Could RC4 used to generate S-Boxes? ("T.Williams")
Re: Question about recommended keysizes (768 bit RSA) (Jerry Coffin)
Re: Question about recommended keysizes (768 bit RSA) (Paul Koning)
Cryptography FAQ (01/10: Overview) ([EMAIL PROTECTED])
Cryptography FAQ (02/10: Net Etiquette) ([EMAIL PROTECTED])
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Question about recommended keysizes (768 bit RSA)
Date: 6 Jun 2000 11:32:47 -0700
In article 8hiv9l$vcp$[EMAIL PROTECTED],
Bob Silverman [EMAIL PROTECTED] wrote:
In article 8hhcok$v4s$[EMAIL PROTECTED],
[EMAIL PROTECTED] (David A. Wagner) wrote:
In article [EMAIL PROTECTED],
Roger Schlafly [EMAIL PROTECTED] wrote:
It is not obvious to me why it a time estimate should be more
accurate than a space estimate.
One reason why it might be so is that many theoretical works consider
only the total complexity, and even then, in asymptotic form only.
We have real-world benchmarks!!! These are not "theoretical estimates".
Yes, now. But wouldn't you say that people have been studying
"theoretical estimates" for advanced algorithms longer (or more
intensely, if one looks back in time a bit) than they have been
studying "real-world benchmarks"?
The point is, whichever has been studied more thoroughly might
well be considered better-understood and thus might lead to a
more reliable (from a very conservative point of view) estimate
of the complexity of factoring.
--
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: A Family of Algorithms, Base78Ct
Date: Tue, 06 Jun 2000 11:08:28 -0600
In article [EMAIL PROTECTED], Mok-Kong Shen
[EMAIL PROTECTED] wrote:
wtshaw wrote:
Mok-Kong Shen[EMAIL PROTECTED] wrote:
Through the time I saw you several times mentioning GVA but I have
never understood what that scheme really performs. Could you give
a pointer or post a sketch to the group? Thnaks.
http://www.radiofreetexas.com/wts/
I see that the multistage (i.e. iterated) use of the Jefferson cylinder
with the aid of a key is indeed a nice idea.
M. K. Shen
Thanks, it works, and neither Jefferson, Brassier, nor any Mr. M94 is
complaining about the role of prior art.
BTW, none has be able to successfully attack even a moderate level of
security, as define by the keys, not a single soul, and many have tried.
Keep in mind that the cylinder itself is the principal key.
At the time of its public description, none in the public sector seemed to
admit that strong crypto was known or might be possible as having such
violated crypto propaganda maximums. Since then it has become vogue to
claim such strength., but none can easily come close the working strength
of this baby, certainly not its simplicity.
--
If you wonder worry about the future enough to adversely limit
yourself in the present, you are a slave to those who sell security.
--
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Some citations
Date: Tue, 06 Jun 2000 10:55:17 -0600
In article [EMAIL PROTECTED], Mok-Kong Shen
[EMAIL PROTECTED] wrote:
I think that the following citations may be of some interest,
because they may presumably not be unanimously accepted by
us all and hence could trigger some discussions:
Bandwidth expansion is not necessarily either a drawback
or a strength of a system, merely a feature.
I said the same thing ,in essence, and said it first, circa 1995.
--
If you wonder worry about the future enough to adversely limit
yourself in the present, you are a slave to those who sell security.
--
From: "T.Williams" [EMAIL PROTECTED]
Subject: Re: Could RC4 used to generate S-Boxes?
Date: Tue, 06 Jun 2000 20:51:12 +0200
Mark Wooding wrote:
T.Williams [EMAIL PROTECTED] wrote:
Runu Knips wrote:
Hmm. For me, a s-box is an operation of the form:
f(x) - y
where f is bijective and should have some other good properties
already discussed in this thread.
No. Bijectivity isn't actually a necessary feature; it helps security,
though. For example, Blowfish's S-boxes aren't necessarily bijective --
these are the `weak keys' that Vaudenay found. DES's S-boxes aren't
bijective either: in particular, they're source-heavy. Non-bijectivity
is a bad idea in general: it means that you can get nonzero input
differences sent to zero output differences, giving you an easy 2-round
iterative characteristic.
The main point about it is, that it is an operation or function,
not a dynamically changing mapping, i.e. for the same x you
always get the
Cryptography-Digest Digest #958
Cryptography-Digest Digest #958, Volume #9 Sat, 31 Jul 99 00:13:03 EDT
Contents:
How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
(Guenther Brunthaler)
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
(Greg Comeau)
Re: How Big is a Byte? (was: New Encryption Product!) (Roger)
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
(Mr. Leo Yanki)
Re: Hash (One-Way) Functions (Mr. Leo Yanki)
Re: How Big is a Byte? (was: New Encryption Product!) ("Douglas A. Gwyn")
Re: Modified Vigenere cipher (Alexander Demin)
Re: Q: Does ElGamal require that (p-1)/2 is also prime like DH?
([EMAIL PROTECTED])
Re: Cryptonomicon - low priority posting (Helge Horch)
Re: the defintion of Entropy ("Mark Hammer")
The Onega Cipher (wtshaw)
Re: OTP export controlled? (Jerry Park)
From: [EMAIL PROTECTED] (Guenther Brunthaler)
Crossposted-To:
alt.folklore.computers,alt.comp.lang.learn.c-c++,comp.lang.c++,microsoft.public.vc.language
Subject: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
Date: Fri, 30 Jul 1999 22:01:43 GMT
A PRACTICAL GUIDE TO PORTABLY WRITE CODE
THAT DEPENDS ON SPECIFIC BIT SIZES FOR C/C++
(c) 1999 by Guenther Brunthaler
===
This is an excerpt of an article I recently posted on this topic for
free use and distribution by the USENET community.
===
In cryptographic applications as well as many other situations
integers of specific bit sizes are required.
But how to write code dealing with bits in a portable fashion? Bits
make a byte, right? And bytes always have 8 bits, most people believe.
But is that correct? What has a byte been defined anyway!?
Well, "byte" is simply short for "binary term" and nothing else. It
can have ANY number of bits, although on most machines it has 8 bits
("binary digits").
However, I know that on some older mainframes bytes also used to have
just 6 bits.
Usually, a byte is the smallest unit of memory a processor allows to
address directly.
If you have to obtain the number of bits in a byte in a C program,
just include the ANSI-C header file
#include "limits.h"
and use the constant
CHAR_BIT
for that purpose: ANSI-C defines that 'char' is mapped to a
processor's byte, however big that may be on this particular processor
(although certain minimum requirements have been specified by the ANSI
committee).
So, if you want to know how many bits there are in an 'int', just
write
CHAR_BIT * sizeof(int)
instead of #defining it for your specific processor.
And, please, avoid following the WINDOWS-misconception of thinking
"BYTE" is a good choice for referring to an 8 bit integer, WORD for 16
and LONG for 32 bits, etc.
As outlined above, a 'byte' on a machine must NOT necessarily have 8
bits. Also, the signedness of a byte can be interpreted differently on
each machine, just as as a plain 'char' in C (as opposed to 'signed
char' and 'unsigned char').
The term 'word' actually stands for 'machine word' in most contexts,
not just for "16 bits" as in windows. A machine word is usually
defined as the native unit of memory access (or standard register
size) for each processor. So 8 bit processors use 8 bit words, 16 bit
processors use 16 bit, 32 bit processors use 32 bit and a 64 bit
processors use 64 bit. A machine word is typically mapped to an 'int'
for each 'C' implementation.
Also the choice of "LONG" (or "DWORD") is a bad choice either, because
what seems long for one processor is rather short for another. In
fact, such name assignments are basically MEANINGLESS.
So, what better choices are available?
Until before a few years, I defined data types such as
U8, U16, U32 etc for unsigned integers and S8, S16, S32 for signed
integer types of a specific bit size.
The names are pretty descriptive and I was quite happy with this,
until I found QUITE A BETTER replacement for my self-defined types:
The soon-to-come standard header file "inttypes.h".
This file solves all the problems associated with assigning bit sizes
to integers - and provides even more.
Although it has not yet (1999) been approved as a standard IMHO, I
have found it to be part of many compiler distributions already. But
even if this is not the case with your compiler, it will always be
worth the effort of downloading some version of inttypes.h from the
internet and customizing the typedefs until it matches your machine
(as I did).
But what makes inttypes.h so powerful?
First of all, it provides integers with specific signedness and bit
size: uint8_t is an unsigned integer exactly 8 bits wide, int32_t is a
signed integer exactly 32 bits wide, etc.
So this header file provides complete portable replacement for all
those fancy &q
