Cryptography-Digest Digest #841, Volume #10 Wed, 5 Jan 00 12:13:01 EST
Contents:
Re: Square? (Mok-Kong Shen)
Re: How to pronounce "Vigenere"? (Boyd Roberts)
Re: RSA encrypt (Paul Schlyter)
Re: "Variable size" hash algorithm? (Terje Elde)
Re: RSA encrypt (Paul Schlyter)
Re: RSA encrypt (Paul Schlyter)
Re: How to pronounce "Vigenere"? ("LBMyers")
Re: REQ: Applied Crypto source disc ("LBMyers")
Re: PKZIP compression security ([EMAIL PROTECTED])
Re: RSA encrypt (Paul Rubin)
Re: REQ: Applied Crypto source disc (Paul Rubin)
Re: REQ: Applied Crypto source disc (Paul Crowley)
Re: cracking Triple DES (DJohn37050)
Re: How to pronounce "Vigenere"? ("Tony T. Warnock")
Re: Truly random bistream (James Felling)
New ECM record: up to 60 digits (Paul Zimmermann)
Re: Truly random bistream (Tim Tyler)
Re: Square? (James Felling)
Re: Wagner et Al. (Tim Tyler)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Square?
Date: Wed, 05 Jan 2000 11:19:49 +0100
Andrej Madliak wrote:
>
> Who knows something about the "Square" algorithm, it's
> strenght/weaknesses and attacks against it?
I suggest that such questions be always accompanied with references,
i.e. where (in which paper, journal, internet news article) one met
with the names in question that are presumably not very well-known.
M. K. Shen
------------------------------
From: Boyd Roberts <[EMAIL PROTECTED]>
Subject: Re: How to pronounce "Vigenere"?
Date: Wed, 05 Jan 2000 11:37:24 GMT
In article <[EMAIL PROTECTED]>,
Jay wrote:
> On Tue, 04 Jan 2000 06:47:26 GMT, [EMAIL PROTECTED]
(John
> Savard) wrote:
>
> >Vee-zhen-yehr is about right.
>
> That first 'e' is silent, John. More Vee-zh-nyehr.
>
Yeah, that's it. The first 'e' isn't really silent, but it's glued to
the 'g' to give the 'zh' sound. I'd group the sounds this way:
vee-zhn-yehr
You need a grave accent over the second e:
vigenère
--
See, an ordinary person spends his life avoiding tense situations.
A repo man spends his life getting into tense situations.
-- Bud, Repo Man
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: RSA encrypt
Date: 5 Jan 2000 12:44:35 +0100
In article <[EMAIL PROTECTED]>,
Paul Koning <[EMAIL PROTECTED]> wrote:
> Brice wrote:
>
>> I have a question about RSA.
>>
>> If I was to calculate M^d (M: message, d: secret key) and give it away for
>> the modular step to be done by someone else (say), how easy would it be for
>> that person to find what my secret key is since my public key is available
>> to anyone ?
>
> Very easy.
>
> That other person can do the mod, then decrypt the result to get M
> again. Now he has M and M^d. Take the log of both sides, divide,
> and presto, there's d.
One practical problem: how would you store the full M^d ? If we assume
M and d are both 512 bits (a minimum requrement -- 512-bit RSA can today
be cracked with some effort), then M^d would be approx 512*(2^512) = 6.8E+156
bits large. If you want to use M and d wihich each are 1024 bits, then
the full M^d would be approx 1024*(2^1024) = 1.8E+311 bits large.
The entire universe contains about 1E+80 atoms. Thus, you'd need to
store 1E+77 (512-bit case) or 1E+231 (1024-bit case) in EACH ATOM OF
THE ENTIRE UNIVERSE to have space enough to store M^d.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Terje Elde)
Subject: Re: "Variable size" hash algorithm?
Date: Wed, 05 Jan 2000 12:45:08 GMT
In article <84qrmt$k5u$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>> A quick online search for it reveals some bibliographic
>> references, and some mostly unannotated source code...
>> However, the source I found seems to imply that the
>> output hash size can only be one of the following:
>> 128, 160, 192, 224 or 256 bytes. I'll have to dig
>> deeper to see whether that can actually be generalized
>> to larger values -- perhaps it's only a limitation of
>> the memory available in the implementation I found.
>
>That's all the different sizes of hashes it will produce. The algorithm
>really only creates a 256 bit hash, but uses a simple compression
>technique to create the smaller hashes.
Feel free to flame me for this if I'm way off, but do it in a private email,
no need to punish the rest of the ng for my mistakes :)
I was thinking symmetric ciphers could easily be used as variable lenght
hashes. This has been talked about over and over, and have been discussed in
applied cryptography etc.
What I'm wondering is could this be done easily with a stream cipher? I mean,
basicly, set a key (NULL is you wish the hash to be verifiable by anyone),
then start encrypting, when you've encrypted TARGET_SIZE bits you simply start
over, xoring the new output with the old.
Naturally I'm not suggesting using this, I'm just asking if the idea in itself
is usable, or if I should just forget about it altogether.
Terje Elde
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: RSA encrypt
Date: 5 Jan 2000 12:45:04 +0100
In article <84tsas$7u9$[EMAIL PROTECTED]>,
Michael J. Fromberger <[EMAIL PROTECTED]> wrote:
> In <[EMAIL PROTECTED]> "Brice" <[EMAIL PROTECTED]> writes:
>
>> I have a question about RSA.
>
>> If I was to calculate M^d (M: message, d: secret key) and give it
>> away for the modular step to be done by someone else (say), how easy
>> would it be for that person to find what my secret key is since my
>> public key is available to anyone ?
>
>> What I am doing is M^d=a in one place and then a mod n in another.
>
> Salutations...
>
> For anything other than trivial values of M and d, this is going to be
> intractible. For example, suppose your message is a 1024-bit number,
> and d is (as would commonly be the case) a roughly 1000-bit exponent.
>
> You're just not going to be able to compute M^d in the space and time
> available to you. Modular exponentiation can only be done in a
> reasonable amount of time if you do the modular reductions as you go
> along. You can't leave it 'til the end, except if M and d are very
> small.
If we assume M and d are both 512 bits (a minimum requrement --
512-bit RSA can today be cracked with some effort), then M^d would be
approx 512*(2^512) = 6.8E+156 bits large. If you want to use M and d
wihich each are 1024 bits, then the full M^d would be approx
1024*(2^1024) = 1.8E+311 bits large.
The entire universe contains about 1E+80 atoms. Thus, one would need
to store 1E+77 (512-bit case) or 1E+231 (1024-bit case) in EACH ATOM
OF THE ENTIRE UNIVERSE to have space enough to store M^d.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: RSA encrypt
Date: 5 Jan 2000 12:45:34 +0100
In article <84u1qs$rdd$[EMAIL PROTECTED]>,
Paul Rubin <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, Brice <[EMAIL PROTECTED]> wrote:
>> I have a question about RSA.
>>
>> If I was to calculate M^d (M: message, d: secret key) and give it away for
>> the modular step to be done by someone else (say), how easy would it be for
>> that person to find what my secret key is since my public key is available
>> to anyone ?
>
> Trivial, but why on earth would you want to do that anyway?
> M and d will be about the same size, so if M is 1024 bits (typical),
> then M^d will be about 1 megabit. What type of protocol could that
> be practical in?
The full M^d would be enormously larger than a mere megabit! If we
assume M and d are both 512 bits (a minimum requrement -- 512-bit RSA
can today be cracked with some effort), then M^d would be approx
512*(2^512) 6.8E+156 bits large. If you want to use M and d wihich
each are 1024 bits, then the full M^d would be approx 1024*(2^1024) =
1.8E+311 bits large.
The entire universe contains about 1E+80 atoms. Thus, one would need
to store 1E+77 (512-bit case) or 1E+231 (1024-bit case) in EACH ATOM
OF THE ENTIRE UNIVERSE to have space enough to store M^d.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: "LBMyers" <[EMAIL PROTECTED]>
Subject: Re: How to pronounce "Vigenere"?
Date: Wed, 5 Jan 2000 08:20:24 -0500
>
> As we all know what kind of cipher we're talking about, does
> it matter?
>
> --
> Posted by G4RGA.
>
> Rallies Info: http://website.lineone.net/~nordland
> http://www.netcomuk.co.uk/~amadeus
Not on a news group, but some people have been known to speak to each other
face to face. then it is helpful if words are pronounced in a mutually
understandable manner : ).
------------------------------
From: "LBMyers" <[EMAIL PROTECTED]>
Subject: Re: REQ: Applied Crypto source disc
Date: Wed, 5 Jan 2000 08:26:23 -0500
Jason C. Hartley <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> First off, you suck.
> Secondly, I am so profoundly lazy you have no idea. In a moment of
> clarity, recently, I quit my job after lunch. I would have quit long
> ago, but I was too lazy. So now 40 bucks means a lot of Taco Bell.
> Plus, if you don't pay for something then never use it because you're
> too lazy, you don't feel like you wasted any money. Dontcha love
> that?
>
So basically you are a foul-mouthed, lazy, thief who wants to steal othere
people's work. Have I got it right.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: PKZIP compression security
Date: Wed, 05 Jan 2000 13:39:01 GMT
On 27 Dec 1999 19:34:51 GMT, [EMAIL PROTECTED] (BigJim44) wrote:
>I know it's not exactly PGP but would zipping a text file with PKZIP before
>encipherment significantly increase the security of the link?
>
>Thanx...
>
> [EMAIL PROTECTED]
>
>
In terms of security, zipping first (or other form of compression)
removes some redundancy from the data. This makes it marginally less
easy to attack, although with most forms of strong encryption
available these days, the improvement is probably esoteric.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: RSA encrypt
Date: 5 Jan 2000 14:11:55 GMT
John Enright <[EMAIL PROTECTED]> wrote:
>>Trivial, but why on earth would you want to do that anyway?
>>M and d will be about the same size, so if M is 1024 bits (typical),
>>then M^d will be about 1 megabit. What type of protocol could that
>>be practical in?
>
>Actually, it's a LOT larger than that. ....
<Blush>. A thinkographical error. Oops. Sorry.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: REQ: Applied Crypto source disc
Date: 5 Jan 2000 14:12:54 GMT
LBMyers <[EMAIL PROTECTED]> wrote:
>So basically you are a foul-mouthed, lazy, thief who wants to steal othere
>people's work. Have I got it right.
Um, precisely whose work is being stolen?
I believe these discs are available on some ftp site somewhere, btw.
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: REQ: Applied Crypto source disc
Date: 5 Jan 2000 08:13:49 -0000
[EMAIL PROTECTED] (Keith A Monahan) writes:
> First off, this is not alt.binaries.warez.cryptostuff.
> Secondly, if you are too lazy to work the number of hours to be able
> to afford a $40 item, then you are probably too lazy to use the CD
> anyways. What's it take, a days work perhaps at minimum wage?
I think that everything on that CD is freely redistributable, so
there's no need for the "arbeit mach frei" routine on this occasion.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: cracking Triple DES
Date: 05 Jan 2000 14:39:47 GMT
Yes, it is not practical, someone just asked what it was and I replied. The
"middle" for TDES is either after 1 encrytion or 2. This is treating DES as a
black box.
Don Johnson
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: How to pronounce "Vigenere"?
Date: Wed, 05 Jan 2000 07:57:42 -0700
Reply-To: [EMAIL PROTECTED]
vision air
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Truly random bistream
Date: Wed, 05 Jan 2000 10:06:56 -0600
TohuVohu wrote:
> I don't see why this is impossible. Isn't radioactive decay "random" enough
> for this. I thought one of the fundamentals of quantum behaviour is this
> randomness.
> I sort of new to all this stuff so please explain.
>
> >: I would like to get hold of a truly random bitstream - about 2^24 bits long
> >: should be plenty. Does anyone know if such a thing exists for download ?
> >
> >No such thing is known to exist anywhere on the planet.
> >
> >If anyone were ever foolish enough to puport to offer such a service,
> >it would not be possible to verify whether their material was genuine.
It is possible to produce bitstreams that are arbitrarilally random, but "truly"
random is impossible -- it is like producing the largest integer -- you can always
find a bigger intreger(or a system flaw which induces some potential correlation
that can be corected byv some method), but "truly" random is not an achievable
goal.
------------------------------
From: Paul Zimmermann <[EMAIL PROTECTED]>
Crossposted-To: sci.math.symbolic,sci.math
Subject: New ECM record: up to 60 digits
Date: 05 Jan 2000 17:11:27 +0100
New ECM record: up to 60 digits
===============================
On December 26, 1999, Nik Lygeros and Michel Mizony, two math researchers
from Lyon (France), found a prime factor of 54 digits of a 127-digit
composite number with GMP-ECM, a free implementation of the Elliptic
Curve Method (ECM). According to the table maintained by Richard Brent [1]
this is the largest prime factor ever found by ECM. The previous record was
hold by Conrad Curry with a 53-digit prime found in September 1998.
The number Lygeros and Mizony factored was a cofactor from (6^43-1)^42+1,
more precisely n = b^4-b^2+1 where b = 6^43-1. It was known that
n = 13 * 733 * 7177 * c127
where c127 is a 127-digit composite number. Lygeros and Mizony discovered that
this number factors into c127 = p54 * p73 where
p54 = 484061254276878368125726870789180231995964870094916937
is the factor found. This search was done in a huge factoring project Lygeros
and Mizony started a year ago about generalized Sloane's sequences [2].
Those generalize sequences A003504, A005166 and A005167 from The Encyclopedia
of Integer Sequences [3].
The Elliptic Curve Method was discovered by H. W. Lenstra in 1985.
The lucky curve was of the form b*y^2*z = x^3 + A*x^2*z + x*z^2 with A =
422521645651821797908421565743985252929519231684249666 mod p, and group order
2^3*3^2*13*53*283*337*29077*837283*1164803*3978523*7613819*8939393*13323719.
Very surprisingly, the 54-digit prime was found in step 1 of ECM! The first
limit used was B1=15,000,000. The probability of finding a 54-digit prime in
step 1 with such parameters is about one over three million. Lygeros and
Mizony just did 1300 curves. The lucky curve took 454 seconds to compute on
a 500Mhz Dec Alpha EV6 (21264) from the CDCSP (Center for the Development of
Parallel Scientific Computation).
The program used was version 4a of GMP-ECM [4], a free implementation of the
Elliptic Curve Method based on T. Granlund's GMP multiprecision library [5].
According to [1], GMP-ECM now holds four from the ten largest factors ever
found by ECM. Other main projects using GMP-ECM are the Cunningham project [6]
and the ECMNET client/server [7].
In a recent paper [8], Richard Brent extrapolates the ECM record to be of
D digits at year about 9.3*sqrt(D)+1932.3. This would give a record of D=60
digits at year Y=2004. We strongly believe 60 digits will be reached before,
perhaps already in 2002 or even this year!
[1] ftp://ftp.comlab.ox.ac.uk/pub/Documents/techpapers/Richard.Brent/champs.txt
[2] http://www.desargues.univ-lyon1.fr/home/mizony/premiers.html
[3] http://www.research.att.com/~njas/sequences
[4] http://www.loria.fr/~zimmerma/records/ecmnet.html
[5] http://www.swox.com/gmp/
[6] http://www.cerias.purdue.edu/homes/ssw/cun/index.html
[7] http://www.interlog.com/~tcharron/ecm.html
[8] Some Parallel Algorithms for Integer Factorisation, Euro-Par 99, cf
ftp://ftp.comlab.ox.ac.uk/pub/Documents/techpapers/Richard.Brent/rpb193.dvi.gz
--
Paul Zimmermann
INRIA Lorraine
615 rue du Jardin Botanique
F-54602 Villers-les-Nancy Cedex
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Truly random bistream
Reply-To: [EMAIL PROTECTED]
Date: Wed, 5 Jan 2000 16:15:14 GMT
TohuVohu <[EMAIL PROTECTED]> wrote:
: I don't see why this is impossible. [...]
It /may/ not be impossible. It's just that nobody knows whether it's
possible or not.
: Isn't radioactive decay "random" enough for this.
Perhaps, perhaps not. It depends on your "this" - since the original
poster did not specify an application and instead asked after a "truly"
random bitstream - an entity whose existence some regard in much the same
light as they would a perpetual motion machine.
Even if radioactive decay /were/ perfectly random, there is no known way
of amplifying it to a macroscopic scale while demonstrably avoiding every
possibility of non-random influence from the environment - so whether
radioactivity itself is completely random or not is not very relevant.
Of course for cryptographic protocols, you *can't* possibly trust the
randomness of anything you download from the internet - since your
opponent may be monitoring and/or influencing your download.
: I thought one of the fundamentals of quantum behaviour is this randomness.
That depends on who you talk to. The MWI interpretation of quantum
physics effectively has no randomness in it at all, for example.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Pain is just God's way of hurting you.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Square?
Date: Wed, 05 Jan 2000 10:22:21 -0600
Check here
http://www.esat.kuleuven.ac.be/~rijmen/square/index.html
This is Square's home page. It doesn't mention attacks vs it, but it does
mention who built it.
Andrej Madliak wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi!
>
> Who knows something about the "Square" algorithm, it's
> strenght/weaknesses and attacks against it?
>
> Thanks,
>
> Andrej
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>
> Comment: Quis custodiet ipsos custodes?
>
> iQA/AwUBOHL2fIaZUlJQw2ggEQLlPQCeMD0KhoB2Ia6rbcvESx8MGQ5Cs3kAoJUK
> ovFqDd3nLJKpyO1Z07OkeNUd
> =50qy
> -----END PGP SIGNATURE-----
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Wagner et Al.
Reply-To: [EMAIL PROTECTED]
Date: Wed, 5 Jan 2000 16:38:27 GMT
John E. Kuslich <[EMAIL PROTECTED]> wrote:
: Daniel Roethlisberger wrote:
:> Decent encryption software cares for its sensitive data. It locks memory in
:> which it allocates memory for keys and such, so it doesn't get paged on hard
:> disk. It wipes memory after usage. It also tries not to send it through
:> windows mechanisms like the windows messages.
: No. Total myth. Software under Windows can do absolutely nothing to
: protect itself!
I'd have to agree with Daniel. *Even* when running on an fundamentally
buggered OS like Windows, software can go to great lengths to ensure its
own integrity. Perfection will of course be impossible - but trying
to preserve its integrity is not likely to be a /complete/ waste of time.
: Security by software is total myth. Once resident in memory, any
: software can be made to whistle Dixie or do anything at all by a
: competent machine language programmer. Any executable or dll can be
: loaded and then altered in arbitrary ways to achieve any desired result.
This is one of the reasons systems like Java has security features which
include code signing to verify the integrity of the code to be executed.
: This fact is not widely appreciated because there are so few programmers
: today who understand how Windows works. The models they are normally
: exposed to are abstractions having no physical reality. Once you
: achieve understanding of the machine itself, not the software model of
: the machine, the truth of what I am saying will be apparent.
Windows does indeed appear to be pretty shafted. However, security
software *can* still do things to try to pretect itself. Executing a
search of the system for all existing known trojans upon installation
might help, for example. /Perfect/ security against every possible trojan
will not be practical - but defeating many of them would certainly help.
The encryption software author /may/ regard it as largely the
responsibility of the virus-checker (and other related security
software) to avoid trojans. Defenses against persistent records
on potentially multi-user based systems are another matter, though.
Cleaniung up after yourself and avoiding leaving data on disc in swap
files may be worth consideration.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
People who live in stone houses shouldn't throw glasses.
------------------------------
** 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
******************************
