Cryptography-Digest Digest #774
Cryptography-Digest Digest #774, Volume #13 Fri, 2 Mar 01 02:13:00 EST
Contents:
Re: philosophical question? ("Douglas A. Gwyn")
Re: super-stong crypto, straw man phase 2 ("Douglas A. Gwyn")
Re: encryption and information theory (Benjamin Goldberg)
Re: "RSA vs. One-time-pad" or "the perfect enryption" ("Douglas A. Gwyn")
Re: Rabin's Unbreakable Code ("Douglas A. Gwyn")
Re: "RSA vs. One-time-pad" or "the perfect enryption" (David Wagner)
Re: Safe to use DSS key for DH? (David Wagner)
Re: => FBI easily cracks encryption ...? ("groj")
Re: => FBI easily cracks encryption ...? ("groj")
RSA Key Generation ("Mark Reed")
Re: RSA Key Generation ("Roger Schlafly")
Re: => FBI easily cracks encryption ...? (nemo outis)
Re: => FBI easily cracks encryption ...? (Nemo psj)
Re: Sad news, Dr. Claude Shannon died over the weekend. (wtshaw)
Re: Fractal encryption? (David A Molnar)
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers,de.sci.informatik.misc,sci.math
Subject: Re: philosophical question?
Date: Fri, 02 Mar 2001 03:33:00 GMT
"Joe H. Acker" wrote:
> but when I listen to white noise in my radio, it might not.
> Randomness itself does not convey any information, ...
It certainly does, it's just not information that has value to you.
It could well have value in other contexts.
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: super-stong crypto, straw man phase 2
Date: Fri, 02 Mar 2001 03:41:10 GMT
William Hugh Murray wrote:
> "Douglas A. Gwyn" wrote:
> > William Hugh Murray wrote:
> > > In any case, most of us do not worry about keeping secrets from
> > > nation states for a long time.
> > Well, you should!
> I admit that I do like to confound authority.
Another point is that "super strong crypto" ought to mean that
*nobody* can come up with a practical attack; if you allow that
some "nation-state" can successfully attack a given system, then
that demonstrates that that system was not "super strong".
--
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: encryption and information theory
Date: Fri, 02 Mar 2001 03:42:26 GMT
Mxsmanic wrote:
>
> "John Savard" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>
> > More precisely: if the message contains N bits of
> > information, and occupies M bits of bandwidth, and
> > the K is K bits long, the entropy of the encrypted
> > message is N+K bits, *or* M bits, whichever is less.
>
> The entropy can never be less than N+K, or the original plaintext
> message will be lost (because information has been permanently lost).
> Thus, M must always be equal to or greater than N+K, if the original
> message is ever to be recovered.
Oh? Suppose I have a message, which was 128 bits from a TRNG. Now I
encrypt with Rijndael, using a 128 bit blocksize, and 128 bit key, where
the key was also generated by a TRNG. Now I send that ciphertext. Are
you saying that the 128 bit ciphertext has 256 bits of entropy?
The way the apparent paradox probably can be resolved is through the
statement "Entropy that can be seen is not true entropy." If we, the
attacker, know both the plaintext and ciphertext, then both plaintext
and ciphertext have 0 entropy (because they've been seen by us).
If we have only the ciphertext, then the ciphertext has 0 entropy, but
the key and the message still have K and N bits of entropy.
The rather peculiar conclusions we get from the above paragraph (
M=N=0 -> K=0
M=0 -> N+K=0
) mean that we cannot do arithmatic with entropy in aconventional
manner.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: "RSA vs. One-time-pad" or "the perfect enryption"
Date: Fri, 02 Mar 2001 04:06:06 GMT
Steve Meyer wrote:
> >It will be interesting to see your argument. I know of no
> >evidence that this was a factor. If you turn the question
> >around and ask, why did workers for government cryptologic
> >organizations get there first, an obvious answer would be:
> >They had more experience, more support, and more at stake.
> I do not think they did, i.e. only evidence seems to be popular
> book (see my rump talk).
Are we talking about the same thing -- the discovery of
nonsecret encryption (aka public-key encryption)
Cryptography-Digest Digest #774
Cryptography-Digest Digest #774, Volume #12 Mon, 25 Sep 00 20:13:00 EDT
Contents:
Re: Tying Up Loose Ends - Correction (Tim Tyler)
Re: What make a cipher resistent to Differential Cryptanalysis? (Tom St Denis)
Re: What make a cipher resistent to Differential Cryptanalysis? (Tom St Denis)
A Different Kind of Quantum Computer ("A. Melon")
nonlinear decorrelation idea... (tom's learning calculus :)) (Tom St Denis)
Re: On block encrpytion processing with intermediate permutations (Mok-Kong Shen)
Re: What make a cipher resistent to Differential Cryptanalysis? (Mok-Kong Shen)
Re: Question on biases in random-numbers & decompression (Tom St Denis)
Re: What make a cipher resistent to Differential Cryptanalysis? (Mok-Kong Shen)
differnetials... (Tom St Denis)
Re: differnetials... (Tom St Denis)
Re: Question on biases in random-numbers & decompression (Bob Harris)
Re: Question on biases in random-numbers & decompression (Benjamin Goldberg)
Re: Tying Up Loose Ends - Correction (Mok-Kong Shen)
FREEFONE,NO LIMITS (Free service)
Re: rc4 -- repetition length ([EMAIL PROTECTED])
Re: Question on biases in random numbers & decompression (Benjamin Goldberg)
Re: What make a cipher resistent to Differential Cryptanalysis? (Tom St Denis)
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Tying Up Loose Ends - Correction
Reply-To: [EMAIL PROTECTED]
Date: Mon, 25 Sep 2000 22:01:55 GMT
Bryan Olson <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Bryan Olson wrote:
:> : With no attack better than exhaustive
:> : search you have no way to rapidly eliminate any large class of keys.
:>
:> You might well have a method that works much faster than decrypting
:> blocks and analysing the plaintext for known characteristics.
:> The latter might require a number of blocks and take a non-trivial
:> volume of processing.
: Yes, you can work on reducing that constant. The mistake is
: pretending it does something to the keyspace.
It doesn't do anything to the keyspace. This was the point of my attempts
to distinguish the "effective keyspace" from the actual keyspace.
The "effective keyspace" contains the keys that can't be dismissed out
of hand on a priori grounds - and may need further consideration.
I've said if this is likely to rub people up the wrong way then they are
invited to present an alternative concise way of saying operation X
"reduces the effective keyspace by five bits".
To clarify, the "operation X" in question in this instance is something
that allows 31/32 keys to be rapidly rejected on a-priori grounds, without
consideration of the text of the message sent.
I'm reasonably happy with my usage. Yes, one can discuss how much
and what sort of "effect" something needs to be to be described as
"effective" - but this sort of issue seems likely to crop up regardless
of what terminology is used.
:> : The problem is a conceptual error and cannot be fixed by adjusting
:> : terminology.
:>
:> I don't think so - the issue appears to be purely terminological.
: No. The effect of the keyspace is still there. [...]
I don't think I ever said that these keys could be discarded without doing
any work at all.
In fact, *if* the cypher has been broken, being supplied with known
plaintext can sometimes rule out keys en mass, with practically no work.
This would be a case of the "ineffective keyspace" being *extremely*
ineffective ;-)
Of course, normally, one would hope that this is not the case.
: If I give you a thousand bits of Blowfish (448-bit key) ciphertext and
: corresponding plaintext, what's the "effective keyspace"?
Probably very small, to the point of being practically non-existent.
The work required to reject each key is about as small as it can
ever be expected to be, and - in all liklihood - enough information is
supplied to be able to reject all but the correct key.
--
__ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
--
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What make a cipher resistent to Differential Cryptanalysis?
Date: Mon, 25 Sep 2000 22:18:33 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> Tom St Denis wrote:
> >
> > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > >
> > > Tom St Denis wrote:
> > > >
> > > > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > >
> > > > > "Paul L. Hodgkinson" wrote:
> > > > > >
> > > > > > "Mok-Ko
Cryptography-Digest Digest #774
Cryptography-Digest Digest #774, Volume #11 Mon, 15 May 00 00:13:00 EDT
Contents:
Re: S-BOX Construction Tutorial? (John Savard)
Re: Notes on the "Vortex" block cipher (Tim Tyler)
Re: (May 11, 2000) Cipher Contest Update (Tim Tyler)
Re: Destructive crypting (Tim Tyler)
Yet another sci.crypt cipher (Tom St Denis)
Re: Unbreakable encryption. (Anthony David)
Re: S-BOX Construction Tutorial? (Terry Ritter)
Re: Notes on the "Vortex" block cipher (Terry Ritter)
Definition of "Broken" Cipher (Tom St Denis)
Re: Notes on the "Vortex" block cipher (Tom St Denis)
Re: S-BOX Construction Tutorial? (Tom St Denis)
Re: Yet another sci.crypt cipher (Tom St Denis)
Re: Key generation for lja1 (Benjamin Goldberg)
Re: About Hardware RNG ("Steve and Darla Wells")
Re: How does one test an encryption algorithm? (SCOTT19U.ZIP_GUY)
Snappy Block Cipher (key schedule) (Tom St Denis)
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: S-BOX Construction Tutorial?
Date: Mon, 15 May 2000 00:01:58 GMT
On Sun, 14 May 2000 20:43:51 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>My approach is to try to eliminate every ghost of weakness I can see.
>I suppose others have different approaches.
It does appear that many others seem to have the approach of not
putting anything in a cipher that they don't understand...which leads
to using only things that _are_ potentially weak (but strong enough
not to fall to known attacks).
I prefer your approach, and I try to use it myself.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
--
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Notes on the "Vortex" block cipher
Reply-To: [EMAIL PROTECTED]
Date: Sun, 14 May 2000 23:42:03 GMT
Bruce Schneier <[EMAIL PROTECTED]> wrote:
: Tom St Denis <[EMAIL PROTECTED]> wrote:
:>I noted in the F function there is a very simple compression of four 16
:>bit values given
:>
:>F(a, b, c, d) = ((a ^ b) + c) ^ d -> a'
:>
:>Then only a' is passed thru the sboxes Wouldn't it be possbible to
:>create a quadruple so that the input difference is fixed?
: All the non-linearity is in the carry bit. If this is a straight
: Feistel network with this round function, you're going to need a LOT
: of rounds to be secure.
I don't think that's what is being proposed.
The round function seems to be quite complicated.
It appears that there's also an 8-bit s-box, applied to both halves of a,
b, c and d in turn, and then to all the bytes in the block.
--
__ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Be good, do good.
--
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: (May 11, 2000) Cipher Contest Update
Reply-To: [EMAIL PROTECTED]
Date: Sun, 14 May 2000 23:55:08 GMT
David A Molnar <[EMAIL PROTECTED]> wrote:
: What about an attack which just distinguishes the cipher from an
: "ideal" or "truly random" permutation over the blocksize? That is,
: suppose I am able to prove that a cipher always outputs blocks with even
: parity or something else that doesn't "look random," but I can't turn
: that into a key-recovering or plaintext-recovering attack. What happens
: then? [...]
I think a block cypher [i.e. keyed permutation] that always outputs blocks
with even parity is impossible ;-)
As for distinguishing the output from that of a random permutation - I
personally think some sort of attack that provides information about
key or plaintext bits - and which takes less effort than brute force -
should be required.
--
__ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ This tagline no verb.
--
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Destructive crypting
Reply-To: [EMAIL PROTECTED]
Date: Mon, 15 May 2000 00:07:13 GMT
Daniel Åkerud <[EMAIL PROTECTED]> wrote:
: Is there a one-way hash algorithm that takes an arbitrary key as a parameter?
Yes: "Message Authentication Codes" (MACs).
Sometimes folks seem to use use Hash(Key,Message) as a way of building
MAC(Message). Doing this may be slower than using a dedicated MAC.
--
__ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Goodbye cool world.
--
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Yet another sci.crypt cipher
Date: Mon, 15 May 2000 01:52:18 GMT
I just finished my package for another block cipher. I don't have the
warm fuzzy feeling about it, but I would still like to see what you
guys c
Cryptography-Digest Digest #774
Cryptography-Digest Digest #774, Volume #10 Mon, 20 Dec 99 18:13:01 EST
Contents:
Access User Level Security and Export Regulations ("John E. Kuslich")
Re: Keystrokes monitored/encryption useless (Liyang Hu)
Re: Code Puzzle (Jim Gillogly)
Re: Analogue encryption (Jim)
Re: Analogue encryption (Jim)
Re: Analogue encryption (Jim)
Re: Code Puzzle (Rich Lafferty)
Re: Analogue encryption (Paul Rubin)
Re: Q: transcendental pad crypto ("dls2")
Re: Q: transcendental pad crypto ("dls2")
Re: Analogue encryption (Simon DeDeo)
Re: Q: transcendental pad crypto ("dls2")
Re: Q: transcendental pad crypto (John Savard)
Re: Q: transcendental pad crypto (John Savard)
Re: Q: transcendental pad crypto (John Savard)
Re: Q: transcendental pad crypto (Pelle Evensen)
Re: Enigma - theoretical question (Roger Carbol)
Re: dictionary attack (Roger Carbol)
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Access User Level Security and Export Regulations
Date: Mon, 20 Dec 1999 12:22:38 -0700
Here is an example of why the Clinton Administrations one-time review
policy for cryptographic software is completely bogus. Any software on
the PC can be made to act in arbitrary ways using the readily available
Windows API. One does not need access to source code. It does not
matter how the software is compartmentalized, or modularized. Anyone
can write software that takes control of executable code and have his
way with it. Did you say you want a key lenght of 400 bits?? Want
triple DES AND Blowfish at a zillion bits?? No problem, want to see the
red suit, turn on the red light!
CRAK Software ( http://www.crak.com ) has just released a beta version
of a NEW password recovery product for Access Database. This new
software effectively defeats all User level security by allowing the
log-on password dialog to be by-passed and by revealing all database
user account names.
The new software, called AXcrak, launches Access in a very promiscuous
mode allowing any password you can imagine to be used as a valid log-on
password.
AXcrak allows the user to log on as a user having Admins privileges
without the need to know the log-on password. Once logged on as an
Admins user, the database user passwords can be changed and/or removed
(again, without having a valid password).
The user must have access to a valid system.mdw file (this is where all
user account password information is stored).
The product is in beta release as demo and full performance products
from http://www.crak.com under the /programs directory (Axdemo.exe and
AXfull.exe). The demo has limitations :-))
This new release presently ONLY WORKS with Access using the MSJT3032.dll
version 3.000.4513 (Version 7.0 of Access for Office 95). All versions
of Access will be covered by future releases of AXcrak.
This a new beta release. If you experience problems please send your
comments to [EMAIL PROTECTED] Your help would be greatly appreciated.
Anyone with an urgent need to recover a password protected database (for
which they can legally certify ownership!) generated in another
version of Access is urged to contact CRAK Software at
[EMAIL PROTECTED] We may be able to help.
JK
--
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.com
--
From: Liyang Hu <[EMAIL PROTECTED]>
Subject: Re: Keystrokes monitored/encryption useless
Date: Mon, 20 Dec 1999 00:56:30 -
At 18 Dec 1999 14:25:59 EST, Guy Macon <[EMAIL PROTECTED]> said:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Liyang
>Hu) wrote:
> >
> >It's very easy to spot those programs running, as long as you keep an eye
> >out for them. A useful little util, which just happens to
> >be called Useful, has a very good process monitor. Anytime I see anything
> >running that I dont know the purpose of, I can just kill that process. It
> >sees all processes, as opposed to , which only shows the
> >non-service processes. You can get it at http://www.nerv.cx/hcbd/ >shameless plug>
>
> I like to run a couple of 30AWG wire wrap wires into the plug on the
> back of your PC and connect a Basic Stamp [ http://www.parallaxinc.com/ ]
> and have it record keystrokes. It's about the size of a postage stamp,
> and there are cool RF transmitter modules available. This allows me to
> get the NT Logon password, which no sniffer program can get. For that
> matter. there are TX cameras that look through pinholes in your walls
> or ceiling. I could make a video of your hands on the keyboard and
> of what is displayed on your screen.
Assuming the person cannot reach your machine physically. I'm talking
about software security here, not things like surveillance or tempest
attacks. Sli
Cryptography-Digest Digest #774
Cryptography-Digest Digest #774, Volume #9 Fri, 25 Jun 99 14:13:03 EDT
Contents:
Re: Online material? (JPeschel)
Re: Bytes of "truly random" data for PRNG seed. (fungus)
HELP: FIPS 140-1 for Browser Engine ([EMAIL PROTECTED])
DES-NULL attack ([EMAIL PROTECTED])
Re: CBC mode (?) ([EMAIL PROTECTED])
Re: "Breaking" a cipher ([EMAIL PROTECTED])
Re: Bytes of "truly random" data for PRNG seed. ([EMAIL PROTECTED])
Re: DES-NULL attack ([EMAIL PROTECTED])
Categorize a RNG ([EMAIL PROTECTED])
Re: Bytes of "truly random" data for PRNG seed. ("Douglas A. Gwyn")
Re: one time pad (Patrick Juola)
Re: "Breaking" a cipher (JPeschel)
Re: one time pad (John Savard)
Re: Dundee Society (John Savard)
Re: VIC cipher now described on web site (John Savard)
Re: one time pad (John Savard)
Re: The Constrained One-Time Pad and the Cryptanalyst's Lucky Day (John Savard)
Re: one time pad (Jim Felling)
Re: CBC mode (?) (Eric Young)
Re: one time pad (John Briggs)
Re: one time pad ("Douglas A. Gwyn")
Tough crypt question: how to break AT&T's monopoly??? (Jayjames99)
Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length? (Medical
Electronics Lab)
Re: one time pad (Greg Ofiesh)
Re: Kryptos article (Jim Gillogly)
Re: one time pad (Terry Ritter)
Re: RC4 Susectability ([EMAIL PROTECTED])
Re: one time pad (Mickey McInnis)
LOKI 89,91; Safer K-64, K-128 (JPeschel)
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Online material?
Date: 25 Jun 1999 12:03:22 GMT
>[EMAIL PROTECTED] writes:
>Does anyone know of any online materials available for a newbie
>interested in cryptanalysis? I'm talking about real basic stuff that'd
>cover the math/number theory involved...
Menezes' chapter 2 from his book is on his web site. Might
be helpful.
http://www.cacr.math.uwaterloo.ca/hac/
Joe
__
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__
--
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Bytes of "truly random" data for PRNG seed.
Date: Fri, 25 Jun 1999 15:17:55 +0200
Benjamin Goldberg wrote:
>
> The seed generator used in java.security.SecureRandom says that it
> "has not been thoroughly studied or widely deployed." Does anyone know
> how I could go about verifying that the bytes provided by that method are
> "truly random," in the sense that they are usable for cryptographic
> purposes?
>
That's the fun part - you can *never* prove a number is random
just by looking at it. "When is a number not random" has been
a thread in this newsgroup since it was started.
The Blum Blum Shub I mentioned earlier is supposed to be "provably
good" but I have to confess I don't know much about the algorithm
or how the proof works.
--
<\___/>
/ O O \
\_/ FTB.
--
From: [EMAIL PROTECTED]
Subject: HELP: FIPS 140-1 for Browser Engine
Date: Fri, 25 Jun 1999 13:48:50 GMT
Can anyone give me the FIPS 140-1 compliance status for the encryption
engines of Microsoft IE and Netscape Navigator.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
--
From: [EMAIL PROTECTED]
Subject: DES-NULL attack
Date: Fri, 25 Jun 1999 14:04:43 GMT
Suppose we use DES encryption algorithm.
Let a plain text block contains only bits with NULL value.
Then correspondent cipher block is well-defined function
of the encryption key, which can be recovered.
For more details please follow the link 'DES-NULL attack'
at
Regards
Alex
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
--
From: [EMAIL PROTECTED]
Subject: Re: CBC mode (?)
Date: Fri, 25 Jun 1999 13:50:08 GMT
In article <7ku1qe$1pp$[EMAIL PROTECTED]>,
"Serge" <[EMAIL PROTECTED]> wrote:
> I did find a test array for Blowfish in CBC mode. Length of array 29
bytes.
> Is there a standart method to fill last block up to 8 bytes? I did
try to
> fill last 3 bytes with zero, but it was wrong.
Normally you pad with zeroes except the last bit is a one. This is
like hash functions I believe.
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: [EMAIL PROTECTED]
Subject: Re: "Breaking" a cipher
Date: Fri, 25 Jun 1999 13:53:03 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (JPeschel) wrote:
> As it happens, I also encrypted
