Cryptography-Digest Digest #85
Cryptography-Digest Digest #85, Volume #13Fri, 3 Nov 00 12:13:01 EST
Contents:
Re: RSA vs. Rabin (Bob Silverman)
Rijndael Security ("ajd")
Re: 3-dimensional Playfair? (Daniel)
Re: Calculating the redudancy of english? (Roger Gammans)
Re: Crypto Export Restrictions (Terry Ritter)
Re: srp-1.7.0 released w/TLS Telnet security, X11 forwarding support (Jeffrey Altman)
Re: Give it up? (Eric Lee Green)
Re: Rijndael Security (Eric Lee Green)
Re: Crypto Export Restrictions (James Felling)
Re: Calculating the redudancy of english? ("Douglas A. Gwyn")
Re: Is RSA provably secure under some conditions? ("Douglas A. Gwyn")
Re: ECC choice of field and basis (DJohn37050)
Re: index of coincidence of Spanish/Turkey ("Douglas A. Gwyn")
Re: Beale Cypher ("Douglas A. Gwyn")
Re: is NIST just nuts? ("Douglas A. Gwyn")
Re: Rijndael Security ("Douglas A. Gwyn")
Re: Give it up? (Tom St Denis)
From: Bob Silverman [EMAIL PROTECTED]
Subject: Re: RSA vs. Rabin
Date: Fri, 03 Nov 2000 14:37:08 GMT
In article 8tsl7m$pu4$[EMAIL PROTECTED],
Tom St Denis [EMAIL PROTECTED] wrote:
Is this little difference the reason why Rabin is provably as
secure
as factorization?
Yes. If you can find square roots, i.e a^2 = b^2 mod N (a != b) then
you can factor N. Thus solving the square root (well I think this is
how the proof goes, of course Bob will correct me) is as difficult as
factoring.
Somewhat simplified, but essentially correct. But you also need
a != -b mod N as well as a != b mod N
The question remains: Is factoring hard?
2. RSA with low exponents is found insecure today.
Nope. Wrong. Thank you for playing.
Please explain where you heard this and why you think your statement
is correct.
Rabin is insecure for various other reasons I would imagine.
Oh? Please tell us why you think this, and what these other reasons
might be. If you can't then you have no business making such a
statement.
R-W is subject to a known ciphertext attack which can reveal the key
(and not just the plaintext or signature!). But correct padding
destroys the attack.
RSA is more convenient as well. You can easily perform either
operation and you can do signatures, etc..
Rabin-Williams with e = 2 is 50% faster than RSA with e = 3
(and faster still than RSA with larger e) for verifying signatures.
I therefore ask why you think RSA is "more convenient"?
RSA is conjectured to be as hard as taking the discrete logarithm
modulo a composite (and with sufficient twisting as hard as
factoring).
However, there is no proof that you need to factor to solve the RSA
problem. In the case of Rabin it has been proven that you need to
factor to take the square root.
This is almost, but not quite correct. What would be correct is
saying that finding square roots modulo a composite is polynomially
equivalent to factor. You don't NEED to factor to take the square
root. You could find the square root by direct search without
factoring. However, once you have done so, you can factor the modulus
easily.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: "ajd" [EMAIL PROTECTED]
Subject: Rijndael Security
Date: Fri, 3 Nov 2000 10:05:35 -
How secure is Rijndael when given (most of) the plaintext and the cipher
text? For example if I encrypt a bitmap (and somehow the interceptor
knows its a bitmap), the interceptor then knows that the first block will
decrypt to
42 4D ** ** ** ** 00 00 00 00 36 00 00 00 28 00
where bytes 0-1 are the bitmap identifier
2-5 are the file size (which the interceptor doesn't *quite* know as my
encrypted file will be a multiple of the block size, and vthe plaintext file
may not be)
6-9 reserved and always zero
10-13 is the offset to beginning of bitmap data
14-17 is th header size
Given this information about the plaintext, and given the encrypted text,
can the interceptor work out the key? It seems to me like we are giving away
a bit too much information. Is there a standard to get around this problem?
regards
andrew
--
From: [EMAIL PROTECTED] (Daniel)
Subject: Re: 3-dimensional Playfair?
Date: Fri, 03 Nov 2000 14:58:13 GMT
On Thu, 02 Nov 2000 19:48:04 +0100, Mok-Kong Shen
[EMAIL PROTECTED] wrote:
Daniel wrote:
The largest problem to overcome will be the size of the CT (= 2 times
the length of the PT - this is the case for a typical Playfair).
I suppose you erred. Playfair encodes a couple of characters
to another couple via the matrix, thus preserving the length.
M. K. Shen
Indeed, I mixed up with Nebel's/Painvin's system. But my previous
remarks still have a point, though.
regards,
Dani
Cryptography-Digest Digest #85
Cryptography-Digest Digest #85, Volume #12 Thu, 22 Jun 00 11:13:00 EDT
Contents:
Re: DH - Man In The Middle (Mark Wooding)
Re: Quick Question on Primitive Elements GF(p) (Mark Wooding)
Re: How encryption works (Mark Wooding)
Re: How encryption works (infamis.at.programmer.net)
Re: How encryption works (Mark Wooding)
libdes: des_SPtrans ([EMAIL PROTECTED])
Re: Encryption on missing hard-drives (Guy Macon)
Re: How encryption works ([EMAIL PROTECTED])
Re: How encryption works ([EMAIL PROTECTED])
Re: libdes: des_SPtrans (Mark Wooding)
Re: Encryption on missing hard-drives ("Tony T. Warnock")
Re: Variability of chaining modes of block ciphers (Mok-Kong Shen)
Re: Length of pseudo random digits (Mok-Kong Shen)
Re: Variability of chaining modes of block ciphers (Mok-Kong Shen)
Re: Variability of chaining modes of block ciphers (Mark Wooding)
Re: Variability of chaining modes of block ciphers (Mark Wooding)
Re: Try it. (John)
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: DH - Man In The Middle
Date: 22 Jun 2000 10:35:57 GMT
Mark [EMAIL PROTECTED] wrote:
Im thinking of using a DH exchange to setup my keys (client/server
app). To stop the man in middle attack i need to sign the public
values of the DH exchange.
Yes.
Im planning on storing my servers public DSS key inside the client
EXE. (is that ok?)
Should be OK, assuming that you don't have any worries about users
themselves modifying the executable. (If you do, then all bets are off:
give up and go home now.)
I know i NEED to sign the public values from the server. what im
wondering is if i can skip the signing on the client public values
that get sent to my server.
This is OK, if you don't mind authenticating the client later. As long
as you do it carefully.
(this way i wouldnt need to generate any primes on the client (or am i
missing something?))
You're missing something. You can reuse DSA parameters, and share them
among many users. All the client needs to do is find a copy of the
shared parameters, pick a random secret key x, 0 x q, and somehow
transmit g^x (mod p) to the server.
If i read everything right, only 1 large prime needs to be generated
for a DH exchange (a public value)
No. If you've agreed on the Diffie-Hellman parameters (the prime and
generator) beforehand, you only need to generate arbitrary random
numbers to do the exchange, not find primes.
and 2 primes need to be generated to sign using DSS.
Again, false. You need to generate a random number, and do some
arithmetic.
Does this comprimise the exchange so a man in the middle attack can still
happen (or any other).
Do it carefully.
Here's a suggestion for the other sci.crypt readers to analyse.
Choose a security parameter t, such that 2^t effort is more than your
adversary will expend in breaking the system. You'll also need to
decide on the length of primes to make the Discrete Log problem
sufficiently hard -- see references elsewhere to the RSA and CryptoSavvy
papers about choosing numbers of the right size.
The system uses two sets of parameters:
p_S, q_S, g_S -- DSA parameters for the server. (q_S is 2t-bit prime;
p_S is a larger prime such that q_S divides p_S - 1, and the
Discrete Log Problem mod p_S is hard; g_S generates the
order-q_S subgroup mod p_S.)
p, q, g -- DH parameters for key exchange. (p = 2 q + 1; both p and q
are prime, and p is large enough for the Discrete Log Problem
mod p to be hard; g = 4.)
The server creates a private DSA key x_S, 0 x_S q_S, and publishes
its corresponding public key y_S = g_S^{x_S} mod p_S. The server knows
all of the values above; the clients know the parameters and the
server's public key.
Let S(*) be the server's signature on a piece of data (i.e., the data
together with a signature).
The protocol works like this:
1. client - server: g^\alpha mod p
2. server - client: S(g^\alpha mod p, g^\beta mod p)
In detail:
1. The client chooses a random Diffie-Hellman exponent \alpha,
0 \alpha q, and sends its public Diffie-Hellman value g^\alpha
mod p.
2. The server generates its own random Diffie-Hellman exponent \beta,
0 \beta q, and sends back, in a signed message, both its own
public value g^\beta mod p and the client's public value.
Both then compute the secret K = g^{\alpha \beta} mod p, from which they
can set up a secret and valid connection using a symmetric cipher and a
MAC, keyed from the shared secret K. The client is certain that it is
communicating with the server: the server has no such assurance, but may
require some authentication later.
Analysis: Consider an adversary who controls the network between the
client and server. He can change the client's initial public value, but
cannot forge the server's signature on the response, so the client will
detect the modific
Cryptography-Digest Digest #85
Cryptography-Digest Digest #85, Volume #11Wed, 9 Feb 00 23:13:01 EST
Contents:
Re: new standart for encryption software... ("finecrypt")
Re: New standart for encryption software. (David Wagner)
Re: Anti-crack ([EMAIL PROTECTED])
Re: New standart for encryption software. (Albert P. Belle Isle)
Re: permission to do crypto research (Xcott Craver)
Re: I'm returning the Dr Dobbs CDROM (Frank M. Siegert)
Re: Anybody know about this flaw? (Dan Day)
Re: Guaranteed Public Key Exchanges (Dan Day)
Re: Using Gray Codes to help crack DES (Dan Day)
Re: Anti-crack (Dan Day)
Re: new standart for encryption software.. (Johnny Bravo)
Re: new standart for encryption software... (Johnny Bravo)
From: "finecrypt" [EMAIL PROTECTED]
Subject: Re: new standart for encryption software...
Date: Thu, 10 Feb 2000 04:02:11 +0300
Repeating the sequence 1,000
times is not going to add 1,000 bits of entropy. In fact, it may not add
any
entropy at all, if nothing happens to be changing on your system at that
moment in time.
Sounds like you never worked with Windows (and if so, why you value Windows
specific program?) . Among pseudo-random values that has been retrieved
during key generation (and I specified these values in my post ) there is
such values as milliseconds since Windows started, types of events in input
queue, 1 ms time for last message and so on. These values permanently
changing during key generation. .
Not to mention that it is *SLOW*.
Slow for what? Entire cycle of key generation on PIII takes less than 0,1
sec.
--
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: New standart for encryption software.
Date: 9 Feb 2000 17:46:31 -0800
In article [EMAIL PROTECTED],
Albert P. Belle Isle [EMAIL PROTECTED] wrote:
I don't know what reason you have to make such a pejorative
interpretation of my use of the term "performance," (unless you're an
afficionado of fast cars and influenced by their advertising's use of
the term).
I apologize if any offense was taken. I guess I'm overly buried
in the "systems" world, where performance always means speed. I
see you meant something very different by the term. I apologize
for any confusion I may have caused.
Specifically, any good INFOSEC professional should be looking at the
actual contents of the files produced on the disk - whether this
refers to ciphertext or supposedly Sanitized clusters - regardless of
how good the source code looks.
The problem is still that this sort of "black box testing" of
cryptographic systems is not enough to detect many types of bugs.
Flawed key generators are one obvious example of a vulnerability
that can be exceedingly difficult to recognize without source.
(For instance, the Netscape key generator was MD5-ing the time
of day and some other predictable values. There's no way you are
going to find that flaw just by looking at program outputs.)
There are many other examples, too.
Ideally, one would combine source code audits with checks of the
actual output of the system. (Indeed, your comments later in your
post give a great example of why both are needed!) But if you
leave out the source code and other detailed information about the
system, it makes the auditor's job much more difficult.
--
From: [EMAIL PROTECTED]
Subject: Re: Anti-crack
Date: 9 Feb 2000 17:44:35 -0800
In article [EMAIL PROTECTED],
CJ [EMAIL PROTECTED] wrote:
Has anyone researched means of protecting
programs from being cracked with encryption?
If I can hear it, I can record it.
If I can see it, I can record it.
If my computer can execute it, I can comprehend it.
Why do people have trouble with these facts?
--
Matthew Skala "Ha!" said God, "I've got Jon Postel!"
[EMAIL PROTECTED]"Yes," said the Devil, "but *I've* got
http://www.islandnet.com/~mskala/all the sysadmins!"
--
From: Albert P. Belle Isle [EMAIL PROTECTED]
Subject: Re: New standart for encryption software.
Date: Wed, 09 Feb 2000 21:17:22 -0500
Reply-To: [EMAIL PROTECTED]
On 9 Feb 2000 17:46:31 -0800, [EMAIL PROTECTED]
(David Wagner) wrote:
In article [EMAIL PROTECTED],
Albert P. Belle Isle [EMAIL PROTECTED] wrote:
I don't know what reason you have to make such a pejorative
interpretation of my use of the term "performance," (unless you're an
afficionado of fast cars and influenced by their advertising's use of
the term).
I apologize if any offense was taken. I guess I'm overly buried
in the "systems" world, where performance always means speed. I
see you meant something very different by the term. I apologize
for any confusion I may have caused.
Specifically, any good INFOSEC professional should be looking at the
actual contents of the
Cryptography-Digest Digest #85
Cryptography-Digest Digest #85, Volume #9Wed, 17 Feb 99 05:13:04 EST
Contents:
Re: Help! Cryptosystem needed. ("Peter Flodin")
Re: encryption debate (DM Lanza)
Re: encryption debate (DM Lanza)
Re: Block ciphers vs Stream Ciphers
Re: Web Site Problems, Quadibloc III
Re: Barcodes
Protecting Against Replay Attacks With Nonrandom IV
Re: Would this PRNG work?
Re: Block ciphers vs Stream Ciphers ("Douglas A. Gwyn")
Re: True Randomness ("Douglas A. Gwyn")
More Security for Single-DES?
Re: Really lousy random numbers ("Douglas A. Gwyn")
Re: some hash questions (Vladimir Beker)
Re: Protecting Against Replay Attacks With Nonrandom IV (Terry Ritter)
Re: Block ciphers vs Stream Ciphers ("Douglas A. Gwyn")
Re: encryption debate ("Douglas A. Gwyn")
Re: Privacy, Traps and Frozen Hell ("Douglas A. Gwyn")
Re: Help! Cryptosystem needed. ("Douglas A. Gwyn")
Re: More Security for Single-DES? (Terry Ritter)
From: "Peter Flodin" [EMAIL PROTECTED]
Subject: Re: Help! Cryptosystem needed.
Date: Wed, 17 Feb 1999 13:10:57 +1100
No rumors, sure they can do it. Granted, nobody knows NSA´s
real budget... but it surely is larger than $250.000!
Yes, NSA's budget is closer to $3,500 million per year.
The CIA, the Defense Intelligence Agency, the NSA and military RD have a
budget of at least $30,000 million, which is greater than what the US spends
on education.
--
Date: Wed, 17 Feb 1999 00:35:53 -0500
From: DM Lanza [EMAIL PROTECTED]
Subject: Re: encryption debate
R. Knauer wrote:
On Tue, 16 Feb 1999 16:43:24 -0500, "Trevor Jackson, III"
[EMAIL PROTECTED] wrote:
Amendment X grants unenumerated rights to the STATES. I believe
you mean to refer to Amendment IX. Unless my Anheuser's Disease
is affecting my memory.
This is an error. The phrase is the states or the people. Note that
this is one of the keys to the proper interpretation of some of the
enumerated rights in which the term "the people" appears.
Some? Why not ALL?
There is not one use of the term "The People" that could ever be
misinterpretated to mean the several States.
Some indicates that only some of the enumerated rights have been distorted
by interpreting "the people"as a reference to government as representatite
of the people "as a whole" instead of as individual persons.
All the liguistic and constitutional scholars who have examined the
terminology usage of the Bill of Rights has concluded that "the people"
means the people not the government(s). The Xth amendment is one of the
cases where this interpretation is glaring.
Clearly "the people" is not a synonym for the states.
The Founding Fathers knew enough English to know what they meant by
the use of two completely distinct terms: The People and The States.
There is no possible confusion, unless someone deliberately tries to
introduce a bogus misinterpretation.
"The People" means the people, pure and simple, not the State. This is
further clarified in the writings of that era. Nowhere do the framers
of the Constitution once mean anything different from the conventional
meaning of the term "The People".
It's the marxist organizations trying to subvert our Constitution that
attempt to foist off such ridiculous misinterpretations, and then only
where it suits them.
It is not only the marxists, but the pick-a-termists who are willing to
distort reality to fit their preconceptions. Belief has always interfered
with Truth. Always will.
--
Date: Wed, 17 Feb 1999 00:38:57 -0500
From: DM Lanza [EMAIL PROTECTED]
Subject: Re: encryption debate
Michael Sierchio wrote:
On Tue, 16 Feb 1999 16:43:24 -0500, "Trevor Jackson, III"
[EMAIL PROTECTED] wrote:
Amendment X grants unenumerated rights to the STATES. I believe
you mean to refer to Amendment IX.
This is an error. The phrase is the states or the people. Note that
this is one of the keys to the proper interpretation of some of the
enumerated rights in which the term "the people" appears.
Amendment IX refers to RIGHTS of the people. Amendment X says that POWERS
not delegated to the United States are reserved to the respective
states or the people. Amendment IX is the relevant one when discussing
"enumerated" vs. implicit rights.
On rights v. powers you are, of course, correct. On your initial statement
"Amendment X grants unenumerated rights to the STATES" you are wrong because
you have truncated the statement, butchering it in the process. There is
neither mercy nor appeal for this kind of (ahem) error.
--
From: [EMAIL PROTECTED] ()
Subject: Re: Block ciphers vs Strea
