Cryptography-Digest Digest #832
Cryptography-Digest Digest #832, Volume #13 Wed, 7 Mar 01 22:13:01 EST
Contents:
Re: Super strong crypto ("Douglas A. Gwyn")
Re: hardwire prime generator in Diffie-Hellman? ("Julian Morrison")
Re: Semi-super-strong crypto? ("Douglas A. Gwyn")
Re: How to find a huge prime(1024 bit?) ("Dik T. Winter")
Re: hardwire prime generator in Diffie-Hellman? ("Tom St Denis")
Re: Super-strong crypto..(As if). ("Douglas A. Gwyn")
Re: How to find a huge prime(1024 bit?) ("Douglas A. Gwyn")
CHES 2001 registration! (Christof Paar)
Re: hardwire prime generator in Diffie-Hellman? ("Julian Morrison")
Dayton's Code Breakers (Jerry Proc)
Re: National Security Nightmare? (John T. Kennedy)
Re: Creating serial numbers? (Paul Rubin)
Re: hardwire prime generator in Diffie-Hellman? (those who know me have no need of
my name)
Re: National Security Nightmare? (Paul Rubin)
Re: National Security Nightmare? (John T. Kennedy)
Re: Again on key expansion. (Benjamin Goldberg)
Re: hardwire prime generator in Diffie-Hellman? ("Julian Morrison")
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
From: "Douglas A. Gwyn" [EMAIL PROTECTED]
Subject: Re: Super strong crypto
Date: Thu, 08 Mar 2001 01:08:27 GMT
Bryan Olson wrote:
But understand it's no small detail. Thousands have tried
to bridge that chasm, and so far all have failed.
But in the meantime, we can try to beef up the methods we have
by such methods as I was suggesting. In applications such as
one I'm supporting at the moment, there are real-world
constraints that force the security implementation to work too
close to the edge, and efficient implementation is paramount
(so the data encryption will be something like Rijndael with
small parameters). Under such circumstances, anything that can
be done to get in the way of the enemy cryptanalysts is welcome.
--
From: "Julian Morrison" [EMAIL PROTECTED]
Subject: Re: hardwire prime generator in Diffie-Hellman?
Date: Thu, 08 Mar 2001 01:09:42 +
"Tom St Denis" [EMAIL PROTECTED] wrote:
A slew means under sqrt((p-1)/2).
Does this mean: that many messages to a particular person, or that many
messages total? (in other words: could I just slurp up that many messages
with packet sniffing, and weaken security thereby?) Because in normal
situations, the number of uses of DH I intend is only once between any two
IPs - as a setup handshake.
Perhaps the best way to improve this, is to hardwire several
prime/generator pairs, and let each handshake specify "we'll be using the
n'th pair this time"
--
From: "Douglas A. Gwyn" [EMAIL PROTECTED]
Subject: Re: Semi-super-strong crypto?
Date: Thu, 08 Mar 2001 01:18:43 GMT
Benjamin Goldberg wrote:
k(i) = encrypt_k0( IV0 + i )
ct(-1) = IV1
ct(i) = encrypt_(k(i/N))( pt(i) ^ ct(i-1) )
The key schedule is fairly good (assuming a reasonable encrypt
function), but you might as well not have the "^ ct(i-1)" since
the enemy knows it (for all i0) without having to do any work.
It does stop prearranged tests for busts, however.
Most of the concerns I was addressing in the straw man are
addressed here. My main concern is that the small amount of
k0+IV0+IV1 entropy is spread across an indefinitely large amount
of CT, which might not be a problem, but it sure feels like one.
--
From: "Dik T. Winter" [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp,sci.math
Subject: Re: How to find a huge prime(1024 bit?)
Date: Thu, 8 Mar 2001 01:13:26 GMT
In article 985sua$[EMAIL PROTECTED] [EMAIL PROTECTED] (Gregory G Rose) writes:
In article [EMAIL PROTECTED], Dik T. Winter [EMAIL PROTECTED] wrote:
Well, I say it is correct. The premissa is: "there is a finite number
of primes". Multiplying them all together and adding 1 shows that the
resultant number is not divisible by any prime. Hence by the definition
of prime it must be prime, contradicting the premissa.
The number you get by multiplying all the primes
together and adding one might not be prime itself;
Why not? The definition of prime is a number is prime if it is not
divisible by another prime. As the number so calculated is not
divisible by any prime it must be prime by the definition. Which
of course is a contradiction (you did not actually have a complete
list of primes).
That it is not necessarily prime in real life is something completely
different. When you start with a false premissa you can prove almost
anything, and that is the point, you prove something that is false
and there is your contradiction, and what way you go does not matter.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland
Cryptography-Digest Digest #832
Cryptography-Digest Digest #832, Volume #12 Tue, 3 Oct 00 22:13:00 EDT
Contents:
Re: Mr. Zimmermann, Mr. Price when can we expect this feature ? (Rich Wales)
Re: Authenticating a PIN Without Compromising the PIN ("Mat")
Re: Q: does this sound secure? (Thomas Wu)
Re: is NIST just nuts? (John Savard)
Re: Rijndael: making the "flaw" plainer (John Savard)
Re: RC6 royalty free or not? (John Savard)
Re: Comments on the AES winner (John Savard)
Re: is NIST just nuts? (John Savard)
Re: Rijndael test vectors (John Savard)
Re: Authenticating a PIN Without Compromising the PIN (Paul Rubin)
Re: Authenticating a PIN Without Compromising the PIN (Thomas Wu)
Re: My Theory... (John Savard)
Re: Democrats, Republicans, AES... (Albert Yang)
Re: Requirements of AES (Tom St Denis)
Re: Requirements of AES (Tom St Denis)
Re: My Theory... (Tom St Denis)
Re: Requirements of AES (Tom St Denis)
Re: Requirements of AES (JPeschel)
Re: Democrats, Republicans, AES... (Jim Gillogly)
From: [EMAIL PROTECTED] (Rich Wales)
Crossposted-To: alt.security.pgp
Subject: Re: Mr. Zimmermann, Mr. Price when can we expect this feature ?
Date: 4 Oct 2000 00:04:09 -
=BEGIN PGP SIGNED MESSAGE=
Tom McCune wrote:
On a modern computer, it takes no additionally noticeable
time to encrypt or decrypt to a 4096 bit RSA key than it
does to a 1024 bit RSA key. So although it isn't really
necessary to use the maximum potential of PGP by using a
key larger than 3000 bits, there isn't really harm in doing
so (except for backwards compatibility). I'm surprised
that this performance myth continues.
As far as I can tell, it ought to be possible to take PGP 2.6.3ia
(the "internationalized" version of 2.6.2, with some extra bug fixes,
which has been available since 1996 on www.pgpi.org) and modify it
to generate and use 4096-bit RSA keys by making the following simple
changes to the source code:
== In mpilib.h, change MAX_KEY_BITS from 2048 to 4096.
== In randpool.h, change RANDPOOLBITS from 3072 to something larger
(otherwise the program will bomb during generation of a large key).
I chose a new value of 10240, and it seems to work, though this is
probably somewhat larger than necessary.
This isn't any sort of official patch: I don't work for NAI, I accept
no liability if the modified code doesn't work or has hidden weaknesses,
etc., etc. I'm just proposing this as a starting point for discussion
and experimentation. I would be very interested in any constructive
feedback.
Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/
PGP 2.6+ key generated 2000-08-26; all previous encryption keys REVOKED.
RSA, 2048 bits, ID 0xFDF8FC65, print 2A67F410 0C740867 3EF13F41 528512FA
=BEGIN PGP SIGNATURE=
Version: 2.6.3ia
Charset: noconv
Comment: Rich Wales's public keys at http://www.webcom.com/richw/pgp/
iQEVAwUBOdpznEm4X0z9+PxlAQF7Agf+KPd6nm8ij+mpAIcV3tGLL4F+NlYyhoEA
mPIfLrhviOjnq3rqnffoRvTbQDR7JStMbbe8tJHqapWYbo/k7TMaOwbwzSJBN9xF
9rqjjZUphjJ7n/xadzsnR/uM8A+L1TU6XS19TH8FljR0Hhn0s4rFMVG+HGQKQbkE
6wLSoiAhLt/ujIZxOh887Yu4UcmHraW0Ffs5S87nfJe4RPd/n5rzZzLvcS/iN/ep
J75HMnAmySbxx3E54tBBIxvEba1uBYj6lIiX1gnCQvo9T8yTylqhQZNNPps4E8Hi
gx3DKgRLpIa7JqKZx6vQUwzIaJuZPfzS19t5BHMTx4uBd18P7uDuPg==
=kt3+
=END PGP SIGNATURE=
--
From: "Mat" [EMAIL PROTECTED]
Subject: Re: Authenticating a PIN Without Compromising the PIN
Date: Wed, 04 Oct 2000 00:16:11 GMT
Why can't you have the server generate a random number and give it to the
client. The client would then hash its pin with the number and return the
result to the server. The server would do the same and compare the results
to see if they match. The pin would never be sent over the network.
I thought that was the way secure email authentication worked or something?
I'm sure there are flaws in it but it may suit your need. There would be no
assurance that you were talking to the right server besides the network
address. I guess the server could be forced to authenticate through the
same method and verify that it had a copy of your password if that were
neccessary?
I'm thinking of using something like this in a client server system over the
Internet. If anyone has any comments on this form of authentication please
speak up. My security needs are not very heavy though and I am also
considering sending the passwords plain.
Client Connects
Server Generates Challenge Random #
Client Sends Password Hashed with Challenge #
Server Authenticates or Says OK
Matt
"Guy Lancaster" [EMAIL PROTECTED] wrote in message
news:8rd6d8$4a9$[EMAIL PROTECTED]...
If it's possible, how could a protocol authenticate a user's
PIN without revealing information that would make it
relatively easy to determine the actual PIN value?
PINs are common
Cryptography-Digest Digest #832
Cryptography-Digest Digest #832, Volume #10 Mon, 3 Jan 00 16:13:01 EST
Contents:
Re: "Variable size" hash algorithm? (Boris Kazak)
Re: On documentation of algorithms (Mok-Kong Shen)
Re: meet-in-the-middle attack for triple DES (Mok-Kong Shen)
Re: Bits 1 to 3 (Re: question about primes) ("Tony T. Warnock")
From: Boris Kazak [EMAIL PROTECTED]
Subject: Re: "Variable size" hash algorithm?
Date: Mon, 03 Jan 2000 12:18:28 -0800
Reply-To: [EMAIL PROTECTED]
"Peter K. Boucher" wrote:
Why not have your program measure the entropy of the input, then use the
input as an RC4 key, then use the RC4 PRNG to output as many bytes as
can be justified by the entropy in the input?
=
This is the reply to original poster
[EMAIL PROTECTED] (Dan Day)
Organization:
Frontier GlobalCenter Inc.
***
Try this, it reads a file, writes a file...
The program takes the filename from the simple dialog
and writes the hash into a new file with the name of the
original file and extension "h32".
Original message is divided into segments of the size
twice that of the final hash, e.g. if the final hash will
be 160 bit, the segments will be 320 bit each. The size of
the hash and segments is #defined by the HASHBLOCKSIZE
constant and can be altered according to need.
This proposed function is based on multiplication
(mod 2^32+1) with two "twists". First, however, some
background information.
The function uses one single modular multiplier
which in the program is #defined as "SEED". This number is
0x6A09E667, which happens to be the first 8 hex digits of
SQRT(2), less initial 1. The use of this number should
dispel any suspicions about a "trap door" built into SEED.
Now about the "twists". The first twist regards the
progression along the block. After the multiplication,
when the bytes of the product are returned to their places
and it is time to proceed with the subsequent multiplication,
the two LS bytes of the previous product become the two
MS bytes of the new number to be multiplied, and two adjacent
bytes of the plaintext are appended to them in order to make
this new 32-bit number. When the end of the block is reached,
the index wraps cyclically over the 2*HASHBLOCKSIZE.
For each block, there are three repetitions of two rounds
each (for those paranoid among us, there is a #define, where
one can change the ROUNDS constant to whatever desired).
Graphically a round can be visualized in the
following sketch:
( the index is circular mod 2*HASHBLOCKSIZE )
___
1-st multiplication
( - 32-bit number to multiply)
___
2-nd multiplication
ppPPXXxx
(ppPP - product of the first multiplication,
PPXX - 32-bit number to multiply)
___
3-d multiplication
PPXX
( PPXX - 32-bit number to multiply)
...
Last multiplication
XXPP
( The index is cyclically wrapped over -
PPXX - 32-bit number to multiply)
___
This arrangement allows an ultra-rapid propagation
of all changes across the entire block - there is complete
avalanche after the 2-nd round and then after each
subsequent round.
The second twist was introduced later, after Paul Onions
pointed out that it is possible to easily produce collisions
if each subsequent text block is simply XOR-ed into the text
buffer without any further precautions.
In all the discussion below I shall assume the 320-bit
block and 160-bit hash, just for example.
Since modular multiplication is a one-to-one transformation,
there is no way to find a different single 320-bit block which
would be transformed to the same value. A single bit change in
the original 320-bit block will produce unpredictable avalanche
changes after 2 rounds.
However, after we process the second block, there is a
possibility to take this 320-bit value, reverse transform it
via our modular multiplication with the multiplicative inverse,
take an arbitrary 320-bit value, XOR it with the buffer, again
reverse transform the result with the multiplicative inverse,
and thus obtain two bogus blocks which will together hash to
the same value as two blocks of original message. This is
really a direct way to produce collisions.
T
Cryptography-Digest Digest #832
Cryptography-Digest Digest #832, Volume #9Mon, 5 Jul 99 14:13:03 EDT
Contents:
re: AES public comments from the Rijndael Team ([EMAIL PROTECTED])
Re: The One-Time Pad Paradox ("Dr.Gunter Abend")
Why this simmetric algorithm is not good? ([EMAIL PROTECTED])
Re: The One-Time Pad Paradox ("Dr.Gunter Abend")
Re: The One-Time Pad Paradox (Mok-Kong Shen)
Re: I don't trust my sysadmin ([EMAIL PROTECTED])
Re: Why this simmetric algorithm is not good? (Nicol So)
Re: Crypto Books on CD-ROM (John Savard)
Re: Crypto Books on CD-ROM (John Savard)
Re: Why this simmetric algorithm is not good? (John Savard)
Re: Why this simmetric algorithm is not good? (John Savard)
Re: Why this simmetric algorithm is not good? (Francois Grieu)
Re: Crypto Books on CD-ROM (Wil Baden)
Re: Summary of 2 threads on legal ways of exporting strong crypto (Mok-Kong Shen)
Re: Summary of 2 threads on legal ways of exporting strong crypto ([EMAIL PROTECTED])
Re: Standard Hash usage (Keith A Monahan)
From: [EMAIL PROTECTED]
Subject: re: AES public comments from the Rijndael Team
Date: Mon, 05 Jul 1999 11:35:38 GMT
One comment they note that only theirs and HPC is suited for hashes
128 bits. However RC6 is well suited if 64-bit words are available.
I think they should revise their statement to include this. On a ALPHA
for example the 64-bit version would actually be faster then the 32-bit
one...
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: "Dr.Gunter Abend" [EMAIL PROTECTED]
Subject: Re: The One-Time Pad Paradox
Date: Mon, 05 Jul 1999 15:51:35 +0200
Reply-To: [EMAIL PROTECTED]
Jim Gillogly wrote:
Dr.Gunter Abend wrote:
G.A. The proposed technique of appending some garbage at
the beginning of the plaintext in case of an intelligible
ciphertext surely weakens the keystring, no matter if it
is done automatically or by hand.
Actually, a quantification did just occur to me. Your
algorithm could be something like "If the ciphertext is all
ASCII and says something coherent, skip the first OTP bit and
try again." The cryptanalyst will know or guess that you've
done this, and immediately has one bit of known data from
every byte -- the low bit, which is where the 8th bit got
shifted from the first try.
My idea was: skip one bit of the OTP if the ciphertext
contains more than 10% letter tripletts.
Usually the ciphertext will contain 20% letters, 4% doubletts,
0.8% tripletts, 0.4% tripletts with at least one vowel.
If the whole text contains 10% tripletts of this kind,
it is still not yet readable. Thus, if you automatically
discard ciphertexts with more letter tripletts, you never
transmit readable text. Yet you have to discard a very small
number of all your texts!
*If* the adversary has a realistic reason to assume that the
actual ciphertext was modified in this way, he really knows
about 10% of all low order bits. But he doesn't know, which
ones. If he checks the frequency of any specific bit, he also
*knows* some 10% of these bits because of the non-uniform
distribution of individual bits in plain ASCII texts. He may
easily find out how many lower or upper case letters or digits
are contained in you message.
In order to avaoid this kind of leak of the OTP technique
you should not apply it to ASCII texts, but compress them
beforehand. Usually, the bit frequencies in compessed files
are fairly uniform. But: this amount of "information" which
is inherent to OTP of ASCII texts, is usually not considered
a (theoretical) problem.
... Skip the whole damned thing and start over N bytes
down. You're now back in the dicey business of pre-qualifying
pads because of perceived patterns, but that's a much lower
risk than giving away 1/8 of your message.
I don't know which of the two proposed methods will be better.
The last one consumes more of the OTP, thus I would prefer the
first one.
Ciao, Gunter
--
From: [EMAIL PROTECTED]
Subject: Why this simmetric algorithm is not good?
Date: Mon, 05 Jul 1999 12:01:21 GMT
Hi,
I'm not a experimented cryptanalyst but there is an encryption algorithm
(written in a Pascal-like language).
procedure cipher(Key : uint128 ; plain: file ; cipher : file)
var Kaux: uint128
begin
setRandomSeed(Key);
c = 2^128 - 1
while not EOF(plain)
begin
Kaux := c xor Random(0..2^128-1)
p := getNext128bits(plain)
c := p xor Kaux
writeNext128bits(cipher, c)
end
end
What's wrong with this algorithm, besides the Random function strength?
Gabriel
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
--
From: "Dr.Gunter Abend" [EMAIL PROTECTED]
Sub
