Cryptography-Digest Digest #675, Volume #11 Mon, 1 May 00 01:13:01 EDT
Contents:
Re: The Illusion of Security (Diet NSA)
Re: The Illusion of Security (Diet NSA)
Re: Shortcut authenticated Diffie Hellman (David Hopwood)
Re: The Illusion of Security (Diet NSA)
Re: Intel drops serial number (Ornie Kamyl)
Re: Sunday Times 30/4/2000: "MI5 builds new centre to read e-mails on the net"
(Dave J)
Re: Command Line Cypher? (Michael J. Fromberger)
Re: S/MIME + Netscape v47 serious problem in symmetric encryption ... (Travis Farral)
Re: The Illusion of Security (Diet NSA)
Re: S/MIME + Netscape v47 serious problem in symmetric encryption ... (jungle)
Re: Command Line Cypher? (Paul Rubin)
OAPL-3: Observations ([EMAIL PROTECTED])
----------------------------------------------------------------------------
Subject: Re: The Illusion of Security
From: Diet NSA <[EMAIL PROTECTED]>
Date: Sun, 30 Apr 2000 20:10:31 -0700
In article <
e41oOeOr$GA.234@cpmsnbbsa03>, "Joseph
Ashwood" <[EMAIL PROTECTED]>
wrote:
Without a proof of
>randomness, the proof of OTP is invalid, without the proof
>of OTP the security there is no proof of security available.
>If I am wrong, please give a reference.
You might want to read D. Gwyn's reply in
the "Claims/Science Daily" thread and
also why physicists consider certain
quantum phenomena to be "random",
physically speaking.
>
>There are also more instances where quantum computing is
>simply inapplicable, then there are ones where it is
>applicable.
Why is this?
>
>This is not a questioning of you, it is a comment on the
>astounding amount of misinformation that has abounded about
>quantum cryptography.
By whom?
" V hfdt afogx nfvw ufo axb (o)(o) " - Gtnjv
====================================================
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: The Illusion of Security
From: Diet NSA <[EMAIL PROTECTED]>
Date: Sun, 30 Apr 2000 20:23:24 -0700
In article <29839f23.df4b8e06@usw-
ex0105-036.remarq.com>, ritter <
[EMAIL PROTECTED]> wrote:
>1. We cannot trust any cipher. The academic peer-review
>process does not claim to produce unbreakable ciphers.
>The ciphers we get thus have a very real possibility of
>weakness.
>
>2. We cannot know the possibility of cipher weakness,
>because this occurs at the opponent in secrecy. We
>simply do not have evidence to state that a break is
>improbable or infrequent. We are thus forced to assume
>that exposure is likely and common.
>
>3. The more often a cipher is used, the more ciphertext
>is available for analysis, and the greater the value
>of the information protected by that cipher. A
>massively-used cipher is thus the most inviting target.
>
These statements are true for classical
crypto, but not necessarily true for the
quantum case. I am saying this only for
the sake of completeness, and do *not*
mean to fault you because you were not
making any claims about quantum crypto.
" V hfdt afogx nfvw ufo axb (o)(o) " - Gtnjv
====================================================
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Date: Sun, 30 Apr 2000 23:14:59 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Shortcut authenticated Diffie Hellman
=====BEGIN PGP SIGNED MESSAGE=====
lcs Mixmaster Remailer wrote:
> Here is an idea for a shortcut way to do authenticated Diffie Hellman key
> exchange. It might be useful for an application where exponentiations
> are expensive.
>
> In this situation, only the server will authenticate. The client is
> anonymous and so it does not authenticate itself. But the client has
> a public key for the server.
>
> In Diffie Hellman key exchange, the client and server each choose secret
> values k1 and k2 respectively, and then send g^k1 and g^k2. The shared
> secret value is then g^(k1*k2), which each one can calculate but an
> eavesdropper cannot. (All this is mod p.)
It will also work in an arbitrary group in which the Diffie-Hellman Problem
is hard, if p-1 is replaced by the order of g.
> To authenticate, the server needs to sign its part of the exchange. It
> has a secret value x and has published y = g^x as its public key.
>
> In most discrete log based systems the server needs to start off the
> signature calculation by choosing a random k and doing g^k. The proposal
> for this shortcut is to use that same k as the k1 in the Diffie Hellman
> exchange. By doing this the "signature" can be over empty data and
> reduces to an identity protocol.
>
> Using the Schnorr identification protocol, the server sends g^k1.
> The client sends g^k2 for the DH exchange, and also a challenge value c.
> The server responds with r = c*x + k1, mod p-1, which the client verifies
> by g^r =?= y^c * g^k1. This is the standard Schnorr ID protocol.
For robustness, I'd suggest the following:
- include g^k1, g^k2, c and r, as well as g^(k1*k2) in the hash used to
derive session keys,
- add key confirmation (i.e. the client and server check that they
are using the same key),
- g should generate a prime-order subgroup (of size q > 2^180, say,
where r is calculated mod q).
- specify that k1 and k2 are chosen uniformly at random from [1, q-1],
- the client should check that g^k1 is a member of the subgroup
generated by g, and the server should similarly check g^k2.
Alternatively (and more efficiently), it would be sufficient in the
case of GF(p), to ensure that (p-1)/2 has no small factors, and check
that g^k1 and g^k2 are in the range [2, p-2].
Otherwise I can't see anything wrong with the protocol.
(Of course if k1 becomes known then x will be revealed, but that's also
true for DSA signatures, where it is not normally considered a serious
problem.)
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOQyv1jkCAxeYt5gVAQFfnQf6AmUqQR70fWbZ4jK0ZiKLvreg3ZeJndrI
g2YdDjBw+hHN0R/UjQYimGTZbwInxdSxEoeySKtqSL68Oy/44hDunAs9K6bGsOWq
ANA2Yyx03vGBV9ZiUoaxrzTtRsxulFYiPwlF9AsdNvLO/Xsf4fl6wf3XSSloJWwh
sNpcemLoLfiL5KUyH9qywp8KVn81Kc6EjJ/FVU30Bjrbs6RMJ6hL9k5DCDCcA/op
cx884K6dxb8wNWiUMAlZH8KbCDVUpPS5RHHK3fUbSpWW0BHPv6AZiK6fHj7fWyJ2
c2mU/NPUeyD3HI1VSPtsyNxI5ds7MqD+fxYm9+JwQSc4Wx6yfLTL/Q==
=T34i
=====END PGP SIGNATURE=====
------------------------------
Subject: Re: The Illusion of Security
From: Diet NSA <[EMAIL PROTECTED]>
Date: Sun, 30 Apr 2000 20:45:30 -0700
In article <j824e8.1lf.ln@twirl>,
[EMAIL PROTECTED] (Geoff Lane)
wrote:
>Err..., can a non-linear function be composed of a finite
number of linear
>functions? Fourier analysis would imply not.
Fourier methods won't apply to nonlinear
problems because there cannot be any
superposition of solutions. The
requirement for superposition also means
that fourier methods won't apply to linear
systems either, *if* these sytems are not
homogonous. Right now, I can't think of an
(exact) answer to your question but I
wish I knew the answer.
" V hfdt afogx nfvw ufo axb (o)(o) " - Gtnjv
====================================================
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (Ornie Kamyl)
Crossposted-To: talk.politics.crypto
Subject: Re: Intel drops serial number
Date: Mon, 01 May 2000 03:46:43 GMT
[EMAIL PROTECTED] (Vernon Schryver) wrote:
>You are someone who usually seems sane, so please explain what has been
>won.
I'll explain what has been won in simple terms: A monopoly tried to shove
something down the throats of its customers that the customers did not ask
for and do not want. This is something that only a monopoly can accomplish
since (barring collusion), any competitors would quickly steal their share
of the market. Fortunately in this case they gave up. If there were two
manufacturers of microprocessors that had equals shares of the market, then
this processor serial number scheme would never have even been considered.
--
"Ornie Kamyl" is actually 7354 268901 <[EMAIL PROTECTED]>.
01234 56789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: Dave J <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.politics.uk
Subject: Re: Sunday Times 30/4/2000: "MI5 builds new centre to read e-mails on the
net"
Date: Mon, 01 May 2000 04:50:01 +0100
On Sun, 30 Apr 2000 19:20:45 +0100, Therion Ware
<[EMAIL PROTECTED]> wrote:
>First I'd advise you read Phil's bit on PGP and his original
>"unbreakable" code.
>
>I presume what you mean by this is a file that doesn't announce itself
>as an encrypted file.
yes
It's just been pointed out to me that this has already been done.
>
>It seems to me that the first question that would be asked is "why are
>you sending random garbage to other people?" - while this isn't
>uncommon on usenet, at least, a traffic analysis of your sending
>patters may go far enough to establish that you're "probably" sending
>encrypted stuff to other people.
I wasn't really thinking of message encryption. For that as you say you
need steganographic techniques. I was more thinking of private work that
one doesn't want joe plod or any other joe looking at.
>
>If you really want to write a useful program, it would be one that
>encodes the real message in another message - or in a picture -
>probably using a mixture of public key and substitution as its basis.
Joke I hope ;) Even if there was an instant c programing pill I still
wouldn't be able to compete with whats already been done.
>
>the major problem, of course, is that should the boys in blue, or
>indeed gray, find your program on your, or any, computer you would be
>assumed, de facto, to have sent/received encrypted messages.
Yes but did you keep any? If they can't prove the difference between the
straight picture/sound and one with a message inside it..
Fair point though.
As I understand it there is nothing to stop you hiding several mesages
inside the same picture, so how do they know when to stop. You give them
the 'key' and lo theres a message about your next cannabis purchase. Would
the jury then believe there's also a message about world terrorism in the
same file?
I am not so much intested in the relative strengths of encryprtion systems
as in the unjust (not to mention dumb) RIP bill. I assume one or two
groups in the massive crosspost list will contain people who know the
legal system. (Give us a clue as to which ones? :) )
>
>So perhaps the major problem is to hide the program, more than the
>output. Several methods occur, but mostly involving very large
>magnets.
That was the point of my thought, if the existance (or the number) of
messages is genuinely unprovable, does it matter if you have a copy of the
encrytion program? How the !* can the bill work?
Thank you for the reminder on steganography, An application that hides
your work along with as many dummy files/messages as you like. That would
appeal (-;
Dave J.
------------------------------
From: Michael J. Fromberger <[EMAIL PROTECTED]>
Subject: Re: Command Line Cypher?
Date: 1 May 2000 02:56:08 GMT
In <8eieht$550$[EMAIL PROTECTED]> "Jimmy" <[EMAIL PROTECTED]> writes:
>Thanks... the ole XOR encryption... yeah thats pretty secure :)
No! That's not XOR encryption. XOR is totally weak compared to this.
Whereas XOR flips only those bits which correspond to set bits in the
key, this cipher flips ALL the bits of the input! Talk about an
avalanche effect! ;)
-M
(Anj, vg'f arire gbb yngr sbe Ncevy Sbby'f Qnl :)
>Richard Heathfield wrote in message
><[EMAIL PROTECTED]>...
>>Jimmy wrote:
>>>
>>> Anyone know of a decent command line stream cypher for *nix and NT?
>>>
>>
>>Here's one. It's so secure it doesn't need a key. It's called SNA-Coil,
>>and it works on the same principle as DES. What's more, you don't need a
>>separate decryption program. Here's the full source:
>>
>>#include <stdio.h>
>>
>>int main(int argc, char **argv)
>>{
>> FILE *fpin, *fpout;
>> unsigned char ch;
>>
>> if(argc > 2)
>> {
>> fpin = fopen(argv[1], "rb");
>> if(fpin != NULL)
>> {
>> fpout = fopen(argv[2], "wb");
>> if(fpout != NULL)
>> {
>> while(fread(&ch, 1, 1, fpin))
>> {
>> ch = ~ch;
>> fwrite(&ch, 1, 1, fpout);
>> }
>> if(ferror(fpin) || ferror(fpout))
>> {
>> printf("rats.\n");
>> }
>> fclose(fpout);
>> }
>> fclose(fpin);
>> }
>> }
>>
>> return 0;
>>}
>>
>>I defy anyone on this newsgroup to crack SNA-Coil.
>>
>>
>>V ubcr V'z abg gbb yngr sbe Ncevy Sbbyf Qnl <t>
>>
>>--
>>
>>Richard Heathfield
>>
>>"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
>>
>>C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
>>34 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (63
>>to go)
------------------------------
From: Travis Farral <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp.discuss
Subject: Re: S/MIME + Netscape v47 serious problem in symmetric encryption ...
Date: Sun, 30 Apr 2000 22:58:32 -0500
I have seen both of these examples as well using Outlook Express 5.00 w/128 bit
security and a Verisign digital certificate on Windows 2000 Professional. Outlook
2000 appears to perform the same on the same machine with the same certificate. Is
this a problem with Windows and not necessarily with the mail clients? Or is it
simply user error and something isn't set right? I beat my head over this several
weeks ago and finally gave into the fact that whatever encryption method you set it
for isn't necessarily what you will get.
jungle wrote:
> THIS IS VERY SERIOUS BREACH OF SECURITY, BY USING SOMETHING, WHICH I DIDN'T
> APPROVE
>
> S/MIME + Netscape v47 serious problem in symmetric encryption ...
>
> S/MIME v2 Message Spec has 4 rules to step down in symmetric encryption, but
> the rules are for ambiguity only situations ...
>
> tested with win95 + netscape v47 / 128 bits ...
>
> example 1
> ==========
> at creation process of this message [ at test time, here is reporting problem
> only ], I selected explicitly RC2 / 128 bits
> cipher only, I need all of my s/mime encryption to be made with RC2 / 128 bits,
> this is my requirement for testing ...
> but message is reporting RC2 / 40 bits encryption cipher used ...
>
> what is going on at s/mime encryption ?
> it's look to me that all is working against any logic, against any of my
> selections, against my setup ...
>
> example 2
> ==========
> after explicitly excluding all but one cipher [ rc2/128 bits ] for s/mime
> encryption,
> the received message in Netscape is reporting as been encrypted by the
> algorithm DES-EDE3-CBC with 168 bits & not the one that has been selected ...
>
> how this happen ?
> this cipher has been excluded from use at encryption process ...
------------------------------
Subject: Re: The Illusion of Security
From: Diet NSA <[EMAIL PROTECTED]>
Date: Sun, 30 Apr 2000 21:21:43 -0700
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>Mike Kent wrote:
>> ... a comment which I paraphrase as "you may find out that a
>> cipher is weak, but it's impossible ever to know if a cipher
>> is really strong".
>
>One should be careful of making such strong categorical claims.
>In one of Shannon's seminal papers, he already showed how one
>could place a lower bound on the secrecy of a simple system.
>It may well be that the open community hasn't followed up on
>that approach, but that doesn't mean that it couldn't be
>further developed. For example, Kullback's book proves that
>a certain statistic, readily computed in many cases, is the
>best one possible for testing a hypothesis. That can be used
>to establish lower bounds on secrecy of more elaborate systems.
>
This is an excellent point to which I
would add that certain levels of strength
can be guaranteed for some quantum
crypto processes. For instance, in a
particular set-up, there could be a strict
limit to the amount of Shannon info
potentially available to an eavesdropper,
and this is important because of the
concept of unicity distance.
" V hfdt afogx nfvw ufo axb (o)(o) " - Gtnjv
====================================================
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp.discuss
Subject: Re: S/MIME + Netscape v47 serious problem in symmetric encryption ...
Date: Mon, 01 May 2000 00:44:37 -0400
user error [ my error ] ? NO ...
windows error ? the certificate is handled by Netscape & not by win95 ... in my
understanding ...
Travis Farral wrote:
>
> I have seen both of these examples as well using Outlook Express 5.00 w/128 bit
> security and a Verisign digital certificate on Windows 2000 Professional. Outlook
> 2000 appears to perform the same on the same machine with the same certificate. Is
> this a problem with Windows and not necessarily with the mail clients? Or is it
> simply user error and something isn't set right? I beat my head over this several
> weeks ago and finally gave into the fact that whatever encryption method you set it
> for isn't necessarily what you will get.
>
> jungle wrote:
>
> > THIS IS VERY SERIOUS BREACH OF SECURITY, BY USING SOMETHING, WHICH I DIDN'T
> > APPROVE
> >
> > S/MIME + Netscape v47 serious problem in symmetric encryption ...
> >
> > S/MIME v2 Message Spec has 4 rules to step down in symmetric encryption, but
> > the rules are for ambiguity only situations ...
> >
> > tested with win95 + netscape v47 / 128 bits ...
> >
> > example 1
> > ==========
> > at creation process of this message [ at test time, here is reporting problem
> > only ], I selected explicitly RC2 / 128 bits
> > cipher only, I need all of my s/mime encryption to be made with RC2 / 128 bits,
> > this is my requirement for testing ...
> > but message is reporting RC2 / 40 bits encryption cipher used ...
> >
> > what is going on at s/mime encryption ?
> > it's look to me that all is working against any logic, against any of my
> > selections, against my setup ...
> >
> > example 2
> > ==========
> > after explicitly excluding all but one cipher [ rc2/128 bits ] for s/mime
> > encryption,
> > the received message in Netscape is reporting as been encrypted by the
> > algorithm DES-EDE3-CBC with 168 bits & not the one that has been selected ...
> >
> > how this happen ?
> > this cipher has been excluded from use at encryption process ...
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Command Line Cypher?
Date: 1 May 2000 04:53:45 GMT
In article <8ei906$868$[EMAIL PROTECTED]>,
Jimmy <[EMAIL PROTECTED]> wrote:
>Anyone know of a decent command line stream cypher for *nix and NT?
>
>JImmy
Yes, send an email address and I'll send you source for one.
------------------------------
From: [EMAIL PROTECTED]
Subject: OAPL-3: Observations
Date: Mon, 01 May 2000 04:51:12 GMT
After reading (not really, sifting through the flames) the threads that
have been going on here about the product, I decided to have a look at
the product/algorithm/help files, and downloaded the software. I
started the OARL-3 program, and completely got lost on the first try.
The error messages "E00121" or some such was not really helpful. I
admit, I never read the help files on how to use the program, but hey!
who does these days. A couple of minutes spending experimenting with
the menu items is enough for most programs to learn how to use them. If
it will be a good comparison, on my first install of PGP, it took me
about five minutes to learn how to generate my key, register it to one
of the servers, and encrypt/sign messages. All without reading a single
document.
To make a long story short, the OARL-3 program gets a huge minus for
usability.
The second thing to look at was the help files for the algorithms. I
think I understood most of the operations Mr. Szopa is performing to
get his random bytes. My first impression? It is quite ruthless both on
memory, and hard drive (if al those files are really kept there, that
is). A couple of hints to Mr Szopa:
Since you are storing permutations, you only need 8 digits, plus a
single bit per row. 8 digits for the first 8 numbers, and a single bit
to determine whether the smaller number comes first, or not (e.g.
0356874129 can be represented as 03568741/0, and 0356874192 can be
represented as 03568741/1). It will save about 3 Megabytes per mixfile
(if I get the terminology correct).
Anyway, after reding Mr Taneli Huuskonen's attack on the random digit
generator, I wanted to have a look at the digit generator to understand
the properties of it. First observation:
- When the full permutation set (all 10! of them) is used as Mixfiles
1/2/3 (or Set1/2/3), the random digit generator is not biased at all. I
am not sure whether biases are introduced after this stage, but this
stage is perfectly balanced. Every digit will occur exactly 10!*9!
times. If anyone is interested, I can explain why.
Then I noticed the weakness of the algorithm. After about 30*10! of the
digits are generated (and known), almost all future digits (for the
current set1/set2/set3 combination, there are 10!^2 of them) can be
predicted. I verified this observation with 4 digit permutations, in
which I needed about 9*4! digits to get the full 4!^2 digits. Anyway, I
am not going to describe the attack here. I will merely note the lack
of analysis that went into the random digit generation. After the first
10! digits are generated, Set1 is rotated one position up. The choice
of Set 1 was apparently arbitrary, because that is the worst possible
of all three sets. Set 2 would be slightly stronger (but still an
attack exists), and set 3 would be the strongest of all (against the
attack I have, there may be other attacks). Since I am not being paid
by Mr. Szopa, I will let him find and patch the weakness on his own (of
course he can take what I say on face value, and change the rotated set
to set 3, but there is always a possibility that I am lying to make him
choose a weaker algorithm).
I am not a cryptanalyst. The fact that it took me only a couple of
hours to find a weakness (which may or may not be exploited to break
the system) suggests that the algorithm is not strong enough to resist
attacks against people who know what they are doing. The following
processes may be able to hide this weakness sufficiently, but someone
must prove to me (rigorously, not with hand waving, and saying that it
is not possible to get at these digits) that they will.
Yeps, this was my two cents' worth of observations. Flame away at
will. :-)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
