Cryptography-Digest Digest #429, Volume #11 Mon, 27 Mar 00 12:13:01 EST
Contents:
Re: Basic info on cryptography (doc)
DES question (doc)
Re: DES question (Paul Rubin)
Re: Sunday People 26/3/2000: "FORGET YOUR PASSWORD... END UP IN JAIL" ("Nick")
Re: DES question ("Douglas A. Gwyn")
Re: Mixing N bits into N bits (John Savard)
Re: Hashes! (newbie question) (Runu Knips)
Re: one-way hash functions with 256-bit output (Runu Knips)
Re: root mod a prime? (Mika R S Kojo)
Re: Does anybody know of a secure FTP server? (Nuno Jaime Cardoso)
Re: Basic info on cryptography (George Voina)
Re: Mixing N bits into N bits (Mok-Kong Shen)
Examining random() functions (_Andy_)
Re: DES question (John Savard)
Re: Checking for a correct key (Thomas Luzat)
Re: Download Random Number Generator from Ciphile Software (Eric Lee Green)
Re: OAP-L3: Answer me these? (Eric Lee Green)
Re: one-way hash functions with 256-bit output (Scott Nelson)
Re: OAP-L3: Answer me these? (Eric Lee Green)
Re: DES question (Frank Gifford)
----------------------------------------------------------------------------
From: doc <[EMAIL PROTECTED]>
Subject: Re: Basic info on cryptography
Date: Mon, 27 Mar 2000 04:42:59 -0500
Try "Applied Crypography" by Bruce Schneier. Published by
Wiley.
DOC
Slip Gun wrote:
>
> Where can a newbie to cryptography find info on the subject? Eg how to
> write asymetrical (sorry about spelling) code, what they mean when they
> say 128-bit encryption, etc. A website would be useful.
> Thanks,
> Ed
> --
> Those who trade privacy in favour of security will soon find that they
> have neither.
------------------------------
From: doc <[EMAIL PROTECTED]>
Subject: DES question
Date: Mon, 27 Mar 2000 05:14:21 -0500
I would appreciate any help/input in considering this
question.
Given a specific randomly generated ciphertext, does there
exist a key, plaintext combination that can encrypt to it?
Perhaps a more general way of asking this question is to
inquire about the domain of the ciphertext.
Or, is it possible to have a ciphertext that does NOT
decrypt
using DES?
If it is not clear from the question, I am asking about the
nature of DES and not it's strength.
Thanks,
DOC
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: DES question
Date: 27 Mar 2000 10:23:34 GMT
In article <[EMAIL PROTECTED]>, doc <[EMAIL PROTECTED]> wrote:
>I would appreciate any help/input in considering this
>question.
>
>Given a specific randomly generated ciphertext, does there
>exist a key, plaintext combination that can encrypt to it?
Of course. Just take any key and use it to decrypt the ciphertext.
>Perhaps a more general way of asking this question is to
>inquire about the domain of the ciphertext.
>
>Or, is it possible to have a ciphertext that does NOT
>decrypt using DES?
That wouldn't make any sense. It would mean the encryption was not
reversible.
------------------------------
From: "Nick" <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,uk.politics.censorship
Subject: Re: Sunday People 26/3/2000: "FORGET YOUR PASSWORD... END UP IN JAIL"
Date: Mon, 27 Mar 2000 11:25:12 +0100
Geordie <[EMAIL PROTECTED]> wrote in message
news:8blmck$24j9$[EMAIL PROTECTED]...
>
>
> The most frightening thing is he can get away with it. There seem to be no
> organised protest to this attack on fundamental right's to privacy. Well
> maybe this just goes to prove, as I have often suspected, that we are the
> most intolerant and authoritarian country in the Western world.
>
> Geordie
>
1 - The European Convention on Human Rights becomes part of British Law in
October, and includes provisions on privacy
2 - Get on to your MP and complain like hell!
Nick
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: DES question
Date: Mon, 27 Mar 2000 10:31:10 GMT
Paul Rubin wrote:
> ... doc <[EMAIL PROTECTED]> wrote:
> >Or, is it possible to have a ciphertext that does NOT
> >decrypt using DES?
> That wouldn't make any sense. It would mean the encryption was not
> reversible.
While not an issue for DES, it does make sense for some other
encryption systems.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Mixing N bits into N bits
Date: Mon, 27 Mar 2000 10:13:37 GMT
On 26 Mar 2000 19:44:06 EST, [EMAIL PROTECTED] (Guy Macon) wrote,
in part:
>I would like to convert the variable into a
>32 bit variable where each bit is equally likely to flip as time
>increments, yet I want to keep the property that I am 100% certain
>that the variable will never repeat in this century.
>BTW, would "hash"
>be a proper word to call what I just described?
No, because even a cryptographically-secure hash is not 100% certain
not to convert two different 32-bit values to the same result. But an
invertible cipher would be, so a scaled-down version of DES with a
32-bit block size would meet your criteria.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
Date: Mon, 27 Mar 2000 12:54:08 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Hashes! (newbie question)
Boris Kazak schrieb:
> > (b) you use nothing but multiplication to produce the
> > hash. muliplication is both slow and bad for certain
> > input values (for example, 0*anything=0).
> -----------------------
> This would be true if the multiplication used would be
> (mod 2^32-1). In case of multiplication (mod 2^32+1) the rules
Aaaaah !!! Thats the thing I've didn't seen ! I've read
"mod 2^32+1" as "mod 2^32-1" all the time...
------------------------------
Date: Mon, 27 Mar 2000 13:17:39 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: one-way hash functions with 256-bit output
stanislav shalunov schrieb:
> My questions were, anyway,
> (a) Is there something that is going to become a "standard"
> collision-free one-way function with 256-bit output?
> (b) What is the most likely candidate for this position?
Well I would like to know that too. I've already thought of
simply mixing the outputs of SHA-1 and RIPE MD160 so the
result is 256 bit, but thats of course not a standard
algorithm with a paper etc.
In fact, I would like the situation of having multiple
different algorithms.
------------------------------
From: Mika R S Kojo <[EMAIL PROTECTED]>
Subject: Re: root mod a prime?
Date: 27 Mar 2000 14:46:11 +0300
"Tom St Denis" <[EMAIL PROTECTED]> writes:
>
> The problem is that I am adding this to my crypto library, and want to be
> able to make new curves as the user sees fit.
>
> Tom
Hi Tom,
The problem with SEA (Schoof-Elkies-Atkin) algorithm is that you might
need about hundred random tries before finding a suitable curve. Even
though best implementations seem to find the order of one curve in
about minute or two this clearly is not real time.
So using Mike Scott's program is not too bad an option. What I understand
it is very fast and freely available.
Nevertheless, I would like to encourage you to take upon the task of
implementing the Schoof's original algorithm with suitable Shanks
bs-gs (or Pollard lambda) continuation. It is not trivial to
implement, nor to understand, but very good practice at least if you
are interested in the basic algebraic aspects of elliptic curves. In
my opinion it is easier to implement than complex multiplication based
counting.
You probably should read the original paper by Rene Schoof, and the
book by Alfred Menezes. Also you could look for the paper by Buchmann
and Mueller for some insight. Be warned that the original paper by
Schoof contains few typos in the equations (if I recall correctly),
but those are easy to derive by oneself.
If you have a few months time you could then expand the code to SEA,
which is slightly more complicated to understand, and to
implement. There is a good book by Ian Blake, Gadiel Seroussi and
Nigel Smart which you probably should read even if you are not
interested in the implementation of SEA algorithm. It gives a good
overview of all aspects of elliptic curve cryptography.
-- Mika
------------------------------
From: Nuno Jaime Cardoso <[EMAIL PROTECTED]>
Subject: Re: Does anybody know of a secure FTP server?
Date: Mon, 27 Mar 2000 12:54:38 +0100
Abid Farooqui wrote:
> Ok that is helpful to know but do you know of any ftp servers that either
> have a module to do ftps or ftps is built in. Can they be set with different
> options like ssl on Apache using httpd.conf file etc.
> Secondly, do any of you know of a SSL module for apache or any other
> webserver or ftp server that does encryption/decryption in hardware like on a
> crypto chip so that precious CPU time and cycles are spared from this task. I
> am trying to set up a system where I will be sending large files (GB of data)
> over SSL to and from a SSL enabled webserver/ftp server.
> Thanks
> Abid Farooqui
Some time ago I made a proposal to a customer that required a FTP server over
SSL that integrates with Netscape Products and, I remember that I found him one
but, he had several problems because the FTP clients aren't ready to support
SSL. Remember that not only the server, but also the client, has to support the
protocol. (Quite obvious but, people usualy forget that). The thing his that
there are very few FTP clients that use SSL.
The best way his realy to have the files transfered by Https, using an Web
Server and, if you don't have money for a powerfull machine, I recomendthat you
buy an SSL acelerator card, they realy work and they realy incresase
performance.
Sorry for any eventual mistakes i gave with my English but, I believe that my
English his a lot better than your Portuguese :)))))
Bye
//Jaime Cardoso
------------------------------
From: George Voina <[EMAIL PROTECTED]>
Subject: Re: Basic info on cryptography
Date: Mon, 27 Mar 2000 15:30:57 +0200
Slip Gun wrote:
>
> Where can a newbie to cryptography find info on the subject? Eg how to
> write asymetrical (sorry about spelling) code, what they mean when they
> say 128-bit encryption, etc. A website would be useful.
> Thanks,
> Ed
> --
> Those who trade privacy in favour of security will soon find that they
> have neither.
One of the best books of cryptography ( also a good material for
begginers )"Handbook of Applied Cryptography" is now free to download at
the address :
http://cacr.math.uwaterloo.ca/hac/
Best regards,
George.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Mixing N bits into N bits
Date: Mon, 27 Mar 2000 16:18:18 +0200
John Savard wrote:
>
> On 26 Mar 2000 19:44:06 EST, [EMAIL PROTECTED] (Guy Macon) wrote,
> in part:
>
> >I would like to convert the variable into a
> >32 bit variable where each bit is equally likely to flip as time
> >increments, yet I want to keep the property that I am 100% certain
> >that the variable will never repeat in this century.
>
> >BTW, would "hash"
> >be a proper word to call what I just described?
>
> No, because even a cryptographically-secure hash is not 100% certain
> not to convert two different 32-bit values to the same result. But an
> invertible cipher would be, so a scaled-down version of DES with a
> 32-bit block size would meet your criteria.
Consider the full DES. If the input runs from 0 to 2^64-1, it is
not apparent to me why each bit of the output should be very random.
For suppose we run this presumably very random output backwards
thru DES, then we do get back the original input which is not random
at all. Thus the avalanche property etc. don't seem to be sufficient
to study the issue at hand. What's the fault with my argument?
Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (_Andy_)
Subject: Examining random() functions
Reply-To: [EMAIL PROTECTED]
Date: Mon, 27 Mar 2000 14:12:40 GMT
I've been playing around with random integer generators and
was wondering about different methods of examining the output.
Currently, I take my results and plot a 3-dimensional graph
and examine it by eye. i.e. I take three consecutive results and treat
them as the (x,y,z) coordinates of a point and plot it on the graph. I
repeat this until a visual pattern emerges. (As described in "Jungles
of Randomness")
If a pattern emerges, I tend to apply fiddle factors until the
pattern becomes so complex that it seems to disappear.
So, can anyone recommend another way?
For example...
The following function will generate a random integer where:
0 <= n < nMax.
--begin random.c--
static int nRandomSeed = 0;
int SetSeed(int nSeed)
{
nRandomSeed = nSeed;
return( nRandomSeed );
}
int Random(int nMax)
{
static int nOldRandom = 0;
static int nIteration = 0;
int n1;
n1 = nRandomSeed;
n1 *= nOldRandom + (nRandomSeed % 7);
n1 += 797 + (nOldRandom >> 3);
if( n1 & 0xc0 ) n1 -= nRandomSeed;
nRandomSeed = nRandomSeed + n1 % 0xdfdf + nIteration;
nOldRandom = n1;
n1 = n1 % nMax;
if( n1 < 0 ) n1 = -n1;
nIteration++;
return( n1 );
}
--end random.c--
The distribution seems fair (for small nMax - I haven't
checked large yet) now that the various fiddle factors have been
introduced. It would be nice to have a more formalised proof, and
better development process... rather than the trial-and-error that
I've been using.
Your thoughts appreciated,
Andy
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: DES question
Date: Mon, 27 Mar 2000 14:11:13 GMT
On Mon, 27 Mar 2000 10:31:10 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote, in part:
>Paul Rubin wrote:
>> ... doc <[EMAIL PROTECTED]> wrote:
>> >Or, is it possible to have a ciphertext that does NOT
>> >decrypt using DES?
>> That wouldn't make any sense. It would mean the encryption was not
>> reversible.
>While not an issue for DES, it does make sense for some other
>encryption systems.
Or, to be more specific, having a ciphertext that does not decrypt
using DES does not make sense, and implies that the encryption is not
reversible, because DES maps 64-bit blocks to 64-bit blocks without
expansion.
As it happens, it is also not possible to have a ciphertext that does
not validly decrypt with DES even if one is applying DES to it in one
of those modes which, on encipherment, involves the expansion of the
plaintext with a 64-bit IV. This is because the IV is independent of
the plaintext; for each possible plaintext, there are exactly 2^64
possible expanded plaintexts as input into the cipher.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: Thomas Luzat <[EMAIL PROTECTED]>
Subject: Re: Checking for a correct key
Date: Mon, 27 Mar 2000 18:18:27 +0200
Reply-To: [EMAIL PROTECTED]
On Sun, 26 Mar 2000 20:41:31 -0000, "Joseph Ashwood"
<[EMAIL PROTECTED]> wrote:
>3 seems to be the best from your list. OTOH it is commonly
>considered secure (and almost certainly is) to store a hash
>of the original file. Given a cryptographically strong hash
>this does not weaken the security of the file (except that
>it becomes possible to verify a key guess). Storing the hash
>encrypted is of no use, so save yourself the processor time,
>and simply store the hash.
> Joe
What if I encrypted only very small files (1-100 byte for example)?
Wouldn't the hash make an attack much easier? My files will probably
be somewhat bigger, but would it be better to store some junk data in
the files if they get too short?
Thanks,
Thomas
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Download Random Number Generator from Ciphile Software
Date: Mon, 27 Mar 2000 16:20:38 GMT
Anthony Stephen Szopa wrote:
> What would you say if there were no attacks possible against
> OAP-L3 when used according to recommendations (truly random user
> input and large key length) except brute force?
I would suggest a paper similar to the Yarrow paper, which addresses a large
number of potential attacks including references to other papers about those
attacks, and steps they made to make sure that it was not succeptible to those
attacks.
As for what you "say", I'd say that all random number generators have attacks.
The issue is how to minimize those attacks. For example, even the Linux
/dev/random, as deeply embedded in OS internals as it is, is succeptible to
attack if the attacker has control over the system clock and can monitor the
device interrupts. (Something that might be possible in, e.g., a smart card
application). To totally dismiss issues of this type gives people the
impression that you are engaged in complete hyperbole.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Date: Mon, 27 Mar 2000 16:29:56 GMT
Anthony Stephen Szopa wrote:
> 1) CASE: liar. You say the theory, and specification of the
> procedures and processes have not been made available. Not true.
> The theory, and specification of the procedures and processes have
> been available for some time now at http://www.ciphile.com
Could you direct me to the particular page where these are described? I just
went to www.ciphile.com and could not find the described page. I did find
numerous mis-spelled words including one on the master navigation menu, and no
firm description of exactly what products or services Ciphile is engaged in,
all of which gives a very unprofessional impression of the web site.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: one-way hash functions with 256-bit output
Reply-To: [EMAIL PROTECTED]
Date: Mon, 27 Mar 2000 16:31:20 GMT
On Mon, 27 Mar 2000 01:35:19 GMT, stanislav shalunov
<[EMAIL PROTECTED]> wrote:
>David A Molnar <[EMAIL PROTECTED]> writes:
>
>> Check http://www.cryptonessie.org/ for a start..
>
>I could not find their motivation for 512-bit output hash functions.
>It seems like 256 bits should be enough for everybody (or am I
>sounding too much like the billionaire who said this about 640K of
>RAM?).
>
>To find a collision with probability of 10^{-10} we'd need around
>2^112 function values. Is this considered to be something within
>reach of mankind in the future? Or what is the motivation?
Currently published brute force cracks have gone up to 2^56
Assuming Moore's Law continues to apply, 2^112 is about 75 years
in the future. Whether we can actually get there is another
question, but 112 doesn't violate any fundamental limits
that are known. I personally consider 75 years in the reach
of mankind in the future, but that too is debatable.
But I think the real motivation for large hash is
if 512 is too much, then it's easy to throw bits away.
But if 256 isn't enough, it's not as easy to scale up.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Answer me these?
Date: Mon, 27 Mar 2000 16:42:04 GMT
Jerry Coffin wrote:
> Despite this, if a particular person's vote is represented (for
> example) as a single bit, with a 0 representing a vote for one
> candidate, and a 1 a vote for the other, I can easily switch
> everybody's votes: I simply toggle the bit from whatever it presently
> is, to the other possible value.
That is why no serious encryption protocol would lack at least a CRC checksum
to make sure that the data received has not been messed with. In reality,
you'd also have a sequence number and salt value in order to prevent replay
attacks, and you'd probably also have a cryptographically secure digest rather
than a plain old CRC (much harder to find a plaintext that encrypts to the
same checksum then).
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: [EMAIL PROTECTED] (Frank Gifford)
Subject: Re: DES question
Date: 27 Mar 2000 11:55:06 -0500
In article <[EMAIL PROTECTED]>, doc <[EMAIL PROTECTED]> wrote:
>I would appreciate any help/input in considering this
>question.
>
>Given a specific randomly generated ciphertext, does there
>exist a key, plaintext combination that can encrypt to it?
Yes, pick any key you want and decrypt the ciphertext.
>Or, is it possible to have a ciphertext that does NOT
>decrypt
>using DES?
If what you are asking is: Can DES encrypt from an arbitrary plaintext P
to a ciphertext C? The answer is generally no. The reason is immediately
obvious since the keyspace is 56 bits, but the block sizes are 64 bits.
-Giff
--
Too busy for a .sig
------------------------------
** 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
******************************
