Cryptography-Digest Digest #815
Cryptography-Digest Digest #815, Volume #13 Tue, 6 Mar 01 05:13:00 EST
Contents:
Thank You Everyone! ([EMAIL PROTECTED])
Re: Monty Hall problem (was Re: philosophical question?) (Shawn Willden)
Re: One-time Pad really unbreakable? (John Savard)
What is SRT ? ("Marc")
Re: Super strong crypto ("Douglas A. Gwyn")
Re: OT: Legitimacy of Governmental Power (Was: Re: = FBI easily crack ...?) (Paul
Crowley)
Re: How good is the KeeLoq algorithm? (Paul Crowley)
Re: Thank You Everyone! (Paul Rubin)
Re: How good is the KeeLoq algorithm? ("r.e.s.")
Re: = FBI easily cracks encryption ...? ("Mxsmanic")
Re: passphrase question (Harri Haanpaa)
Re: One-time Pad really unbreakable? ("Mxsmanic")
Re: Crypto security of pseudo-random sequences (Mok-Kong Shen)
Re: Super strong crypto ("Bryan Olson")
Re: How good is the KeeLoq algorithm? ("Jakob Jonsson")
On encryption through bit permutations (Mok-Kong Shen)
Re: What is SRT ? (Malte Borcherding)
Re: What is SRT ? (Malte Borcherding)
Re: Monty Hall problem (was Re: philosophical question?) (Joe H. Acker)
From: [EMAIL PROTECTED]
Subject: Thank You Everyone!
Date: Tue, 06 Mar 2001 04:57:14 GMT
Hello Everyone,
I just wanted to thank everyone who posts here. Being a complete
newby to this type of work, I'm learning something daily from all your
posts. I was injured at work (I was an Emergency Medical Technician)
and because of it, have had to realign my work type. I'd rather use
brains instead of brawn anyday! But, once again I thank everyone for
their support for us newbys out here and those of us just learning the
basics.
Thanks Again,
George
P.S. Feel free to e-mail me with any suggestions or comments. All
are welcome.
--
From: Shawn Willden [EMAIL PROTECTED]
Subject: Re: Monty Hall problem (was Re: philosophical question?)
Crossposted-To: sci.crypt.random-numbers,de.sci.informatik.misc,sci.math
Date: Mon, 5 Mar 2001 22:15:31 -0700
Benjamin Goldberg wrote:
Shawn Willden wrote:
[snip]
int carPos = r.nextInt(3);
int choice = r.nextInt(3);
I'm not going to comment on anything else, but nextInt(3) returns 3
random bits, or a number in the range 0..7. To get an unbiased int in
the range 0..2, you have to write your own ranmod type function.
No, you're thinking of Random.next(int bits). Random.nextInt(int n)
"Returns a pseudorandom, uniformly distributed int value between 0
(inclusive) and the specified value (exclusive), drawn from this random
number generator's sequence."
Check out:
http://java.sun.com/j2se/1.3/docs/api/java/util/Random.html#next(int)
and
http://java.sun.com/j2se/1.3/docs/api/java/util/Random.html#nextInt(int)
for further details.
Shawn.
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: One-time Pad really unbreakable?
Date: Tue, 06 Mar 2001 05:19:00 GMT
On Tue, 06 Mar 2001 03:13:40 GMT, [EMAIL PROTECTED] (Steven Smolinski)
wrote, in part:
If you can break a one-time pad if you get two ciphertexts made with the
same key, why can't you divide one ciphertext in half and apply the same
analysis?
Well, the one time pad uses a key as long as the ciphertext. So no
part of that key is used twice. Since the whole key is random, the
second half of that key has no relationship to the first half of the
key.
If you use the same key on two ciphertexts, that means the part of
that key corresponding to the shorter of the two messages is used
twice.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
--
From: "Marc" [EMAIL PROTECTED]
Crossposted-To: alt.computer.security,comp.security
Subject: What is SRT ?
Date: Tue, 6 Mar 2001 19:18:52 +1300
Hi,
I'm researching a E-commerce package which says it uses SRT to secure the
web browser
connection to the server.
I have found that SRT appears to be a Java implementation of SSL, to enable
128bit encryption outside of US. Also optimised to E Banking.
What I'm trying to find out is who did it, and has it been reviewed by the
wider
internet community. Other attempts to "optimise" SSL have resulted in it's
being
broken.
Anyone know about this product!
Thanks
Marc
--
From: "Douglas A. Gwyn" [EMAIL PROTECTED]
Subject: Re: Super strong crypto
Date: Tue, 06 Mar 2001 06:33:16 GMT
David Wagner wrote:
If lack of known attacks is our criteria, we don't need new systems.
No, you missed the point. There is *no* possible attack against
the phase 3 straw man in the classes noted, which include those
that are usually the most promising avenues for cryptanalysis.
The space of all possible cryptanalytic attacks (under the standard
scenario as previously described) can conceptually be covered
by a handful of such general classes, and if evol
Cryptography-Digest Digest #815
Cryptography-Digest Digest #815, Volume #12 Mon, 2 Oct 00 16:13:00 EDT
Contents:
Re: Maximal security for a resources-limited microcontroller (Tom St Denis)
is NIST just nuts? (Tom St Denis)
Re: is NIST just nuts? ("alex")
Idea for Twofish and Serpent Teams (Tom St Denis)
Re: Adobe Acrobat -- How Secure? ("David C. Barber")
Re: Shareware Protection Schemes (Darren New)
Re: newbie question (Albert Yang)
Re: Is RC4 a serious cipher? ("David C. Barber")
Re: How Colossus helped crack Hitler's codes (Jim)
Re: NIST Statistical Test Suite (Peter J. Acklam)
Re: It's Rijndael (Daniel Leonard)
Re: is NIST just nuts? (Albert Yang)
Re: Re: It's Rijndael (Jane Gilbert)
Re: Signature size ([EMAIL PROTECTED])
Re: hourra for europa :) (Mok-Kong Shen)
Re: Choice of public exponent in RSA signatures (John Myre)
Re: Choice of public exponent in RSA signatures (D. J. Bernstein)
Re: How Colossus helped crack Hitler's codes (Mok-Kong Shen)
Re: is NIST just nuts? (Mok-Kong Shen)
Re: Comments on the AES winner (JCA)
Re: hourra for europa :) (Frank M. Siegert)
From: Tom St Denis [EMAIL PROTECTED]
Subject: Re: Maximal security for a resources-limited microcontroller
Date: Mon, 02 Oct 2000 18:01:07 GMT
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
Sagie wrote:
Hello all,
I'm in need of a symmetric (secret key) encryption process for
one of my
projects. I would love to use one of the popular schemes, such as
blowfish
and DES, but the cipher has to be implemented in a teeny-weeny
microcontroller with very limited resources.
We could design a new system for you, that would meet your objectives
better that what you can archive using conventional technology.
What do you have that is better then publicly known methods of crypto
and implementing crypto?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Tom St Denis [EMAIL PROTECTED]
Subject: is NIST just nuts?
Date: Mon, 02 Oct 2000 18:05:54 GMT
As if that was picked... From what I understand it's not at all close
to the securest block cipher. Will aes specify that cipher with more
rounds? What a shame...
I demand a recount! Twofish should have won!
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: "alex" [EMAIL PROTECTED]
Subject: Re: is NIST just nuts?
Date: Mon, 2 Oct 2000 20:23:40 +0200
you could email monika lewinsky, she could perhaps ask the President for
that.
Tom St Denis [EMAIL PROTECTED] a écrit dans le message :
8raips$vsd$[EMAIL PROTECTED]
As if that was picked... From what I understand it's not at all close
to the securest block cipher. Will aes specify that cipher with more
rounds? What a shame...
I demand a recount! Twofish should have won!
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Tom St Denis [EMAIL PROTECTED]
Subject: Idea for Twofish and Serpent Teams
Date: Mon, 02 Oct 2000 18:15:57 GMT
Do what RSA did and make your own "Symmetric Cipher Standards" and
ignore the govt.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: "David C. Barber" [EMAIL PROTECTED]
Subject: Re: Adobe Acrobat -- How Secure?
Date: Mon, 2 Oct 2000 11:33:36 -0700
Isn't that Jack's Secret Sauce? :^)
If McDonald's has a secret sauce -- it remains a well protected secret.
*David Barber*
"Nogami" [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Acrobat is a reasonable compromise which should keep most people out
of it, but if you're going to be publishing the secret receipe for
Coke, or McDonald's "secret sauce", then you're probably safer just
not sending it at all ;P
--
From: Darren New [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: Shareware Protection Schemes
Date: Mon, 02 Oct 2000 18:38:54 GMT
Ichinin wrote:
- What would stop anyone from distributing the software WITH
a (stolen or compromised) legitemate key?
I saw an interesting mechanism once that just put the credit card number
used to pay for the software into the "About" box. Encrypted in the
executable, of course. And it wasn't worth it to me to try to track down how
to remove it, since I'd paid for the software. A simple thing like is likely
just as much a hinderance to people trying to steal it as anything more
complicated, for all the reasons already mentioned here.
--
Darren New / Senior MTS Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
The tragedy of the commons applies to monitizing eyeballs, too.
--
From: Albert Yang [EMAIL PROTECTED]
Subject: Re: newbie question
Date: Mon, 02 Oct 2000 18:40:00 GMT
cryto-libs are
Cryptography-Digest Digest #815
Cryptography-Digest Digest #815, Volume #11 Thu, 18 May 00 20:13:01 EDT
Contents:
Re: Skipjack implementation in C (this one works) ("Douglas A. Gwyn")
Re: Matching substrings in a signature (Paul Rubin)
Re: random.org? (Tim Tyler)
Re: Open source cryptography library: BeeCrypt (Paul Rubin)
Re: Unbreakable encryption. (Tim Tyler)
From: "Douglas A. Gwyn" [EMAIL PROTECTED]
Subject: Re: Skipjack implementation in C (this one works)
Date: Thu, 18 May 2000 23:09:24 GMT
/*
SKIPJACK implementation in Standard C
last edit: 25-Jan-1999 [EMAIL PROTECTED]
This is a C89 implementation of the SKIPJACK block cipher algorithm
described in version 2.0 of NSA's SKIPJACK specification dated
29 May 1998 http://csrc.nist.gov/encryption/skipjack-kea.htm.
*/
#ifdef DEBUG
#includestdio.h
#endif
/*
Interface specification:
*/
#define SJ_Keysize 10 /* (80 bits) */
/* Encryption/decryption is performed for a single 64-bit block. */
voidSJ_Encrypt ( const unsigned char *Key, const unsigned char
*Plaintext,
unsigned char *Ciphertext
);
voidSJ_Decrypt ( const unsigned char *Key, const unsigned char
*Ciphertext,
unsigned char *Plaintext
);
int SJ_Selftest ( void ); /* returns nonzero iff passed test */
/*
Implementation:
*/
static const unsigned char F[256] =
{
0xA3, 0xD7, 0x09, 0x83, 0xF8, 0x48, 0xF6, 0xF4,
0xB3, 0x21, 0x15, 0x78, 0x99, 0xB1, 0xAF, 0xF9,
0xE7, 0x2D, 0x4D, 0x8A, 0xCE, 0x4C, 0xCA, 0x2E,
0x52, 0x95, 0xD9, 0x1E, 0x4E, 0x38, 0x44, 0x28,
0x0A, 0xDF, 0x02, 0xA0, 0x17, 0xF1, 0x60, 0x68,
0x12, 0xB7, 0x7A, 0xC3, 0xE9, 0xFA, 0x3D, 0x53,
0x96, 0x84, 0x6B, 0xBA, 0xF2, 0x63, 0x9A, 0x19,
0x7C, 0xAE, 0xE5, 0xF5, 0xF7, 0x16, 0x6A, 0xA2,
0x39, 0xB6, 0x7B, 0x0F, 0xC1, 0x93, 0x81, 0x1B,
0xEE, 0xB4, 0x1A, 0xEA, 0xD0, 0x91, 0x2F, 0xB8,
0x55, 0xB9, 0xDA, 0x85, 0x3F, 0x41, 0xBF, 0xE0,
0x5A, 0x58, 0x80, 0x5F, 0x66, 0x0B, 0xD8, 0x90,
0x35, 0xD5, 0xC0, 0xA7, 0x33, 0x06, 0x65, 0x69,
0x45, 0x00, 0x94, 0x56, 0x6D, 0x98, 0x9B, 0x76,
0x97, 0xFC, 0xB2, 0xC2, 0xB0, 0xFE, 0xDB, 0x20,
0xE1, 0xEB, 0xD6, 0xE4, 0xDD, 0x47, 0x4A, 0x1D,
0x42, 0xED, 0x9E, 0x6E, 0x49, 0x3C, 0xCD, 0x43,
0x27, 0xD2, 0x07, 0xD4, 0xDE, 0xC7, 0x67, 0x18,
0x89, 0xCB, 0x30, 0x1F, 0x8D, 0xC6, 0x8F, 0xAA,
0xC8, 0x74, 0xDC, 0xC9, 0x5D, 0x5C, 0x31, 0xA4,
0x70, 0x88, 0x61, 0x2C, 0x9F, 0x0D, 0x2B, 0x87,
0x50, 0x82, 0x54, 0x64, 0x26, 0x7D, 0x03, 0x40,
0x34, 0x4B, 0x1C, 0x73, 0xD1, 0xC4, 0xFD, 0x3B,
0xCC, 0xFB, 0x7F, 0xAB, 0xE6, 0x3E, 0x5B, 0xA5,
0xAD, 0x04, 0x23, 0x9C, 0x14, 0x51, 0x22, 0xF0,
0x29, 0x79, 0x71, 0x7E, 0xFF, 0x8C, 0x0E, 0xE2,
0x0C, 0xEF, 0xBC, 0x72, 0x75, 0x6F, 0x37, 0xA1,
0xEC, 0xD3, 0x8E, 0x62, 0x8B, 0x86, 0x10, 0xE8,
0x08, 0x77, 0x11, 0xBE, 0x92, 0x4F, 0x24, 0xC5,
0x32, 0x36, 0x9D, 0xCF, 0xF3, 0xA6, 0xBB, 0xAC,
0x5E, 0x6C, 0xA9, 0x13, 0x57, 0x25, 0xB5, 0xE3,
0xBD, 0xA8, 0x3A, 0x01, 0x05, 0x59, 0x2A, 0x46
};
void
SJ_Encrypt ( const unsigned char *K, const unsigned char *P, unsigned
char *C )
{
register inti, k; /* could be unsigned char */
unsigned char counter = 0;
unsigned char temp[2];
for ( i = 0; i 8; ++i )
C[i] = P[i];
#ifdef DEBUG
printf( "%2d", counter );
for ( i = 0; i 8; ++i )
printf( " %2.2x", C[i] );
printf( "\n" );
#endif
k = 0;
do {
++counter;
temp[0] = C[6];
temp[1] = C[7];
C[6] = C[4];
C[7] = C[5];
C[4] = C[2];
C[5] = C[3];
C[2] = C[0];
C[3] = C[1];
C[2] ^= F[C[3] ^ K[k]];
if ( ++k = SJ_Keysize )
k = 0;
C[3] ^= F[C[2] ^ K[k]];
if ( ++k = SJ_Keysize )
k = 0;
C[2] ^= F[C[3] ^ K[k]];
if ( ++k = SJ_Keysize )
k = 0;
C[3] ^= F[C[2] ^ K[k]];
if ( ++k = SJ_Keysize )
k = 0;
C[0] = temp[0] ^ C[2];
C[1] = temp[1] ^ C[3] ^ counter;
#ifdef DEBUG
printf( "%2d", counter );
for ( i = 0; i 8; ++i )
printf( " %2.2x", C[i] );
printf( "\n" );
#endif
}
while ( counter 8 );
do {
++counter;
Cryptography-Digest Digest #815
Cryptography-Digest Digest #815, Volume #10 Fri, 31 Dec 99 12:13:01 EST
Contents:
Re: letter-frequency software ("r.e.s.")
Re: cryptography website(dutch)! (wtshaw)
The Cipher Challenge from the Code Book (Sisson)
Re: The Cipher Challenge from the Code Book ("Chris Williams")
Re: File format for CipheSaber-2? ("Rick Braddam")
Re: File format for CipheSaber-2? (Johnny Bravo)
DECRYPTION Urgent! ("Van Der Mussele")
Re: Cryptanalysis (TohuVohu)
Re: DECRYPTION Urgent! ("Michael Scott")
Re: File format for CipheSaber-2? (Paul Crowley)
Re: File format for CipheSaber-2? (Paul Crowley)
Re: Data Encryption in Applet? (Michel Dalle)
Re: DECRYPTION Urgent! ("Michael Scott")
Re: looking for simple RSA source (RSAEURO General)
Re: DECRYPTION Urgent! (John Savard)
From: "r.e.s." [EMAIL PROTECTED]
Subject: Re: letter-frequency software
Date: Thu, 30 Dec 1999 20:17:52 -0800
It's a pleasant discovery indeed to find that there
seem to be some really decent free compilers around.
Thanks to all who replied.
--
r.e.s.
[EMAIL PROTECTED]
--
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: cryptography website(dutch)!
Date: Thu, 30 Dec 1999 23:28:17 -0600
In article 84g9ug$76s$[EMAIL PROTECTED], "Red Shadow"
[EMAIL PROTECTED] wrote:
ya indeed that's right
John Savard [EMAIL PROTECTED] wrote:
It insists you have the Macromedia Flash plug-in installed, it insists
on JavaScript being enabled...
The lesson is that people who are serious about computer security do not
invite trouble. If you want a site to be read by many, make it Mosaic
compatible. Any web snatcher should be able to read it if Mosaic can.
--
Only a little over a year left to go in this centrury
Knowing this, figure that a year from now, we will
resale of the hoopla we are getting ready to see now.
--
From: Sisson [EMAIL PROTECTED]
Subject: The Cipher Challenge from the Code Book
Date: Fri, 31 Dec 1999 07:14:19 GMT
Hello All!
Could someone help me with Stage 3: Monoalphabetic Cipher with
Homophones
my main question is, what does "Monoalphabetic Cipher with Homophones"
mean? is it Homophonic substitution (p52)? if it is, why is the example
of the book numerical, and why when put through frequency analycist Q
has 18.4%?
I have attached (zipped) an excel file that contains all my work so far
Thanks,
Spendabuck
[EMAIL PROTECTED]
ICQ #32207659
--
From: "Chris Williams" [EMAIL PROTECTED]
Subject: Re: The Cipher Challenge from the Code Book
Date: Fri, 31 Dec 1999 18:36:33 +1100
You may wish to visit http://www.onelist.com/community/CipherChallenge for
some hints.
my main question is, what does "Monoalphabetic Cipher with Homophones"
mean? is it Homophonic substitution (p52)? if it is, why is the example
of the book numerical, and why when put through frequency analycist Q
has 18.4%?
It is, just using letters and the asterisk instead of numbers. One cipher
letter is very frequent, perhaps it is not a plain letter at all!
--
From: "Rick Braddam" [EMAIL PROTECTED]
Subject: Re: File format for CipheSaber-2?
Date: Fri, 31 Dec 1999 03:42:31 -0600
Guy Macon [EMAIL PROTECTED] wrote in message
news:84h8bc$[EMAIL PROTECTED]...
Looks like there is no standard file format for ciphersaber-2.
Anyone care to propose one, or would you prefer that the clueless
newbie make a proposal that you can rip to shreds? grin
The attribute of being two way cyphersaber-1 compatable when
repeats=1 is highly desirable. Making the user memorize a repeat
number is undesirable. Revealing the repeat number to attackers
is acceptable.
I hope no one gets upset if a clueless lurker takes a shot. How about
making the repeat value a choice between 1 and the contents of the key
or state table at a fixed index, after the key scheduling? The value
would not have to be transferred between the correspondants as long as
they used the same pass phrase and salt, which they'd have to do anyway,
and the salt must be new for each message. The choice of 1 or the value
would provide compatability with CipherSaber-1.
The value of a particular location in the key table (say, keyTable[10])
should be fairly unpredictable, resulting in an approximately random
repeat count from message to message. The repeat count would not need to
be sent with the message, each user would generate it themselves.
Therefore, no change in the file format from CS-1 (or CS-2).
Yes, I did look at the CipherSaber page and algorithm description. If
I've missed an obvious reason why this would be insecure, just ignore
me.
--
Rick
Spam bait (With credit to E. Needham):
root@l
Cryptography-Digest Digest #815
Cryptography-Digest Digest #815, Volume #9Thu, 1 Jul 99 12:13:05 EDT
Contents:
Re: Quantum Computers (Patrick Juola)
Re: Secure link over Inet if ISP is compromized. (Patrick Juola)
Re: The One-Time Pad Paradox (Patrick Juola)
Re: Quantum Computers (Patrick Juola)
Re: Performance of cryptographic algorithms (David A Molnar)
Re: one time pad (David A Molnar)
Re: Secure link over Inet if ISP is compromized. (Sundial Services)
Re: How do you make RSA symmetrical? (wtshaw)
"Silk to Cyanide" (Neil)
Re: Secure link over Inet if ISP is compromized. (Patrick Juola)
Re: BLT update (long) with (rec) ciphertexts (wtshaw)
Re: A Quanitative Scale for Empirical Length-Strength (wtshaw)
Re: The One-Time Pad Paradox ("Douglas A. Gwyn")
workshop on elliptic curve cryptography (Alfred John Menezes)
Re: BAN Logic considered useful? (Helger Lipmaa)
Re: "Silk to Cyanide" ("Douglas A. Gwyn")
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Quantum Computers
Date: 1 Jul 1999 09:59:50 -0400
In article 7lf4l4$5uo$[EMAIL PROTECTED],
Greg Ofiesh [EMAIL PROTECTED] wrote:
Let us begin with the following assertion that I think you will all
agree with. If a quantum computer exists, then the only form of
encryption that cannot be broken by it, or at least has half a chance
to survive an attack, is OTP. All other forms of encryption are
deterministic in nature and are not "cracked" but simply "translated"
(to convey the ease with which cryptanalysis is performed) by a quantum
computer.
This doesn't follow; contrary to popular belief, quantum computers
are not necessarily -- or even likely to be -- magic boxes that will
perform *any* operations flawlessly and in zero time. Current approaches
(or at least current publically-known approaches) have difficulties
with maintaining the coherence of the quantum states as the problems
get more complex. You may cheerfully believe that the NSA is ahead of
the civilians in this regard -- but I doubt that they can maintain quantum
coherence through an infinite amount of computation. Any "sufficiently
complex" form of encryption would be too complex for the quantum machine
to solve.
Furthermore, quantum machines don't run infinitely fast, either.
Decryption takes time.
Or to put it another way, QM isn't God.
Now let me make my assertion - The US government, most likely the NSA,
has operational quantum computers.
Assert away. They do not, however, have operational quantum computers
with infinite capacity.
Contrary to a point raised earlier, the quantum computer is not used by
the NSA. It is simply left running - translating everything it sees on
the internet into plain text and then passing it off to storage devices.
This is nonsense; the amount of data on the internet would require
computational capacity comparable to the rest of the computers on the
planet to decrypt and store.
God I wish this were not true, but I have strong reasons to believe it
is. My brother was studying how to build a quantum computer at UC
Berkeley in the early to mid 80's and talked with people from around
the country on this subject.
Can anyone provide any additional insight. And please don't say I am
nuts, or kook, or anything else. If that is all you have to say, get a
life or a wife and go somewhere else.
Let me get this straight. Your brother was doing some preliminary
research in this area fifteen years ago, and therefore he knows better
than all the experts on this forum who are current on the technology?
Again, you're not looking for information; you're looking for sock
puppets to confirm your prejudices.
-kitten
--
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Secure link over Inet if ISP is compromized.
Date: 1 Jul 1999 10:08:50 -0400
In article 7lfi2r$38f$[EMAIL PROTECTED],
Gene Sokolov [EMAIL PROTECTED] wrote:
Jim Felling [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Else wrote:
Jim Felling wrote in message [EMAIL PROTECTED]...
That is incorrect. Any internet encryption sceme is as secure as the
parameters allow it to be.
Show please how SSL is secure against man-in-the-middle attack.
If, for example, a trusted certification authority/ trusted public key
collection exists, internet communication is as secure as that
certification
authority/trusted key repository are. (Trusted authority)
How do you access this authority? Whould not it be thorough the ISP?
When I claim a "trusted authority" I am claiming that we somehow have
trust
that this authority is who we think they are, and that the information
that they provide is valid.
Let's get down to practical terms. Here is a situation. FBI suspects someone
who uses 128 bit SSL to deliver his data to a remote location. FBI with a
warrant goes to the s
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 chttp://ww
