Cryptography-Digest Digest #206
Cryptography-Digest Digest #206, Volume #14 Sun, 22 Apr 01 09:13:01 EDT
Contents:
Re: Diffie-Hellman signatures now described ("Tom St Denis")
Re: Better block cipher pre/post whiten step ("Tom St Denis")
Re: Better block cipher pre/post whiten step (Mok-Kong Shen)
Re: Note on combining PRNGs with the method of Wichmann and Hill (Mok-Kong Shen)
Re: Better block cipher pre/post whiten step ("Tom St Denis")
Re: Why re-using the pad is not secure? (Leonard R. Budney)
Re: Better block cipher pre/post whiten step ("Tom St Denis")
Re: Better block cipher pre/post whiten step (Mok-Kong Shen)
Re: XOR TextBox Freeware: Very Lousy. ("Szopa Swings Again"@anon.lcs.mit.edu,
[EMAIL PROTECTED])
Re: Cryptanalysis Question: Determing The Algorithm? (Leonard R. Budney)
Re: Better block cipher pre/post whiten step ("Tom St Denis")
Re: Will this defeat keyloggers ? ("Thomas J. Boschloo")
basics of cryptography (Pille2)
Re: basics of cryptography ("Tom St Denis")
Re: basics of cryptography (Pille2)
Re: basics of cryptography ("Tom St Denis")
From: "Tom St Denis" [EMAIL PROTECTED]
Subject: Re: Diffie-Hellman signatures now described
Date: Sun, 22 Apr 2001 10:30:38 GMT
"John Savard" [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
On Fri, 20 Apr 2001 00:40:13 GMT, "Tom St Denis"
[EMAIL PROTECTED] wrote, in part:
DH afaik describes a key exchange protocol involving the DLP.
But everything using the DLP cryptographically is derived from DH,
since DH represents the realization that the DLP could be used in this
manner.
That's like saying MARS is based on RC5 because it uses data dependant
rotations...
Tom
--
From: "Tom St Denis" [EMAIL PROTECTED]
Subject: Re: Better block cipher pre/post whiten step
Date: Sun, 22 Apr 2001 10:32:45 GMT
"Mok-Kong Shen" [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Tom St Denis wrote:
It's really simple. If you use a decorrelated function such as F(x) =
ax +
b (a,b are round keys a != 0) all in GF(2^W) then your entire cipher
would
be xor-linear.
Which means an input difference of (a,b) - (d,e) would hold with a
probability of 1 over all plaintexts, obviously not very random
behaviour.
Not only that you can break a three round feistel build with this with
only
2 plaintexts/ciphertexts.
My idea is to hide the linearness behind the core cipher, and to hide
any
known biases of the core cipher (linear or differential) behind the
decorrelated functions.
Sorry for one more questions: Would a rotation (static
or dynamic) help in question of linearity?
The rotation must be data dependent and keyed for it to be non-linear.
Tom
--
From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: Better block cipher pre/post whiten step
Date: Sun, 22 Apr 2001 12:42:07 +0200
Tom St Denis wrote:
The rotation must be data dependent and keyed for it to be non-linear.
Yes. But isn't it very fine for improving the strength? (I
ignore the possible Hitachi patent issue).
M. K. Shen
--
From: Mok-Kong Shen [EMAIL PROTECTED]
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Note on combining PRNGs with the method of Wichmann and Hill
Date: Sun, 22 Apr 2001 12:49:49 +0200
Bryan Olson wrote:
[snip]
You cannot justify a bogus result by restating it a
different form. You've no evidence that one cannot break
your scheme if he cannot solve the corresponding problem
against Wichmann-Hill.
[snip]
I think that you are too much theory-oriented (I am not
against that). Wichmann and Hill (WH for short) has
the effect of producing more uniformity with practically
available not very uniform generators. That effect is
non-perfect but tends (in general) to be better when the
number of PRNGs increases. Now this effect is also
dependent on the quality of the PRNGs themselves.
If these are bad enough, then the result will also be
quite poor. So with WH one is not doing any 'perfect' job
anyway. Now given R1 = r1 + r2 mod 1, one achieves 'some'
uniformity. The same holds for R2 = r3 + r4 mod 1,
where I define r3 = c1*r1 and r4 = c2*r2. It is true
that r3 and r4 would be non-uniform if r1 and r2 were
perfectly uniform. But r1 and r2, being obtained in
practice, are more or less non-uniform from the outset.
r3 and r4 are in general worse PRNGs than the (also
non-perfect) r1 and r2. How much worse evidently depends,
among others, on the magnitude of c1 and c2. My opinion
is that small enough deviations from 1.0 of c1 and c2
would lead to deterioration of R2 (in comparison to R1)
that is practically negligible. Gladman strongly opposed
to that, saying that even slight deviations from the
original WH
Cryptography-Digest Digest #206
Cryptography-Digest Digest #206, Volume #13 Wed, 22 Nov 00 09:13:00 EST
Contents:
Re: A poorman's cipher (Mok-Kong Shen)
Re: Entropy paradox (Tom St Denis)
Re: Entropy paradox (Tom St Denis)
Re: Pseudo random sequence generation for xor encryption (OTP) (Tom St Denis)
New Dynamic Algo + Contest + Doc (Sylvain Martinez)
Re: Internet Voting Questions ([EMAIL PROTECTED])
Re: vote buying... (Jeffrey Williams)
Re: New Dynamic Algo + Contest + Doc (Paul Crowley)
Re: Randomness from key presses and other user interaction (Alfons Adriaensen)
From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: A poorman's cipher
Date: Wed, 22 Nov 2000 13:33:46 +0100
Michael Scott wrote:
"Mok-Kong Shen" [EMAIL PROTECTED] wrote:
Addendum (III)
Globally, it may be observed that, while the common block
ciphers work vertically in the sense of first attempting
to achieve as much diffusion as possible within a small
number of bits inside a block and then attempting to
achieve diffusion throughout the message via block chaining,
..
That's why Rijdael/Square is such a nice idea. By arranging the state as a
block of 4x4 bytes much tighter coupling is acheived between the individual
elements and hence much quicker diffusion. I wonder has anyone extrapolated
the idea to "CUBE", or perhaps a tesseract?
As explained, our scheme follows a different principle
('philosophy') than what is done with block ciphers. In fact,
one can either view a message as being treated as a single
block or view the message as being processed with stream
techniques (in both cases with a variable number of passes
or rounds).
M. K. Shen
--
From: Tom St Denis [EMAIL PROTECTED]
Subject: Re: Entropy paradox
Date: Wed, 22 Nov 2000 12:30:05 GMT
In article [EMAIL PROTECTED],
Mok-Kong Shen [EMAIL PROTECTED] wrote:
Tom St Denis wrote:
Mok-Kong Shen [EMAIL PROTECTED] wrote:
This is a re-formulation of an issue that I questioned
previously. Suppose one has m perfectly random bits and
uses that in some appropriate way to get a BBS generator
to generate u bits, with u m. We know that (accepting
certain plausible assumptions) the u bits are provably
secure. It seems thus that we have obtained more entropy
that way, i.e. having obtained an amount of additional
entropy from nothing. How is this apparent paradox to be
properly explained? (Or does each bit of the generated
sequence have in average m/u bits of entropy?) Thanks in
advance.
Hmm there can't be any more entropy then that contained in the
factors
of the BBS modulus. The outputted bits may appear random but are no
more random then the size of the modulus. Look at RC4 for
example. It
may be able to output 2^30 bits, but in reality there are only 2^k
bits
required to distinguish the output from random (k 2^30).
So if BBS generates u bits and I take m bits out of it,
how much entropy is in there? Thanks.
There is no more entropy then in the moduli and original starting point
of the BBS generator. The new bits made are NOT RANDOM they just
appear that way. Thus, entropy is not increasing.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Tom St Denis [EMAIL PROTECTED]
Subject: Re: Entropy paradox
Date: Wed, 22 Nov 2000 12:31:55 GMT
In article [EMAIL PROTECTED],
Mok-Kong Shen [EMAIL PROTECTED] wrote:
I suppose that BBS and its assumptions and proof are known.
I assume that you do the best so that all the entropy in
the given m bits are incorporated into the generator. In
other words, BBS is viewed as a black box with m bits as
input and u bits as output. Is this concept clear? Or do
you contend the correctness of the assumptions and/or
the proof of BBS? Thanks.
The output of BBS is not random though. So no new entropy is created.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Tom St Denis [EMAIL PROTECTED]
Subject: Re: Pseudo random sequence generation for xor encryption (OTP)
Date: Wed, 22 Nov 2000 12:35:10 GMT
In article [EMAIL PROTECTED],
Mok-Kong Shen [EMAIL PROTECTED] wrote:
Ivan Skytte Jørgensen wrote:
What is the best way of producing a pseudo random sequence for use
with
xor encryption?
Standard texts on crypto have materials on PRNGs. I have
a scheme of building a compound PRNG consisting of an
arbitrary number of constituent PRNGs (of arbitrary type)
on my web page. PRNGs are deterministic and hence 'in
principle' always crackable, though I haven't yet seen
a feasible way of cracking my compound PRNG 'in practice'.
What Knuth calls Algorithm.M is a good way to take too long perioded
PRNGs and turn them into one long perioded non-linear PRNG. You can
take too parallel LFSRs (i.e using word-wise xor and such) or two LF
Cryptography-Digest Digest #206
Cryptography-Digest Digest #206, Volume #9Tue, 9 Mar 99 12:13:03 EST
Contents:
Re: RC5 and RC6 code (free code) + update ([EMAIL PROTECTED])
Re: Limitations of testing / filtering hardware RNG's (Mark Currie)
I am on a role (RC4, RC5, RC6) ([EMAIL PROTECTED])
Re: Limitations of testing / filtering hardware RNG's (R. Knauer)
Re: RC5 and RC6 code (free code) ([EMAIL PROTECTED])
Re: DIE HARD and Crypto Grade RNGs. (R. Knauer)
Cyclotomic Number Generators (R. Knauer)
Re: Has anyone given easy-to-understand descriptions of encryption methods? ("almis")
Re: Yarrow (Simon Shepherd)
Does RC4 have the same problems as OTP? ([EMAIL PROTECTED])
Re: DIE HARD and Crypto Grade RNGs. (R. Knauer)
Ecommerce - Govt. consultation document ([EMAIL PROTECTED])
Re: DIE HARD and Crypto Grade RNGs. (R. Knauer)
Re: Testing Algorithms [moving off-topic] (Patrick Juola)
Re: Modular Multipliers (Henry Lewsal)
Re: DIE HARD and Crypto Grade RNGs. ([EMAIL PROTECTED])
Re: Limitations of testing / filtering hardware RNG's (Mark Currie)
Re: DIE HARD and Crypto Grade RNGs. (Patrick Juola)
Re: Does RC4 have the same problems as OTP? (Kent Briggs)
From: [EMAIL PROTECTED]
Subject: Re: RC5 and RC6 code (free code) + update
Date: Tue, 09 Mar 1999 11:28:07 GMT
They're happy for people to use the algorithm. However, they're in
business to make money, and figure that since they invented this thing
they're entitled to a profit from the sweat of their skull, so they
license it. They publish it so that people can see how clean and tidy
the structure is and can evaluate its suitability for their applications.
All seems consistent to me. However, if there are free alternatives that
have similar perceived strength and tidiness, the market is limited to
companies with specific needs... like the need to buy from a Known Name.
That's true. I still think there shouldn't be restrictions on open source or
non-profit programs. I am just learning. Hmm. Well I wait for a reply from
SecurityDynamics...
Tom
= Posted via Deja News, The Discussion Network
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
--
From: [EMAIL PROTECTED] (Mark Currie)
Subject: Re: Limitations of testing / filtering hardware RNG's
Date: 9 Mar 1999 10:17:55 GMT
In article [EMAIL PROTECTED], [EMAIL PROTECTED]
says...
On 8 Mar 1999 20:20:02 GMT, [EMAIL PROTECTED] (Mark Currie) wrote:
One way to limit the damage in this situation would be to always hash the
output with a PRNG.
I have asked people who want to use hash functions to fix errors in
TRNGs to demonstrate that they do not cause unwanted correlations to
become manifest. Thus far I have not gotten an answer, which makes me
a bit suspicious that hash functions *might* actually do more harm
than good.
You may be right. Unfortunately though, practical systems that are not allowed
to produce weak keys under any circumstances, cannot rely on a hardware RNG
entirely. The output must be tested and filtered to some degree.
Again we are talking about the secruoty of the OTP cryptosystem, and
how to generate crypto-grade keystreams for it. And until that issue
is cleared up, it is ill advised to use a hash to clean up the output
of a TRNG.
I am mainly concerned with the RNG used for key generation (symmetric or
asymmetric keys), not specifically for use with an OTP.
Mark Currie
--
From: [EMAIL PROTECTED]
Subject: I am on a role (RC4, RC5, RC6)
Date: Tue, 09 Mar 1999 02:50:23 GMT
Well I am really bored so I looked up RC4 too. I have an implementation which
actually is more portable (no WORD define) then the others. It works with the
test vectors I used. It's at:
http://members.tripod.com/~tomstdenis/rc4.c
http://members.tripod.com/~tomstdenis/rc5.c
http://members.tripod.com/~tomstdenis/rc6.c
All of them were tested in Micro-C (RC5 and RC6 were tested in DJGPP too). If
you would like to get a free copy of Micro-C checkout
'http://www.dunfield.com'. Note: I am not trying to spam, just to let you
know where I got my tools from.
I got the RC4 from a post on a website. I dunno if it's RSA RC4 but it looks
pretty solid. It works slightly different then RC5 and RC6. It uses the same
reversible function to decrypt. Also the session key (rc4_key) is a little
larger then the RC5/RC6 session keys.
Take a look, make comments if you wish. Enjoy.
Tom
= Posted via Deja News, The Discussion Network
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
--
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Limitations of testing / filtering hardware RNG's
Date: Tue, 09 Mar 1999 12:31:11 GMT
Reply-To: [EMAIL PROTECTED]
On 9 Mar 1999 10:17:55 GMT, [EMAIL PROTECTED] (Mark Currie) wrote:
You ma
