Cryptography-Digest Digest #976, Volume #8 Wed, 27 Jan 99 02:13:04 EST
Contents:
Re: Crack in Export Laws?? (Namesti)
Re: Metaphysics Of Randomness (R. Knauer)
Re: Random numbers from a sound card? (R. Knauer)
Re: Random numbers from a sound card? (R. Knauer)
Re: Random numbers generator and Pentium III (R. Knauer)
[question]help me! (Park Jung-Jun)
Re: My comments on Intel's Processor ID Number ("Trevor Jackson, III")
Brute Forcing DSS To Uncover The DH key ("John Doe")
Re: Inforamtionpool sas&chiffrier
Re: Unicity, DES Unicity and Open-Keys ([EMAIL PROTECTED])
Re: Foiling 56-bit export limitations: example with 70-bit DES
([EMAIL PROTECTED])
Re: The Performance of Meet-in-the-Middle (David Wagner)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Namesti)
Subject: Re: Crack in Export Laws??
Date: 27 Jan 1999 01:29:56 GMT
>The big server vendors are M$ and Netscape and Verisign offers SGC
>certificates for both of them. If you want to use any other brand of
>server, you're out of luck, for now.
This isn't true. Check out http:/www.verisign.com/globalserver/Msglobal.html.
You can get them for other servers as well, including Hewlett Packard Virtual
Vault; Lotus Domino 4.6.2+; Nanoteq Servers; and the Compaq/Tandem iTP
WebServer.
Or do I need to be corrected? I also heard that Apache servers now support SGC
can't find documentation on it.
Cheers,
Sinclair
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Metaphysics Of Randomness
Date: Wed, 27 Jan 1999 01:30:20 GMT
Reply-To: [EMAIL PROTECTED]
On 26 Jan 1999 19:07:21 -0500, aland@!spam.striker.ottawa.on.ca (Alan
DeKok) wrote:
> I want random numbers to be so secure that even *I* won't be able to
>predict their behaviour once my application reaches a customers site;
>even knowing the algorithm and guessing all initial conditions.
If your PRNG is seeded, there will only be 2^K possible outputs, which
is far short of the 2^N ciphers possible from a message of length N.
The only way to get true security is to generate one of 2^N possible
keys. But that requires a seed that is N in length - so why not just
use it instead of the PRNG output?
Bob Knauer
"An honest man can feel no pleasure in the exercise of power over
his fellow citizens."
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Random numbers from a sound card?
Date: Wed, 27 Jan 1999 01:33:31 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 26 Jan 1999 20:47:01 GMT, [EMAIL PROTECTED] wrote:
>Computers that can roll dice are not Turing machines.
You got a computer that can roll dice - a completetly
non-deterministic machine that can compute algorithmically?
Bob Knauer
"An honest man can feel no pleasure in the exercise of power over
his fellow citizens."
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Random numbers from a sound card?
Date: Wed, 27 Jan 1999 01:34:38 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 26 Jan 1999 22:20:11 GMT, [EMAIL PROTECTED] (Paul Rubin) wrote:
>Run the audio bits through a cryptographic
>hash function or something similar before using it.
Any recommendations on which hash function or something similar?
Bob Knauer
"An honest man can feel no pleasure in the exercise of power over
his fellow citizens."
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Random numbers generator and Pentium III
Date: Tue, 26 Jan 1999 19:51:07 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 26 Jan 1999 12:36:23 -0600, Medical Electronics Lab
<[EMAIL PROTECTED]> wrote:
>> 2. How can we know, that RNG embedden in Pentium III is really random ?
>> Are there any methods to detect any subtle pattern in data from the RNG,
>> if there are any (if there are any methods, please describe them)? It is
>> possible to design "Random" Numbers Generator with such a pattern, give
>> it to people, and in this way we have a something like key-escow
>> ciphers.
>Yes, there are many methods. Check out Marsaglia's DIEHARD and pLab's
>Diaphony for the most advanced stuff. Simple autocorrelation and
>ballance of 1's and 0's will also give you a few clues. If it can
>pass all those tests, it's mathematically random.
I give up. If people want to believe that crypto-grade randomness can
be characterized by statistical tests, let them.
>I don't think
>anyone knows what "really random" is tho.
<jeez>
Bob Knauer
"An honest man can feel no pleasure in the exercise of power over
his fellow citizens."
--Thomas Jefferson
------------------------------
From: Park Jung-Jun <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: [question]help me!
Date: Wed, 27 Jan 1999 13:00:16 +0900
==============0E80CF37C714C8F211A1F443
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hello!
help me. please ..
How to ABA-JCE using ?
I want SSL communication.
thanks.
==========================================
/* SSL Client */
//package org.vonnieda.security.ssl.test;
import java.io.*;
import java.security.*;
import java.security.cert.X509Certificate;
import javax.crypto.Cipher;
import org.vonnieda.security.ssl.*;
/**
* Simple SSL client test. Connects to the host given on the command line
* using https and spits out what it gets back from a GET /
*/
public class SSLClient
{
public static void main(String[] args) throws Exception
{
// change this line to reflect the security provider you are using
SSLSocket.setDefaultSecurityProvider(new
org.vonnieda.security.ssl.provider.ABA_SSLSecurityProvider());
// end of changes
if (args.length < 2) {
System.out.println("USAGE: SSLClient <hostname> <port>");
System.exit(0);
}
SSLSocket s = new SSLSocket(args[0], Integer.parseInt(args[1]));
SSLContext context = s.getContext();
// defaults to System.out, only here to show people that it exists.
// set it to a FileOutputStream for a log file!
context.setDebugStream(System.out);
context.setDebugOption("all", false);
context.setDebugOption("general", true);
context.setDebugOption("handshakehashes", true);
context.setDebugOption("keyinfo", true);
context.setDebugOption("recordsent", true);
context.setDebugOption("recordreceived", true);
context.setDebugOption("peercertificate", true);
context.setDebugOption("sendrecordbytes", false);
context.setDebugOption("receiverecordbytes", false);
OutputStream out = s.getOutputStream();
InputStream in = s.getInputStream();
out.write("GET /\n\n".getBytes());
byte[] b = new byte[1024];
int d;
while ((d = in.read(b)) != -1) {
// uncomment this to see what the web server returns
//System.out.print(new String(b, 0, d));
}
System.exit(0);
}
}
/* SSL Server */
//package org.vonnieda.security.ssl.test;
import java.io.*;
import java.net.*;
import java.security.*;
import java.security.cert.X509Certificate;
import javax.crypto.Cipher;
import org.vonnieda.security.ssl.*;
public class SSLServer
{
public static void main(String[] args) throws Exception
{
SSLSocket.setDefaultSecurityProvider(new
org.vonnieda.security.ssl.provider.ABA_SSLSecurityProvider());
SSLServerSocket ss = new SSLServerSocket(Integer.parseInt(args[0]));
SSLSocket s = (SSLSocket) ss.accept();
SSLContext context = s.getContext();
context.setDebugOption("all", false);
context.setDebugOption("general", true);
context.setDebugOption("handshakehashes", false);
context.setDebugOption("keyinfo", false);
context.setDebugOption("recordsent", true);
context.setDebugOption("recordreceived", true);
context.setDebugOption("peercertificate", false);
context.setDebugOption("sendrecordbytes", false);
context.setDebugOption("receiverecordbytes", false);
OutputStream out = s.getOutputStream();
InputStream in = s.getInputStream();
out.write("GET /\n\n".getBytes());
byte[] b = new byte[1024];
int d;
while ((d = in.read(b)) != -1) {
System.out.print(new String(b, 0, d));
}
System.exit(0);
}
}
--
====================================================
JUNG-JUN, PARK
URL : http://www.securesoft.co.kr
homepage : http://www.cgii.co.kr/~rambo
E-mail : [EMAIL PROTECTED]
[EMAIL PROTECTED]
Phone : 82-2-564-4011(174)
FAX : 82-2-565-2014
pager : 012-1107-0823
Technology R&D Center/Engineer
SecureSoft Incorporated.
====================================================
==============0E80CF37C714C8F211A1F443
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
Hello!
<BR>help me. please ..
<BR>How to ABA-JCE using ?
<BR>I want SSL communication.
<BR>thanks.
<BR>==========================================
<P>/* SSL Client */
<BR>//package org.vonnieda.security.ssl.test;
<P>import java.io.*;
<BR>import java.security.*;
<BR>import java.security.cert.X509Certificate;
<BR>import javax.crypto.Cipher;
<BR>import org.vonnieda.security.ssl.*;
<P>/**
<BR>* Simple SSL client test. Connects to the host given on the command
line
<BR>* using https and spits out what it gets back from a GET /
<BR>*/
<BR>public class SSLClient
<BR>{
<BR> public static void main(String[] args) throws Exception
<BR> {
<BR> <FONT COLOR="#FF0000"> // change this line to reflect
the security provider you are using</FONT>
<BR><FONT COLOR="#FF0000"> SSLSocket.setDefaultSecurityProvider(new
org.vonnieda.security.ssl.provider.ABA_SSLSecurityProvider());</FONT>
<BR><FONT COLOR="#FF0000"> // end of changes</FONT>
<P> if (args.length < 2) {
<BR> System.out.println("USAGE: SSLClient
<hostname> <port>");
<BR> System.exit(0);
<BR> }
<BR> SSLSocket s = new SSLSocket(args[0], Integer.parseInt(args[1]));
<P> SSLContext context = s.getContext();
<P> // defaults to System.out, only here to show people
that it exists.
<BR> // set it to a FileOutputStream for a log file!
<BR> context.setDebugStream(System.out);
<P> context.setDebugOption("all", false);
<BR> context.setDebugOption("general", true);
<BR> context.setDebugOption("handshakehashes", true);
<BR> context.setDebugOption("keyinfo", true);
<BR> context.setDebugOption("recordsent", true);
<BR> context.setDebugOption("recordreceived", true);
<BR> context.setDebugOption("peercertificate", true);
<BR> context.setDebugOption("sendrecordbytes", false);
<BR> context.setDebugOption("receiverecordbytes", false);
<P> OutputStream out = s.getOutputStream();
<BR> InputStream in = s.getInputStream();
<BR> out.write("GET /\n\n".getBytes());
<BR> byte[] b = new byte[1024];
<BR> int d;
<BR> while ((d = in.read(b)) != -1) {
<BR> // uncomment this to see what the web
server returns
<BR> //System.out.print(new String(b, 0,
d));
<BR> }
<BR> System.exit(0);
<BR> }
<P>}
<P>/* SSL Server */
<BR>//package org.vonnieda.security.ssl.test;
<P>import java.io.*;
<BR>import java.net.*;
<BR>import java.security.*;
<BR>import java.security.cert.X509Certificate;
<BR>import javax.crypto.Cipher;
<BR>import org.vonnieda.security.ssl.*;
<P>public class SSLServer
<BR>{
<BR> public static void main(String[] args) throws Exception
<BR> {
<BR> <FONT COLOR="#FF0000">SSLSocket.setDefaultSecurityProvider(new
org.vonnieda.security.ssl.provider.ABA_SSLSecurityProvider());</FONT>
<P> SSLServerSocket ss = new
SSLServerSocket(Integer.parseInt(args[0]));
<P> SSLSocket s = (SSLSocket) ss.accept();
<P> SSLContext context = s.getContext();
<P> context.setDebugOption("all", false);
<BR> context.setDebugOption("general", true);
<BR> context.setDebugOption("handshakehashes", false);
<BR> context.setDebugOption("keyinfo", false);
<BR> context.setDebugOption("recordsent", true);
<BR> context.setDebugOption("recordreceived", true);
<BR> context.setDebugOption("peercertificate", false);
<BR> context.setDebugOption("sendrecordbytes", false);
<BR> context.setDebugOption("receiverecordbytes", false);
<P> OutputStream out = s.getOutputStream();
<BR> InputStream in = s.getInputStream();
<BR> out.write("GET /\n\n".getBytes());
<BR> byte[] b = new byte[1024];
<BR> int d;
<BR> while ((d = in.read(b)) != -1) {
<BR> System.out.print(new String(b, 0, d));
<BR> }
<BR> System.exit(0);
<BR> }
<P>}
<BR>--
<BR>----------------------------------------------------
<BR> JUNG-JUN, PARK
<BR> URL : <A
HREF="http://www.securesoft.co.kr">http://www.securesoft.co.kr</A>
<BR> homepage : <A
HREF="http://www.cgii.co.kr/~rambo">http://www.cgii.co.kr/~rambo</A>
<BR> E-mail : [EMAIL PROTECTED]
<BR> [EMAIL PROTECTED]
<BR> Phone : 82-2-564-4011(174)
<BR> FAX : 82-2-565-2014
<BR> pager : 012-1107-0823
<BR> Technology R&D Center/Engineer
<BR> SecureSoft Incorporated.
<BR>----------------------------------------------------
<BR> </HTML>
==============0E80CF37C714C8F211A1F443==
------------------------------
Date: Tue, 26 Jan 1999 23:12:34 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: My comments on Intel's Processor ID Number
Bruce Schneier wrote:
> I wrote a column on Intel's Processor ID number for ZDNet. You can
> read it at:
>
> http://www.zdnet.com/zdnn/stories/comment/0,5859,2194863,00.html
You didn't address the concept of software copy protection. While there
will be hackers able to spoof app-level software's access to the CPU
Serial #, there will be software vendors who will not be hackable and
software vendors who will be hackable, but will still want the capability.
The former class includes system software vendors such as Microsoft. It
also includes vendors of packages in the $100K and up range.
The latter class includes vendors of widely copied software such as
games. A technique does not have to be perfect or even very strong to be
useful in reducing piracy. Further, system software vendors may be able
to create secure APIs that make it easier to get the serial number with
high confidence. They would do so in the interest of attracting vendors
from the latter class to use their platform.
I agree that most of what Intel claimed was garbage, and most of what they
denied was probably their true purpose. But there's no direct harm to
vendors or consumers in having the facility present except that it builds
a false sense of security. We should be able to show that that sense of
security is false without claiming that the feature is valueless.
------------------------------
From: "John Doe" <[EMAIL PROTECTED]>
Subject: Brute Forcing DSS To Uncover The DH key
Date: Wed, 27 Jan 1999 04:29:10 GMT
Would it be possible to brute force the DSS in PGP to uncover the
information to brak the security of the DH key?
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Inforamtionpool sas&chiffrier
Date: 27 Jan 99 04:26:44 GMT
John Savard ([EMAIL PROTECTED]) wrote, in part:
: This is done by converting the 5-unit code to a 12-bit code, XORing in
: the paper tape, and then converting the 12-bit result back down to 5
: bits.
: The diagram shows the 12-bit XOR all taking place at one time, which
: places a severe restriction on what can be done, but no doubt there
: are possible arrangements even so, although what I can think of seems
: to be very limited.
Even after some thought, I can't come up with anything better than this:
divide the five bits of the character into two groups, one with two bits,
and one with three bits.
Keep invariant the XOR of all the bits in each group.
Thus, the 12 bits going into the XOR will consist of the five bits of the
character, and seven other bits, each of which is equal to either the XOR
of the two bits in one group, the XOR of the three bits in the other
group, or all five bits in the character.
The five bits of the character, after XOR, are then modified by the seven
other bits only in ways that maintain the invariants: swapping two bits
within the same group, or inverting two bits within the same group.
Even this seems to require a connection across the XOR for decipherment,
although it certainly is invertible. And it does nothing to prevent an
attack by a kappa test - and it is unnecessary if the tapes are used as
true one-time tapes.
However, the diagram shows a diode matrix as a separate component: if a
plugboard is available to change the 5-unit coding of characters for each
message or once a day, that would help, and is likely to be the case - at
least on the plaintext side of this encipherment method. On both sides
would be better, of course.
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Unicity, DES Unicity and Open-Keys
Date: Wed, 27 Jan 1999 04:27:51 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
>
> > Unicity, DES Unicity and Open-Keys
> >
> > Archived at http://www.mcg.org.br/unicity.htm
>
> I have a tiny question. You say that 'magic numbers' or 'information
> tags' enable the analyst to identify the compression algorithm.
> Could one suppress that, i.e. let it be part of the secret information
> of the communication partners? One could also vary the algorithm
> setup (the Huffman table, etc.) depending on some (time-varying)
> value not known to the analyst, I suppose.
>
This will be exemplified in the new version of "Some Non-Random DES
Characteristics and an Identification Attack on DES" which will be at
http://www.mcg.org.b/nrdes.htm (it was discussed here in the nrdes.txt
version).
However, the relevant section (which IMO answers your question in the
negative) is:
For special protocols, in high-security applications, the "magic numbers" can
also be implicit or encoded with a random seed in each use. However, the
encoded data itself may betray its presence by its very structure, size,
range, randomness, redundancy, etc. This is a problem in identification and,
as given in [Ger98], "to identify is to look for connections" -- not just to
look for an identity connection with a set of "magic numbers". For further
discussion on this topic and a practical example please see [Ger99], Section
4.
> More generally: It is commonly assumed that the analyst knows the
> encryption scheme one uses. But this is reasonable if one repeatedly
> uses the same scheme. If one has a fairly large set of schemes to be
> chosen according to a secret schedule, then the analyst has first of
> all to figure out the scheme actually being used, i.e. he has a much
> higher work load. I believe all this could be subsumed under the
> paradigm 'Security through variability', which underlies, in
> particular, those algorithms that are parameter-dependent (analogous
> to parametrized data types in programming languages; the parameters
> can be regarded as kind of 'key extensions' which is of interest
> in the context of the Wassenaar regulation).
>
This is answered in a part of the new text in the paper announced in this
thread ;-)
To highlight it, I posted just this part (which, as you point out, offers
useful variability) in order to explain how one can rather easily foil WA with
"open trust" and/or with "open ignorance".
Cheers,
Ed Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Foiling 56-bit export limitations: example with 70-bit DES
Date: Wed, 27 Jan 1999 04:36:59 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
>
> > Consider a hypothetical 14-DES Standard, which would specify (for
> > example) 2^14 pre-defined and publicly known 64-bit random blocks.
> > Now, Bob would choose one at will and use his choice to XOR-encode
> > all 64-bit DES blocks calculated with the 56-bit secret-key he shares
> > with Alice -- without disclosing his choice (i.e., anyone else would
> > ignore the choice). An attacker would have a workload (2^14)/2 =
> > 8,192 times higher on average for all 56-bit key combinations to be
> > tried -- which would effectively raise the DES key-length from 56 to
> > 70 bits. But the intended recipient Alice, who knows the 56-bit
> > secret-key, would just have to try out an average of 8,192 DES
> > decryptions of one 8-byte block in order to find out which seed was
> > chosen -- a small initial overhead.
>
> I am not clear of your term '14-DES'. Do you mean 14 DES modules
> put in series in the same manner as '3-DES'? But then what are
> the '2^14 predefined ....blocks'? Perhaps the terminology is a
> bit in trouble.
>
Yes. The term 14-DES may be misleading and was better explained -- it is just
one DES but with 2^14 pre-defined blocks of 64-bits that the sender must use
in order to select *one* 64-bit block, the unknown-key (ie, unknown to anyone
else except the sender -- even the receiver ignores it).
Please visit the full paper at http://www.mcg.org.br/unicity.htm
This specific section was also changed, to make it easier to understand. The
new relevant part is:
Consider a hypothetical M-DES Standard (hereafter, M-DES) which would specify
a total of 2M pre-defined and publicly known 64-bit different blocks of data,
for various choices of M = 0, 1, ... Now, when Bob wants to send a message to
Alice, he needs to negotiate a M-DES cipher with Alice, which includes a
56-bit secret-key [Note-1] and a publicly defined value for M, say M = 14.
The value of M is chosen by Bob according to his security needs [Note-2], and
accepted (or not) by Alice. To use M-DES, Bob would privately choose one
64-bit "key" at will (from the public list of 2^14 "keys") and then
repeatedly use this choice to XOR-encode one by one each of all 64-bit DES
ciphertext blocks which are calculated with the 56-bit secret-key he shares
with Alice -- without disclosing his choice (i.e., anyone else would ignore
the choice). Thus, Bob's choice is an "unknown key" to anyone else, including
Alice -- providing open ignorance.
Cheers,
Ed Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: The Performance of Meet-in-the-Middle
Date: 26 Jan 1999 21:26:35 -0800
Oh, now I get it!
Thank you for taking the time to elaborate (really, to dumb it down into
a language I can follow).
It is a nice example of how meet-in-the-middle attacks can exhibit
surprising behavior in pathological cases.
Let me try to summarize what we've both been saying. You are talking
about worst-case complexity (for a deterministic adversary), and I am
talking about average-case complexity (for a randomized adversary).
You show that for any fixed plaintext-ciphertext pair p,c, there is a
pair of ciphers X,Y such that a MITM attack on XY using just p,c takes a
long time.
I am saying that for any pair of ciphers X,Y, most plaintext-ciphertext
pairs allow the MITM attack to run efficiently (unless the cipher XY has
other weaknesses which make a MITM attack irrelevant; and assuming you
allow the adversary access to more than one known plaintext-ciphertext
pair). Moreover, the probability that the MITM attack runs slowly is
exponentially small.
Note the difference in the order of the universal and existential
quantifiers. (Oooh... that has a nice ring to it, doesn't it?)
Up to this point it's just a been series of technical claims and proofs.
But now we get to the subjective part.
The subjective bit is that I feel these "counterexamples" and proofs
indicate that your definition of MITM attack may be too strict. You
require a MITM attack to use just one pair, and to have good worst-case
complexity. I suggest that you should allow for adversaries which have
good average-case complexity (but possibly terrible worst-case
complexity); the existence of such adversaries would normally be
considered problematic in practice.
This is just a question of which definitions best capture the ideas we
are trying to study, so it is subjective, but I think it is also one of
the most important endeavours of theoretical work.
Thanks again for the "counterexample". I think it helps to elucidate
some of the tricky issues in formulating a formal model for MITM
attacks; and it is an interesting example of how our intuition about
MITM attacks can fail in subtle ways.
------------------------------
** 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
******************************
