Cryptography-Digest Digest #401, Volume #13 Fri, 29 Dec 00 14:13:00 EST
Contents:
Re: example code for your use (Simon Johnson)
Basic infor for newbies ("Dullboy")
Re: "Content Protection for Recordable Media" (Mok-Kong Shen)
Re: ___Robert Harley's field multiplications algorithm in GF(2^n) (kctang)
Re: Array shuffling (Tim Tyler)
Re: "Content Protection for Recordable Media" (Stephan T. Lavavej)
Re: Identifying string with blowfish (Christian =?iso-8859-1?Q?Reitwie=DFner?=)
Re: Merry Christmas (Rob Warnock)
calculating 2048 bit public key ops with an 1024 bit engine? (Aki M Suihkonen)
Re: I may file a complaint with the FBI against some people in the past (Paul
Crowley)
Q: COFDM (Mok-Kong Shen)
Re: Some articles of the constitution of Finland .... "Right to privacy" ... "
Freedom of expression and right of access to information" ... " Freedom of assembly
and freedom of association" -- Finnish people violated all ..... ([EMAIL PROTECTED])
Re: Array shuffling (Mok-Kong Shen)
Cryptlib and SQL Server databases ("Michael")
Re: Newbie (cracking DES in months on an Athlon) (Simon Johnson)
Re: Newbie (cracking DES in months on an Athlon) (Simon Johnson)
----------------------------------------------------------------------------
Subject: Re: example code for your use
From: Simon Johnson <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.lang.c.moderated
Date: 29 Dec 2000 05:28:53 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Da Big Book quoteth on 03 Nov 2000 23:00:27 GMT, famous Monk
> [EMAIL PROTECTED] (Kenneth Lantrip) preached:
>
> > I have written a nice (I think so) little program in C to help me
learn the use
> > of the language. I'm not sure if it's legal to post an encryption
algorithm
> > that uses a 128 bit key. I'd like to offer it to whoever wants to
see the code
> > so that they might can use parts of it or learn from it or whatever.
>
> [snip]
> I'd be interrested out of curiosity :)
> however... I live in Europe.
>
> > If you would like to look over the source code, e-mail me and I'll
send it to
> > ya if ya live in the USA. I'm not sure export laws allow 128 bit
crypto
> > algorithms to be exported. However, I can point you in the right
direction to
> > where you can get the source for the IDEA algorithm that was used
in the
> > program below. I can still send you the main() function.
>
> [snip]
> point ahead :)
> I don't know if it's still forbidden, but you could just as well
> modify your program and have an "international 40 bits" version...
> once one has the code, getting it from 128 to 40 to 128 bits shouldn't
> be too complicated :)
>
> As someone pointed however, you might indicate/document for which
> computer (I'd guess at a PC) and OS and compiler it's meant.
>
> > I realize that these stupid crypto laws are a direct infringement
of my first
> > amendment constitutional right!
>
> How about ours :) [not that onyone cares]
>
> Serge
>
> ----------------------------------------------------------------------
========
> The opinions expressed are mine and none other's
> ----------------------------------------------------------------------
========
> Serge Marelli
> [EMAIL PROTECTED]
> --
> comp.lang.c.moderated - moderation address: [EMAIL PROTECTED]
>
I often wonder how successful that export legislation has been, have
any convictions been made on it?
Simon.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
--
comp.lang.c.moderated - moderation address: [EMAIL PROTECTED]
------------------------------
From: "Dullboy" <[EMAIL PROTECTED]>
Subject: Basic infor for newbies
Date: Thu, 28 Dec 2000 12:35:46 +0100
I recently got interested in cryptology reading a book on the subject and
was wondering where I can find more information in general and in specific
crypto methods. Are there any sites that are more relevant than others?
Thanks /Fredrik
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: "Content Protection for Recordable Media"
Date: Fri, 29 Dec 2000 10:19:32 +0100
John Savard wrote:
>
> Mok-Kong Shen<[EMAIL PROTECTED]> wrote:
>
> >Dumb quesion: What prevents one from reading from such a
> >drive into memory and writing out to a drive without
> >protection features, which some manufacturers of the world
> >would certainly continue to produce to meet a corresponding
> >market demand?
>
> What happens is this:
>
> Normally, files are written to, and read from, the drive like any
> other drive, and they can be copied.
>
> But content-protected files, when written to the drive, are in
> encrypted form. And the key to the encryption is written on a part of
> the hard drive which is not directly accessible.
>
> The program writing the file to the hard drive specifies something
> like a password, and the viewer program which is the only thing
> allowed to read the file knows this password. Since the password needs
> to be combined with the key on that particular drive to decrypt the
> file, it can only be turned into its unencrypted form by the viewer
> programs that know the right password, and on the specific machine on
> which it was installed.
>
> Thus, copying it in encrypted form is useless. And if you don't have
> one of those new-style drives, you won't be able to download the
> content which is only for distribution to them.
If one has a license, then one can read its content into
memory (hack the viewer program, if necessary) and write
it out to another drive without protection features.
Wouldn't this open a way to make copies that are freely
readable?
>
> This does create a problem of backup, since what if one wants to take
> this kind of content temporarily off of that hard drive to use the
> space for something else? It is assumed that it is good enough to
> allow individual content providers to each have their own scheme for
> transferring protected content from one user's hard drive somewhere
> else.
If there is some master (magic) piece of software/hardware
at the manufaturers/providers to bypass the protection, then
some other people wanting to do copying for profit would be
able to do the same. So I doubt that the protection could
succeed.
M. K. Shen
------------------------------
From: kctang <[EMAIL PROTECTED]>
Subject: Re: ___Robert Harley's field multiplications algorithm in GF(2^n)
Date: Fri, 29 Dec 2000 18:32:04 +0800
==============4C841EC5FCA47AB03D4B6801
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
robert harley <[EMAIL PROTECTED]> wrote:
>Here are some times for field multiplications in GF(2^n) on a 750 MHz
>Alpha in microseconds:
> n time
> 163 0.48
> 193 0.64
> 239 0.92
>In this case, an elliptic curve multiplication takes six field
>multiplications per bit (and some cheap stuff: four squares, three
>sums) using Peter Montgomery's trick. Count seven multiplications per
>bit and you won't be far off.
Then we have:
Platform
========
a 750 MHz Alpha
The performance of Elliptic Curve multiplications over GF(2^m)
==============================================================
bit ER (Elliptic Curve point multiplication r.P)
--- -------------------------------------------
163 bit 0.48 * 163 * 7 * 10^(-3) = 0.5477 ms
193 bit 0.64 * 193 * 7 * 10^(-3) = 0.8646 ms
23_9 bit 0.92 * 239 * 7 * 10^(-3) = 1.539 ms
283 bit
>.. .. . using Peter Montgomery's trick.
So no precomputation of Points is required. But Alpha 750MHz is a
64-bit machine, which is too big and too expensive.
What kind of magic are found inside Dr. Robert Harley's field
multiplications algorithm in GF(2^n)?
Thanks, kctang
==============4C841EC5FCA47AB03D4B6801
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
robert harley <[EMAIL PROTECTED]> wrote:
<br>
<br>>Here are some times for field multiplications in GF(2^n) on a 750
MHz
<br>>Alpha in microseconds:
<br>> n time
<br>> 163 0.48
<br>> 193 0.64
<br>> 239 0.92
<br>>In this case, an elliptic curve multiplication takes six field
<br>>multiplications per bit (and some cheap stuff: four squares, three
<br>>sums) using Peter Montgomery's trick. Count seven multiplications
per
<br>>bit and you won't be far off.
<br>
<br><tt>Then we have:</tt>
<br><tt> </tt>
<br><tt>Platform</tt>
<br><tt>--------</tt>
<br><tt>a 750 MHz Alpha</tt>
<br><tt> </tt>
<br><tt>The performance of Elliptic Curve multiplications over GF(2^m)</tt>
<br><tt>--------------------------------------------------------------</tt>
<br><tt> </tt>
<br><tt>bit ER (Elliptic
Curve point multiplication r.P)</tt>
<br><tt>---
-------------------------------------------</tt>
<br><tt>163 bit 0.48 * 163 * 7 * 10^(-3)
= 0.5477 ms</tt>
<br><tt> 193 bit 0.64 * 193 * 7 * 10^(-3)
= 0.8646 ms</tt>
<br><tt>23_9 bit 0.92 * 239 * 7 * 10^(-3) = 1.539
ms</tt>
<br><tt>283 bit</tt>
<br><tt> </tt>
<br>
<br>>.. .. . using Peter Montgomery's trick.
<br>
<br><tt>So no precomputation of Points is required. But Alpha 750MHz is
a</tt>
<br><tt>64-bit machine, which is too big and too expensive.</tt>
<br><tt> </tt>
<br><tt>What kind of magic are found inside Dr. Robert Harley's field</tt>
<br><tt>multiplications algorithm in GF(2^n)?</tt>
<br><tt> </tt>
<br><tt>Thanks,
kctang </tt>
<br>
<br> </html>
==============4C841EC5FCA47AB03D4B6801==
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Array shuffling
Reply-To: [EMAIL PROTECTED]
Date: Fri, 29 Dec 2000 11:34:08 GMT
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
[LCG cycles in low bits]
:> This is also a description of the LCG in Sun's JVM.
:>
:> It uses a 48-bit state and outputs the top 32 bits.
:>
:> The defect is quite visible in simple programs - e.g.:
:>
:> http://alife.co.uk/nonrandom/
: Although it's quite clear from your example that java.util.Random (and
: rand() as well) are both nonrandom, there is no indication that rand()
: is bad for practical use.
I found the problem in the process of developing a real application.
I was not thinking about the possibility of the RNG being knackered -
since it was the RNG in the Java class libraries themselves - and spent
a while looking for bugs in my own code. When I identified the problem I
was staggered that the RNG was so bad that I could see the problem so
clearly.
: If I convert the output of rand() into a float in the range [0,1), by
: dividing by (float)(1<<16), the values will have quite decent
: statistics.
That's probably true. Only the Random.nextInt() and Random.nextLong()
exhibit the problem clearly. This sort of RNG is not so bad for
generating FP numbers, since then the non-randomness goes in the LSBs.
However, when generating *integers*, the most non-random bits get to
determine whether the number is even or odd. That's hardly a "not very
significant" property. It seems like a recipe for disaster to me.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: stl/*This_is_a_comment*[EMAIL PROTECTED] (Stephan T. Lavavej)
Subject: Re: "Content Protection for Recordable Media"
Date: Fri, 29 Dec 2000 15:18:15 GMT
> there is fierce opposition to the plan from
> Microsoft and its OEM customers.
Thank the gods that _Microsoft_ is against this crud. It'll have a
hard time surviving now, because it's intrinsically crap (unlike, say,
Linux, which Microsoft is also against).
-*---*-------
Stephan T. Lavavej
http://quote.cjb.net
stl/*This_is_a_comment*[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Christian =?iso-8859-1?Q?Reitwie=DFner?=)
Subject: Re: Identifying string with blowfish
Date: Fri, 29 Dec 2000 16:32:32 +0100
In article <[EMAIL PROTECTED]>, Paul Rubin wrote:
>What exactly are you doing? You do know that someone has already
>implemented CAST encryption in ircii? Are you adding encryption to
>some different client? To ircd? Is there some reason you want to use
>Blowfish instead of CAST?
I am just doing it for fun and for that it's my own :-)
And I want to implement it not for a single client, but as an external program
on Linux and as a DLL für Windows.
And the reason I'm not using CAST is that I haven't yet know about it. (I have
just read the RFC)
What are the advantages of CAST?
--
Christian Reitwießner <[EMAIL PROTECTED]>
--> http://www.secretstar.de
Kenny the talking bot:
--> kenny_dod #frg on IRCNet
------------------------------
From: [EMAIL PROTECTED] (Rob Warnock)
Subject: Re: Merry Christmas
Date: 29 Dec 2000 11:30:56 GMT
Dennis Ritchie <[EMAIL PROTECTED]> wrote:
+---------------
| The oldie (from the Brahms Gang at Berkeley):
| obnoxio@brahms (weemba) wrote [in netnews long ago]--
...
| who | grep bad || good
+---------------
Hmmm... Shouldn't that have been this instead? ;-}
who | egrep 'bad|good'
-Rob
=====
Rob Warnock, 31-2-510 [EMAIL PROTECTED]
SGI Network Engineering http://reality.sgi.com/rpw3/
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
------------------------------
From: [EMAIL PROTECTED] (Aki M Suihkonen)
Crossposted-To: sci.math.num-analysis
Subject: calculating 2048 bit public key ops with an 1024 bit engine?
Date: 29 Dec 2000 15:55:32 GMT
Hello!
Given a crypto core capable of performing upto 1024 bit wide
(public key) modular exponentiation, is it even relatively easy
to extend it for operations twice the length?
Private key ops wouldn't be a problem, thanks to CRT.
Are there any special cases where M^B mod (N_h*2^1024 + N_l)
would be easy to calculate? Eg. when GCD(N_h, N_l)=1 ?
Any thoughts?
--
Problems 1) do NOT write a virus or a worm program
"A.K.Dewdney, The New Turing Omnibus; Chapter 60: Computer viruses"
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Crossposted-To: alt.2600,alt.security,comp.security
Subject: Re: I may file a complaint with the FBI against some people in the past
Date: Fri, 29 Dec 2000 17:22:59 GMT
Tom ST Denis wrote:
> > I may contact the FBI and file charges .. so this is the way it will
> > be ...
>
> The lesson kids is don't drink and type.
The lesson is to take mental health seriously. Someone you know could
fall victim to this potentially debilitating or fatal illness.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Q: COFDM
Date: Fri, 29 Dec 2000 18:26:35 +0100
I came across the term COFDM, coded orthogonal frequency
division multiplexing. Would someone please tell in what
aspects it distinguishes itself from FDM and CDM? What are
its specific advantages? Any literature pointers?
Thanks in advance.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.2600,comp.security,alt.security
Subject: Re: Some articles of the constitution of Finland .... "Right to privacy" ...
" Freedom of expression and right of access to information" ... " Freedom of assembly
and freedom of association" -- Finnish people violated all .....
Date: Fri, 29 Dec 2000 17:27:40 GMT
In article <92fta8$jfd$[EMAIL PROTECTED]>,
Markku J. Saarelainen <[EMAIL PROTECTED]> wrote:
>
>
> Actually Finnish people (the government reps .. I have records of
this)
> violated my rights to privacy ... Tina Nelin, my ex-relatives together
> with my ex-spouse violated my privacy ..... "Section 10 - The right to
> privacy"
Markku,
i have been following your posts for some time, and it is clear that
you have had a great deal of anguish in your life.
there are medicines that can make you feel a great deal better, and
help you think clearly.
find a doctor that you trust, tell him/her all that you have gone
through, and you will be given the proper medication to help you,,
and you can begin to have a new life.
it is painful to continue to see you sufferring as you are,
be well,
vedaal
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Array shuffling
Date: Fri, 29 Dec 2000 18:40:46 +0100
Tim Tyler wrote:
>
[snip]
> That's probably true. Only the Random.nextInt() and Random.nextLong()
> exhibit the problem clearly. This sort of RNG is not so bad for
> generating FP numbers, since then the non-randomness goes in the LSBs.
>
> However, when generating *integers*, the most non-random bits get to
> determine whether the number is even or odd. That's hardly a "not very
> significant" property. It seems like a recipe for disaster to me.
If one wants bit sequences, I suppose the better way is
to first normalize to reals in [0,1) and then multiply to
obtain integers of a suitable range.
M. K. Shen
------------------------------
From: "Michael" <m.condillac@/**DELETE**/blueyonder.co.uk>
Subject: Cryptlib and SQL Server databases
Date: Fri, 29 Dec 2000 18:38:39 GMT
Hi,
Im currently working on my final year project that is focusing on Anonymity
over the Internet using Digital mixes as described by Chaum. My theory is
that a message is encoding using public keys of mixes in a reverse order and
decoded at using the mix's private key and forwarded.
My problem is that i am unsure as to how Cryptlib deals with private keys
from a database. Can i create a number of key pairs using PGP and export
into a SQL server database and use GetPublicKey and GetPrivateKey?
Does Cryptlib expect the database to follow a certain structure?
Thanks,
Michael
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Newbie (cracking DES in months on an Athlon)
Date: Fri, 29 Dec 2000 18:46:09 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Marc) wrote:
> >Often brute forcing is done on a cluster of computers (a DES key
would
> >takes months on a Atlhon 500) to linearly increase the search rate.
>
> My last info was that it takes hundreds of years on a single CPU,
> doesn't it?
>
> What programs perform the attack in just months?
>
There is an attack that can solve des with considerable known-plain-text
in just a month or so on a cluster of fast machines.
If its brute-force attacking your wondering about then the program
isn't the issue; trying every key is simple there are few things that
can be done to optimise. What matters is the speed of execution, and
this is dependent on the speed of processor.
This said, Tom's estimate is ambitious: He said an Atlhon 500 can
execute 1.5 billion instructions per second, lets say that translates
to 200 million keys per second (is that ambitious?) then it would take
around 6 years to solve on this machine.
Still if Moore's Law holds out, his estimation will become reality in
the next few years.
Simon.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Newbie (cracking DES in months on an Athlon)
Date: Fri, 29 Dec 2000 18:46:05 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Marc) wrote:
> >Often brute forcing is done on a cluster of computers (a DES key
would
> >takes months on a Atlhon 500) to linearly increase the search rate.
>
> My last info was that it takes hundreds of years on a single CPU,
> doesn't it?
>
> What programs perform the attack in just months?
>
There is an attack that can solve des with considerable known-plain-text
in just a month or so on a cluster of fast machines.
If its brute-force attacking your wondering about then the program
isn't the issue; trying every key is simple there are few things that
can be done to optimise. What matters is the speed of execution, and
this is dependent on the speed of processor.
This said, Tom's estimate is ambitious: He said an Atlhon 500 can
execute 1.5 billion instructions per second, lets say that translates
to 200 million keys per second (is that ambitious?) then it would take
around 6 years to solve on this machine.
Still if Moore's Law holds out, his estimation will become reality in
the next few years.
Simon.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com
http://www.deja.com/
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
