Cryptography-Digest Digest #558
Cryptography-Digest Digest #558, Volume #11 Sun, 16 Apr 00 15:13:01 EDT Contents: Re: Why is this algorithm insecure? (Newbie flamefodder) (stanislav shalunov) Re: My STRONG data encryption algorithm (stanislav shalunov) Re: ? Backdoor in Microsoft web server ? [correction] (Francois Grieu) Why encrypt email... ([EMAIL PROTECTED]) Re: Open Public Key (Tom St Denis) Re: ? Backdoor in Microsoft web server ? [correction] (Jim Gillogly) Re: Why is this algorithm insecure? (Newbie flamefodder) (Boris Kazak) Re: Open Public Key (Mark Wooding) Re: GOST idea (Mok-Kong Shen) Re: General principles of design (Mok-Kong Shen) Re: AND on encrypted data (Mok-Kong Shen) Subject: Re: Why is this algorithm insecure? (Newbie flamefodder) From: stanislav shalunov [EMAIL PROTECTED] Date: Sun, 16 Apr 2000 17:12:45 GMT Richard Heathfield [EMAIL PROTECTED] writes: Thank you. I'm not sure, however, that I have understood you correctly. You seem to be saying that Eve can decrypt any message she likes, provided she has first done a chosen plaintext attack on a message that length and using the same key as Alice. Okay, yes, that's a problem. But how would she do such an attack? I was a bit careless: known plaintext is enough. What I have meant is that if Alice sends to Bob a stream of messages of the same length encrypted with the same key (e.g., network packets), and if Eve knows plaintext of one of the packets, Eve immediately can decrypt all the other packets. (Eve could guess the first packet, which might be part of a higher-level protocol or make Alice send some chosen plaintext). More than that, Eve can simply XOR any two packets and get rid of key material completely. If data has enough redundancy (e.g., is natural language text) both packets can be recovered. All further and previous packets of the same length with the same key are compromised. If a key can never be reused the cryptosystem is useless. (One could simply use OTP then.) Also, you seem to be mentioning overly long keys (4K, etc.) all the time. If symmetric cryptosystem needs such long keys you know it's worthless. A secure algorithm doesn't need keys longer than 128 bits. The task of brute-forcing 2^128 different keys is out of reach for any known adversary. For extra safety sometimes one might want even longer key, such as 256 bits, but keys longer than that in a symmetric system are a sure sign that the designer didn't understand what he's doing. -- stanislav shalunov | Speaking only for myself. My address in From: is correct; if yours isn't, I don't want to hear from you. Try to reply in newsgroup. I don't need courtesy copies. -- Subject: Re: My STRONG data encryption algorithm From: stanislav shalunov [EMAIL PROTECTED] Date: Sun, 16 Apr 2000 17:19:18 GMT No, it's not strong. If you wish to receive further comments, post a short pseudo-code (or English) description of the algorithm. -- stanislav shalunov | Speaking only for myself. My address in From: is correct; if yours isn't, I don't want to hear from you. Try to reply in newsgroup. I don't need courtesy copies. -- From: Francois Grieu [EMAIL PROTECTED] Subject: Re: ? Backdoor in Microsoft web server ? [correction] Date: Sun, 16 Apr 2000 19:53:57 +0200 I'm glad I started the thread with a disclaimer. The text "Nescape engineers are weenies!" is indeed embedded [reversed] in the file dvwssr.dll coming with some Microsoft web server software for Windows 95/98 and NT 4 [not Windows 2000], and reportedly in file mtd2lv.dll coming with some corresponding web authoring tool. But contrary to some early press reports, evidence is this string is NOT a universal password, nor part of such a deliberate mechanism. My analysis of Microsoft's statements is - this string is "an obfuscation key to obscure the names of files being requested by the client from the server" while gathering information used to draw a site map. - knowledge of this algorithm and key only "allows a user who has privileges on a web server to read certain files from other web sites hosted on the same computer", and therefore the vulnerability only affects "customers who host more than one web site on a server". Still, it looks like Microsoft has distributed a product [reportedly acquired from another company] relying deliberately on obscurity for some of it's security features, a bad professional practice. Microsoft statements on dvwssr.dll issues are at http://www.microsoft.com/technet/security/bulletin/ms00-025.asp and http://www.microsoft.com/technet/security/bulletin/fq00-025.asp Understandably, the focus is on another vulnerability: a subsequently discovered potential for a buffer overrun, which can lead to a denial of service attack, or conceivably [IMHO assuming the attacker
Cryptography-Digest Digest #560
Cryptography-Digest Digest #560, Volume #11 Sun, 16 Apr 00 21:13:01 EDT
Contents:
Re: Why is this algorithm insecure? (Newbie flamefodder) (stanislav shalunov)
Re: GOST idea (Tom St Denis)
Re: Why encrypt email... (Jerry Park)
Re: Encrypt the signature? ("Scott Fluhrer")
Re: One Time Pads Redux ("Joseph Ashwood")
Re: Why is this algorithm insecure? (Newbie flamefodder) (NFN NMI L.)
Re: Why is this algorithm insecure? (Newbie flamefodder) (David Hopwood)
Re: Observer 16/4/2000: "Jack Straw wants the keys to your office. Don't let him in
..." ("PJS")
Re: Why encrypt email... ("Joseph Ashwood")
Re: new Echelon article ([EMAIL PROTECTED])
Re: Encode Book? (greenjh)
Re: One Time Pads Redux ("Trevor L. Jackson, III")
Re: My STRONG data encryption algorithm ("Trevor L. Jackson, III")
Re: My STRONG data encryption algorithm (Tom St Denis)
Re: Why is this algorithm insecure? (Newbie flamefodder) ("Trevor L. Jackson, III")
Re: Why encrypt email... (Guy Macon)
Subject: Re: Why is this algorithm insecure? (Newbie flamefodder)
From: stanislav shalunov [EMAIL PROTECTED]
Date: Sun, 16 Apr 2000 22:38:12 GMT
Richard Heathfield [EMAIL PROTECTED] writes:
or make Alice send some chosen plaintext).
Skulduggery? Surely not! :-)
Many protocols would echo whatever Bob sends (or pieces of it).
Mallory could pretent to be Bob in the end of the transaction and
decrypt everything that happened before.
That's worrying. I'll try to crack it on that basis to see if you're
correct.
If I understood your description correctly, if you encrypt two
messages of the same length with the same key, XOR or the two
ciphertexts is the same as XOR of plaintexts. That reveals way too
much information about plaintexts.
The task of brute-forcing 2^128 different keys is out of reach for any
known adversary.
But wasn't it done recently?
No. If I am not mistaken, the largest publicly known brute-force
attacks are against 56-bit keys. It's probably true that 64-bit keys
can be brute-forced today by well-equipped adversaries (governments of
large countries or many co-operating users on the Internet).
But 2^128 is well out of reach by today's standards. Computing based
on new physical principles would be required to brute-force that.
You might be confusing this with something like RSA-512 challenge.
RSA isn't a symmetric cryptosystem.
Is it worth persevering with this algorithm, but adding partial
rotations and partial XORing, as another poster suggested?
For fun and to learn--sure. But even for fun you could try different
(more traditional) designs, such as a block cipher based on Feistel
networks. It'll usually be faster, won't require loading of the
complete plaintext into memory, and will possibly be more secure.
Feistel networks are described in _Applied Cryptography_ by Bruce
Schneier, 2nd edition (a must-have first book for anyone plaining with
inventing or implementing cryptosystems). They've been described in
this newsgroup before numerous times.
--
stanislav shalunov | Speaking only for myself.
My address in From: is correct; if yours isn't, I don't want to hear from you.
Try to reply in newsgroup. I don't need courtesy copies.
--
From: Tom St Denis [EMAIL PROTECTED]
Subject: Re: GOST idea
Date: Sun, 16 Apr 2000 22:39:34 GMT
Tom St Denis wrote:
Mok-Kong Shen wrote:
Tom St Denis wrote:
Well my idea cannot technically be any worse then before since F(x) 2x^2
+ x is a permutation in GF(2^w). Another balanced approach would be
todo this
Could you explain why a permutation doesn't affect the avalanche?
Thanks.
No the permutation cannot hinder the avalanche. It in fact increases
the avalanche.
That's too vague, sorry. It can't hinder it in this case since the S
function is simply a permutation itself. And since the quadratic
used is a permutation it has no bias towards any particular value. It's
like doing
F(x) = S(x + c), For any constant 'c'. You are just changing the order
of the outputs, not the properties of S() itself.
Tom
--
From: Jerry Park [EMAIL PROTECTED]
Subject: Re: Why encrypt email...
Date: Sun, 16 Apr 2000 17:48:33 -0500
David Crick wrote:
[EMAIL PROTECTED] wrote:
Hi, I am doing a paper on email encryption and I have two theories:
1) The level of encryption depends on the information being encrypted.
Only in military and government systems.
Much email is non-sensitive info so encryption is not used.
There is no reason why you should not encrypt everything.
(The speed issue with modern hardware and ciphers no longer
is an issue. There are also enough free and tested algorithms
so that patent issues, etc. are not an issue.)
At other times, like for medical records, email is encrypted to
protect confidential info.
This is one case
