Cryptography-Digest Digest #815
Cryptography-Digest Digest #815, Volume #8 Wed, 30 Dec 98 09:13:07 EST Contents: WEAK4-EX -- Another Poorman's 56-bit Data Encryption Algorithm (long) (Mok-Kong Shen) New Book "The Unknowable" ([EMAIL PROTECTED]) From: Mok-Kong Shen [EMAIL PROTECTED] Subject: WEAK4-EX -- Another Poorman's 56-bit Data Encryption Algorithm (long) Date: Wed, 30 Dec 1998 13:49:07 +0100 Recently I have designed two 56-bit algorithms, WEAK2-EX and WEAK3-EX, with which the user can arbitrarily scale up the processing time and the algorithm initialization time respectively such that the expected average time for brute forcing can be rendered beyond any practically infeasible bounds. (The number of rounds in these algorithms can be suitably chosen such that brute forcing would be the only viable means of analysis.) Thus, in exchange for some tolerable higher time expenditure, the user can manage to obtain adequate security despite the severe limitation posed by the forthcoming 56-bit key length restriction. The present algorithm, WEAK4-EX, is based on the same paradox-sounding paradigm 'security through inefficiency' as its two predecessors but extends the 'inefficiency' into an additional 'dimension', namely the volume of the ciphertext. It has in total three user choosable scaling factors of processing time. The first is the same as one of the two employed in WEAK2-EX and controls the time rate of pseudo-random number generation of the PRNG used. The second scaling factor determines the number of pseudo-random bits thus obtained that are to be XORed with each single bit of the plaintext. (In WEAK4-EX the plaintext is treated as a bit stream.) The third scaling factor determines (approximately) by how much the ciphertext is to be expanded through filling it with pseudo-random bits at positions that are determined by the PRNG. Let input() designate the function delivering the next bit from the plaintext and scf2 and scf3 be the second and third scaling factor mentioned above. Then the encryption with WEAK4-EX can be conceptually (not 'strictly speaking', see below) described by the following very simple probabilistic automaton, where the function pbit(m) denotes the result of XORing of m*32 pseudo-random bits obtained from the PRNG, i.e. their parity: do with probability 1/scf2: output( input() XOR pbit(scf3) ); with probability 1 - 1/scf2: output( pbit(1) ); od; In the implementation we use our PRNG (not a TRNG) to determine the transition of the automaton. Thus the actual process is not random but only a 'simulation' and is in fact deterministic, being governed by the seed of the PRNG. For otherwise the receiver of the message would have a hard task to do the decryption. Thus WEAK4-EX is a pseudo-randomized encryption. It is not a (true) randomized encryption such as the time-honoured but apparently now disfavoured homophone cipher, where the decision of the choice of the homophones can be made e.g. through casting of dices. (I suggested recently though that homophones could once again be interesting in the light of the 56-bit restriction.) Through the (simulated) probabilistic nature of the algorithm the analyst has the essential difficulty to identify which bits of the ciphertext are information-bearing, i.e. encrypted plaintext bits, and which are the filling nonsense bits. Since the information-bearing bits are themselves obtained through XORing the plaintext bit with a large number (some multiples of 32) of pseudo-random bits, brute forcing would be the only viable method of attack if the factors scf2 and scf3 are adequately chosen. The price that the user has to pay through the scaling factor scf3 is that the ciphertext is about scf3 times as large as the plaintext and hence incurs correspondingly higher transmission expenditure. However, if the plaintext is fairly short, which is very often likely to be the case in a poorman's environment, such expansion of the ciphertext, if not carried to the extreme, may well be sensible. In other cases, one can simply set scf3=1 and exclusively employ the other two scaling factors to achieve a sufficient level of security. An implementation in Fortran 90 is attached below. A binary executable file for PC can be downloaded via my main Web page. I am indebted to TPS for discussions leading to the present work. Constructive critiques, comments and suggestions for improvements are sincerely solicited. M. K. Shen = NOTE: The program codes of WEAK2-EX and WEAK3-EX have been revised (with an error reported by CWL and CK corrected). In the zip-file for download, all three encryption programs and their binaries are included. == c The design of WEAK4-EX is explained in the text of the article c introducing the present program code: c c
Cryptography-Digest Digest #816
Cryptography-Digest Digest #816, Volume #8 Wed, 30 Dec 98 15:13:04 EST
Contents:
Re: WEAK4-EX -- Another Poorman's 56-bit Data Encryption Algorithm (long) (Mok-Kong
Shen)
Re: Decoder for Reed-Solomon codes? (Jyrki Lahtonen)
Re: New Book "The Unknowable" (John Savard)
Secure Credit Card Transactions (Benzbrood)
Re: Session keys in Elliptic Curve (liminal)
Re: Secure Credit Card Transactions ("Steve Sampson")
Re: Session keys in Elliptic Curve (Anonymous)
Re: Security through obscurity in the smartcard world (liminal)
Re: "Encrypted Magic Folders" substitute ("Sam Simpson")
Re: biometrics (Anthony Stephen Szopa)
Re: Opinions on S/MIME ("Sam Simpson")
Re: "should have" for an encrypting filesystem ("Sam Simpson")
Re: Session keys in Elliptic Curve (Mr. Tines)
Re: Blowfish assembler (i386) help needed (Paul Rubin)
From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: WEAK4-EX -- Another Poorman's 56-bit Data Encryption Algorithm (long)
Date: Wed, 30 Dec 1998 15:34:51 +0100
Sorry for a typing error in text. Corrected:
do
with probability 1/scf3:
output( input() XOR pbit(scf2) );
with probability 1 - 1/scf3:
output( pbit(1) );
od;
M. K. Shen
--
From: [EMAIL PROTECTED] (Jyrki Lahtonen)
Crossposted-To: comp.dsp,sci.math
Subject: Re: Decoder for Reed-Solomon codes?
Date: 30 Dec 1998 06:57:36 GMT
You probably also need to find a primitive
element modulo 929. This shouldn't be too hard - I will come back to
this later.
If I didn't make any typos when plugging the numbers into Mathematica,
3 (or its residue class, if you want to be pedantic) is a primitive
element of GF(929), i.e. all the other non-zero elements are of the
form 3 raised to power i for a unique i in the range from 0 to 927
inclusive.
Jyrki Lahtonen, Ph.D.
Department of Mathematics,
University of Turku,
FIN-20014 Turku, Finland
Note to human e-mailers! To obtain my real e-mail address form the
string consisting of my first name, a period, my family name (names in
lower case) and an at-sign followed by utu.fi
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: New Book "The Unknowable"
Date: Wed, 30 Dec 1998 15:37:39 GMT
[EMAIL PROTECTED] wrote, in part:
Hi folks, this is to let everyone know that I've
just finished a new book, "The Unknowable".
It's a prequel/sequel to my book on "The Limits
of Mathematics". "The Unknowable" is available
in html and in postscript at these two URL's:
http://www.umcs.maine.edu/~chaitin/unknowable
http://www.cs.auckland.ac.nz/CDMTCS/chaitin/unknowable
Best wishes for 1999,
Ah. I read about you in Rudy Rucker's "Mind Tools".
His description of your famous proof was somewhat ambiguous.
Obviously, there is a simple proof that for any t, there _exist_
strings of complexity greater than t; as there are 2^(t+2) strings of
length t+2, there are insufficient strings of length t (2^(t+1)-1) to
generate them all.
What you had proved, I believe, was that for some t sufficiently
large, any finite system/machine cannot prove, for any specific
string, that that particular string has complexity greater than t.
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
--
From: [EMAIL PROTECTED] (Benzbrood)
Subject: Secure Credit Card Transactions
Date: 30 Dec 1998 16:08:30 GMT
I need the info, progs, urls, or whatever I need to make a web site with secure
transactions for an online store, subscriptions, etc. Please reply.
--
From: liminal [EMAIL PROTECTED]
Subject: Re: Session keys in Elliptic Curve
Date: Wed, 30 Dec 1998 08:58:15 -1000
Hello again.
Big thanks to both Mr. Tines and Harpy-34 for their
graceful handing of information regarding elliptic
curve cryptography.
My pleasure.
Now, as the session key-thing is effectively settled
(as far as matters anyway,) now I'd like to ask a bit
about the private key in elliptic curve, and generation
of private/public keypair.
What would be the process of generating a 160 bit
elliptic curve key?
This is so difficult that I would not even consider attempting to explain
the method. But I will outline the hurdles you would fail to surmount.
First, chose an elliptic curve which satisfies the MOV condition and
which has enough Points on it so that a search is intractible for your
adversaries. For a discussion of these tasks see:
http://ds.dial.pipex.com/george.barwood/ec_faq.txt
which George Barwood has generously posted on the WWWeb.
Public/private keylengths?
All numbers are less than 170 bits.
Does the generation of the keys correspond to
the generation methods in RSA et all?
No.
And is
a hash algorithm used in the generation, which
would impose a limit of 160 bits if for example
SHA-1 was used?
No.
- --EO
Please read these books cover to cover,
