Cryptography-Digest Digest #808, Volume #8 Tue, 29 Dec 98 07:13:03 EST
Contents:
Re: MD5 -> Blowfish question... (Paul Rubin)
Re: DS5002FP Secure Micro Crypted Buses (Andy Glew)
Re: AFAIK ("Steve Sampson")
Re: ppdd - Encrypted filesystem (incl root filesystem) for Linux - rev (Brad Aisa)
File Locker: The 2 Minute Crack (JPeschel)
Re: RSA-Broken (David Hamilton)
Re: On leaving the 56-bit key length limitation (David A Molnar)
Re: On leaving the 56-bit key length limitation (Mok-Kong Shen)
Why hash random data? ("denis bider")
Re: On leaving the 56-bit key length limitation (wtshaw)
Re: Common Modulus Attack on RSA (Harpy-34)
Re: On leaving the 56-bit key length limitation (Harpy-34)
Re: RSA-Broken!!! (Lauri Pirttiaho)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: MD5 -> Blowfish question...
Date: Tue, 29 Dec 1998 05:27:48 GMT
In article <[EMAIL PROTECTED]>,
LessThanZero <[EMAIL PROTECTED]> wrote:
>Hi,
>
>Forgive my lack of knowledge about cryptography but I do have a
>question. I'm using MD5 to generate a 128 bit user key for a Blowfish
>encryption program I've written. What I would like to do is expand this
>beyond 128, to 256 or perhaps 384. Is there a good way to do this?
>What if I did something like: Generate the first 128 bit key, used the
>altered initialization constants along with the original string to
>generate the second 128 bit key and then concatenate them together is
>some fashion to create the 256 bit key. If this sounds less than
>"reasonable", then I must point you back to my first sentence. Any help
>would be appreciated, and I thank you in advance.
Blowfish's key initialization routine does the expansion automatically.
Just use the 128 bit key.
------------------------------
From: Andy Glew <[EMAIL PROTECTED]>
Crossposted-To:
alt.security,alt.technology.smartcards,comp.arch.embedded,comp.arch,comp.security.misc
Subject: Re: DS5002FP Secure Micro Crypted Buses
Date: Mon, 28 Dec 1998 23:25:31 -0600
Peter Gutmann wrote:
> >(Hmmm.... did the DS5002FP have a cache at all, or was the block
> >size a typical microcontroller bus width *4?)
>
> No cache. I asked a Dallas engineer about this some time ago since a cache
> would really screw up executed-instruction analyses, but it was felt that the
> cost/overhead involved in adding one didn't make it worthwhile.
It seems to me that a cache might make such a processor considerably (????)
more secure.
------------------------------
From: "Steve Sampson" <[EMAIL PROTECTED]>
Subject: Re: AFAIK
Date: Mon, 28 Dec 1998 23:11:40 -0600
It's a form of shorthand that makes no sense since USENET
moved away from 1200 baud modems and UUCP.
AFAIK "as far as I know"
BTW "by the way"
KMA "kiss my a**"
NSA "not sure amigo"
CIA "crank is alright"
FBI "fooled by intoxication"
BATF "the only good Davidian, is a dead Davidian"
etc, etc
Andy wrote in message <[EMAIL PROTECTED]>...
>I've seen "AFAIK" twice this week in sci.crypt
>Anyone care to say what it stands for?
------------------------------
From: Brad Aisa <[EMAIL PROTECTED]>
Subject: Re: ppdd - Encrypted filesystem (incl root filesystem) for Linux - rev
Date: Mon, 28 Dec 1998 23:25:22 -0500
This is a cryptographically signed message in MIME format.
==============ms8DE04755C7338F31B590F9C8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Allan Latham wrote:
> ppdd is an advanced encrypted file system for i386 Linux.
>[etc.]
I am quite interested in ppdd, and have downloaded it and read the
instructions. I decided not to try it though, without finding out a bit
more about it.
My biggest concern is that I will start using it, but that support for
it will not be maintained in newer versions of Linux. I have some other
questions as well...
What exactly does it patch?
What steps are taken to prevent key snooping by an unfriendly program?
Are any steps taken to prevent cleartext from being swapped to a
swapfile?
What are the encryption units? (one sector? etc.)
Does it have to encrypt/decrypt an entire file, or does it strictly work
on blocks?
I have a suggestion -- you might consider providing a more detailed FAQ
or HOWTO, since if someone wants to use a cryptographic file system,
they are likely to want to many answers and to understand the details of
the system.
Best wishes with your project.
--
Brad Aisa
[EMAIL PROTECTED]
S/MIME signed using freemail ID from www.thawte.com
"Laissez faire."
==============ms8DE04755C7338F31B590F9C8
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIIWQYJKoZIhvcNAQcCoIIISjCCCEYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BgYwggLFMIICLqADAgECAgJc1zANBgkqhkiG9w0BAQQFADCBuTELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRo
YXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAx
Nzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5
OC45LjE2MB4XDTk4MTIyNTIyNDk0M1oXDTk5MTIyNTIyNDk0M1owQDEfMB0GA1UEAxMWVGhh
d3RlIEZyZWVtYWlsIE1lbWJlcjEdMBsGCSqGSIb3DQEJARYOYmFpc2FAaXN0YXIuY2EwgZ8w
DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALALier07xXR24pdrjirnceHsJyUOXwz/FUSMvJq
2rlWW8axn95Q/TQxP6g23b8vnWWmwJaF5Z9tDoXkHvwcdn/QEADlTSLZA59S9/huPjT5Busm
9yJNbSScatnmlSN+9yG+OSoTUzxjm+X1il0LkxQHVmJrLjh0etMfO5xs8MRLAgMBAAGjVDBS
MBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAfBgNV
HSMEGDAWgBT+PmCca4wPsNgzxsrGHliwcTi14DANBgkqhkiG9w0BAQQFAAOBgQAcN95/wDDZ
vp2s5SA4GEw7zPwJKKEJbmJj3SH0dzXgHUbpinujkcrJ9bnJCBQ+EHDxW1gIRkpJT5rV9Azp
S5zXWUY0WPbjl564TjoyIFjefGKu6+GWQZ6jQ7DL9DNyeocSFjYCCyqFypAEcZiRL0x6HzfF
gSIIj5+9dEu+Xz0yWjCCAzkwggKioAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV
BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj
ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG
CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05ODA5MTYxNzU1
MzRaFw0wMDA5MTUxNzU1MzRaMIG5MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx
KTAnBgNVBAsTIFRoYXd0ZSBQRiBSU0EgSUsgMTk5OC45LjE2IDE3OjU1MTYwNAYDVQQDEy1U
aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgUlNBIElzc3VlciAxOTk4LjkuMTYwgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAMSl5dTU0F8IAu4HIX0kv6trjh7rIAcCFYRrj9CTJB8bne5o
srksT+mTZxcQFx6h+UNBI7kwqnaXu/Pn/YHAtTGL9qZQJlTylSjrGaQelx6w4ribwQSaMtA8
CWxP5DVP8Ha/ABMDT0UIYPP8tNCQAYoSyZy6f1LqKpM1Njw85DUvAgMBAAGjNzA1MBIGA1Ud
EwEB/wQIMAYBAf8CAQAwHwYDVR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZI
hvcNAQEEBQADgYEALMeCHwFDPgeP7mlcqWSC+MCWrZMry5tQ10CagcK6pnadPJVA3FXB4VWC
easKKabVDOFXKD6P+bvV3w2TWKpbLYuPM+TdWBU1dnIVKb1C9FqSC3dfnSfbmi1OG4IGjtKN
VruV3tsMZQXelZ4C3VMXvr78a8MaInoUK2G9wp9eeloxggIbMIICFwIBATCBwDCBuTELMAkG
A1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUx
GjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElL
IDE5OTguOS4xNiAxNzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJT
QSBJc3N1ZXIgMTk5OC45LjE2AgJc1zAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkq
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk4MTIyOTA0MjUyMlowIwYJKoZIhvcNAQkEMRYE
FAM1q/31m+S9KRy1ysjb6zxG9i28MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G
CSqGSIb3DQEBAQUABIGAYU2wQvQc75HqyPe5HwomeUifex92D/PnLBhu94JMo55UttUZZ6++
wsXYaZ7r+A2nTGMBFFFBiIJTu9zF6pkcnroNnRAtYXQV6NuLrVb5sk6iuI4Ddzb5EFvwmnOn
cUaYm1jpa88h55OO/HmW5SWtm7Ohi2f6wtyYPG5EuQzZluk=
==============ms8DE04755C7338F31B590F9C8==
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: File Locker: The 2 Minute Crack
Date: 29 Dec 1998 06:33:34 GMT
Casimir recently sent me his essay, "The Cracking of File Locker."
The crack, he estimates, takes around two minutes. A late, but
nice little Christmas present -- it's now on my web site.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (David Hamilton)
Crossposted-To:
alt.privacy,alt.security,alt.security.pgp,comp.security.pgp.discuss,talk.politics.crypto
Subject: Re: RSA-Broken
Date: Mon, 28 Dec 1998 22:49:39 GMT
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
>It is vary easy to find private key knowing
>correspondent public one.
Just over 2 weeks ago, I challenged you to prove that your claim was true.
The challenge was posted to alt.privacy, alt.security, alt.security.pgp,
comp.security.pgp.discuss and sci.crypt with a message id of
<[EMAIL PROTECTED]>. You declined the challenge.
I ask you again; will you accept my challenge? If you don't, I imagine that
everyone will assume that you are being silly and lying.
David Hamilton. Only I give the right to read what I write and PGP allows me
to make that choice. Use PGP now.
I have revoked 2048 bit RSA key ID 0x40F703B9. Please do not use. Do use:-
2048bit rsa ID=0xFA412179 Fp=08DE A9CB D8D8 B282 FA14 58F6 69CE D32D
4096bit dh ID=0xA07AEA5E Fp=28BA 9E4C CA47 09C3 7B8A CE14 36F3 3560 A07A EA5E
Both keys dated 1998/04/08 with sole UserID=<[EMAIL PROTECTED]>
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: Signed with RSA 2048 bit key
iQEVAwUBNogJyco1RmX6QSF5AQFlCggAoei82ZJp2IQkKR8xO9GLg70ZsuBzSbnc
51fAbSIO3LOcPvzLlL1QyafTAqNgaCl72o0NZ7RokoHoGlpBJL3m4b4MZBeIqfoK
7V/hb0vFJtGQcjvIiEF4E9tGgR8oIUlwHWDpsqDjxV4WjML/TvCOOYuPCCZsShkK
XU6Wobh64vKrpeX3vHKUgVQdhLZa6vWX2Bo5D1IDpWOXZs9x6JME3/g9+lyl537O
qlFyWbm+yQZt8XLphJJT9SZlpDOWCipOwiaO/B27CMDw5YvsbCS9PlyzrKUoPvWD
6wQo9RMCw36zd6aZ0J2E28cGQGn2vcxZRTLrO4G9pg2wcxGw8s32qA==
=63IV
=====END PGP SIGNATURE=====
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: On leaving the 56-bit key length limitation
Date: 29 Dec 1998 08:50:01 GMT
[EMAIL PROTECTED] wrote:
[much snippage]
[only thing I can say now from first bit :]
Could you recommend a good treatment of the unicity distance? Are
Shannon's papers the best place to start ?
Right now I think of unicity distance as a measure of the number of
encryptions which may be performed by a particular key and method before
there are more ciphertexts than possible encryptions. In other words, a
concept related to hash collisions; after so many encryptions, there must
emerge some structure that differentiates the output from a one-time-pad.
Although now, looking at the _Handbook_, I think I have it backwards;
should be thinking about the choices for key instead. or both.
Would such a system be on the lines of probabilistic systems, except that
all possible decryptions "look valid" ? The Rabin public-key scheme comes
to mind, with the four possible decryptions per unit. Except I don't think
it passes the "computationally unbounded" adversary test, since it's
equivalent to factoring.
[much snipping]
[create multiple perfectly "valid" but not true decryptions]
> -- which the user's system can choose based on some trusted
> information provided out-of-band.
^^^^^^^^^^^^
What kinds of systems would use such information without turning it into a
secret key ? or is the point to reduce key exchange to a single larger,
out of band transfer instead of doing all these in band, policeable
exchanges ? does it make sense to ask how large such information would
need to be, or do we need designs first?
Please feel free to give pointers to designs or lit - this sounds
intriguing, but I think I'm missing the point. :\
Thanks,
-David Molnar
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On leaving the 56-bit key length limitation
Date: Tue, 29 Dec 1998 09:54:37 +0100
wtshaw wrote:
> As a result of my studies of somewhat deficient ciphers I sometimes
> implement with others, the obvious is that frequent key changes, working
> within a unicity distance, can make them quite practical.
A valuable remark. I missed such stuffs in the textbooks.
M. K. Shen
------------------------------
From: "denis bider" <[EMAIL PROTECTED]>
Subject: Why hash random data?
Date: Tue, 29 Dec 1998 06:15:45 GMT
>> With 160 bit elliptic curve key, if you want a 256 bit
>> session key with enough randomness,
>
>What I would do would be to generate 256 bits of
>entropy, slice into two 128-bit halves, expand each
>to 160 bits using SHA-1 or RIPEM, and transmitting two
>packets, P*r1 and P*r2. Then concentrate the entropy
>down again by using MD5(P*x*r1)+MD5(P*x*r2) (where +
>denotes concatentaion of bit-streams, and MD5 denotes
>an agreed 128-bit hash) as the 256-bit session key.
Question:
If I had a true random number generator and I wanted to generate a secret
key, would it still make any sense to use the digest function? I mean, if I
have a true RNG, the bits are already as random as they can get, I can't
make them any more random by running them through the hash.
(Or, to rephrase the question: are there any other reasons to use a digest
other than to prevent someone who knows the secret key from knowing the
PRNG's internal state?)
denis
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: On leaving the 56-bit key length limitation
Date: Tue, 29 Dec 1998 00:57:17 -0600
In article <769jjn$p6e$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> 6. The final word on cryptographic strength is thus not to be found
> in enforced export controls for key length. It is to be found in our
> own drawing boards in terms of a system's "unicity distance" and its
> derived design issues, which is feasible to deal with and lies in our
> hands.
You say something important, but serves to further minimize the meaning of
keylength as it has been thrown around. In short, keylength is not much
of an absolute cross-algorithm measure of much of anything, certainly not
cryptological strength. It matters more what the actual algorithm is and
if it is crackable without brute forcing the keys. Some do not exhibit a
unicity distance at all, which puts them above those that do. The better
ciphers will also have a huge keyspace which twarts knowing where to start
to search it.
>
> 7. To reach the heart of the matter, one must devise ways to thwart
> automatic surveillance decoding -- which is additional from only
> making it harder or theoretically-impossible to decipher the
> messages, as dealt with by TSCSs. The objective here is to make
> decryption either ambiguous or ambiguously related to the key, even
> if sucessful (say, by collusion, forced escrow, etc.). So, the
> attacker would have difficulties to detect that a key does NOT work,
> that it DOES work, and what the decrypted message is, from a possible
> list of choices.
This is characteristic of some ciphers, but they tend to have a bigger
number keylength than 56 bits. And, the block size can be large enough to
slow a search down to a crawl.
....
>
>
> To close, in order to extract the full benefit from such approach to
> security as commented in the seven items above, I believe that one
> must first revisit the concept of "unicity distance" -- since it is
> usually regarded more as a "proof-of-concept" definition than a
> practical tool. Which is IMO due to a series of unfortunate
> historical facts -- beginning with the name, since it is not a
> "distance" (i.e., it is not a metric function that provides
> distance).
I agree. It was based on a limited set of strength deficient algorithms,
without insight into the spectrum of them we have today. Still, many are
mislead into thinking that unicity distance is something more than just a
measure that can be applied to many weaker ciphers.
>
> BTW, on leaving the 56-bit key length limitation we may well bid
> farewell to security systems which do not take into account the
> message's statistics and perfunctorily pad bits -- which is a funny
> flaw, since the attackers of such systems always tend to do
> otherwise.
>
Those who ignore the past are bound to have it what it holds bite them on
the foot, or elsewhere. Certain features incorporated into many ciphers
are misguided, if not the product of basic ignorance, while others are
indeed good; racing stripes painted on an elephant will not increase its
agility.
As a result of my studies of somewhat deficient ciphers I sometimes
implement with others, the obvious is that frequent key changes, working
within a unicity distance, can make them quite practical.
However, it would be premature to accept a 56 bit limit imposed by a
collection of dunderheads. Next, they would try to legislate the freezing
point of water so that winters will not be so severe.
--
New Year's Resolution: Strive to be accurate, even if it means telling a lie or
misrepresenting the whole truth; after all, this is how Congress does it.
------------------------------
From: Harpy-34 <[EMAIL PROTECTED]>
Subject: Re: Common Modulus Attack on RSA
Date: Tue, 29 Dec 1998 03:20:18 -1000
Max wrote:
> >>Let's say I'm part of a network that was naive enough to issue a common
> >>modulus to all of its users. How could a malicious user, knowing his own
> >>encryption/decryption key pair (e,d) factor the modulus n in an efficient
> >>manner such that he could then compute the decryption (private) keys for
> all
> >>other users of the network?
> >>
>
> <snip>
>
> > o Calculate d such that de = 1 mod phi(n) [Here's where knowing the
> > factorization of n is used; phi(n)=(p-1)(q-1) if n=pq; but note that
> > all we _really_ need is phi(n).]; i.e. de-1 = k*phi(n) for some k.
> >
> >Well, you know _your_ d and e, so you can calculate de-1 = k*phi(n), and
> >learn k*phi(n) (but you don't yet know what k is).
>
> OK, but what if all the user knows is n (the modulus), not phi(n) [which is
> (p-1)(q-1)]? What I'm really wondering is how someone factors n, given only
> an e,d pair and the modulus n.
You don't factor n if it is too big. However, if there is a common
modulus, and there is a small e (e=3), and there is a common message sent
to several people with the common modulus, and if the RSA PKC is
implemented in a naive way, the the following post from "deja news" may
be of interest to you:
Re: RSA making e = 0x10001
Author: (Bryan G. Olson; CMSC (G))
Email: [EMAIL PROTECTED]
Date: 1998/10/23
Forums: sci.crypt
more headers
Michael Scott ([EMAIL PROTECTED]) wrote:
: Easier to illustrate for e=3. If I know m^3 mod n1, m^3 mod n2, m^3 mod
n3,
: and m^3 mod n4, for the four public keys n1, n2, n3 and n4, then the
integer
: m^3 (not mod anything) can be found as that unique integer less than
: n1.n2.n3.n4 that satisfies the above congruences using CRT. And knowing
m^3,
: a perfect cube, it is trivial to find m. Clearly m^3 is less than
: n1.n2.n3.n4 if all are 1024 (or whatever) bits in length.
Just an arguably interesting point about this attack where e=3:
As noted elsewhere the standard padding avoids this and other
problems, but lets suppose we're using pure RSA and sending
messages of a length of many blocks. Then not only does this
attack work (given the identical messages), but it recovers
the plaintext _faster_ than the does the RSA decryption
algorithm using the private key.
--Bryan
------------------------------
From: Harpy-34 <[EMAIL PROTECTED]>
Subject: Re: On leaving the 56-bit key length limitation
Date: Tue, 29 Dec 1998 03:30:37 -1000
David A Molnar wrote:
>
> [EMAIL PROTECTED] wrote:
>
> [much snippage]
> [only thing I can say now from first bit :]
>
> Could you recommend a good treatment of the unicity distance? Are
> Shannon's papers the best place to start ?
>
> Right now I think of unicity distance as a measure of the number of
> encryptions which may be performed by a particular key and method before
> there are more ciphertexts than possible encryptions. In other words, a
> concept related to hash collisions; after so many encryptions, there must
> emerge some structure that differentiates the output from a one-time-pad.
>
> Although now, looking at the _Handbook_, I think I have it backwards;
> should be thinking about the choices for key instead. or both.
>
> Would such a system be on the lines of probabilistic systems, except that
> all possible decryptions "look valid" ? The Rabin public-key scheme comes
> to mind, with the four possible decryptions per unit. Except I don't think
> it passes the "computationally unbounded" adversary test, since it's
> equivalent to factoring.
>
> [much snipping]
> [create multiple perfectly "valid" but not true decryptions]
> > -- which the user's system can choose based on some trusted
> > information provided out-of-band.
> ^^^^^^^^^^^^
>
> What kinds of systems would use such information without turning it into a
> secret key ? or is the point to reduce key exchange to a single larger,
> out of band transfer instead of doing all these in band, policeable
> exchanges ? does it make sense to ask how large such information would
> need to be, or do we need designs first?
>
> Please feel free to give pointers to designs or lit - this sounds
> intriguing, but I think I'm missing the point. :\
>
> Thanks,
> -David Molnar
In Eurocrypt '97 Advances in Cryptology, Springer Lecture Notes In
Computer Science, page 199 you will find out about "spoiling knowledge"
which is sent as "side information". The paper is called "Smooth Entropy
and Renyi Entropy" by Christian Cachin of ETH Zurich.
I do not pretend to understand it completely, but "entropy smoothing is
the process of converting an arbitrary random source into a source with
smaller alphabet and almost uniform distribution". Privacy Amplification
is discussed and you can read Bennett's paper in IEEE Trans Info Theory
vol 41 page 1915 Nov. 1995 in some libraries.
------------------------------
From: [EMAIL PROTECTED] (Lauri Pirttiaho)
Subject: Re: RSA-Broken!!!
Date: 29 Dec 1998 10:38:23 GMT
John Bailey ([EMAIL PROTECTED]) wrote:
> On Mon, 28 Dec 1998 12:56:11 GMT, [EMAIL PROTECTED] wrote:
> >For more details please refer to
> >www.online.de/home/aernst/rsa.html
> Its more like
> http://www.online.de/home/aernst/RSA.html
> John
But of course! No-one ever implied it were impossible to break the RSA
by the brute force as explained on the page quoted above. The question
is, is it feasible? The fact is that it is not in the case the modulus
is large enough. Not even if you had much faster exponentiation than
the "square and multiply" or whatever. You simply run out of time in
finding either the full permutation (mapped by p->p^e mod n) since
on the average you have to go through n/2 exponentiations, or finding
the decryption exponent (number of trials comparable).
RSA was never intended to be used with primes in the range
enumerateable by home computers or computers of any conventional kind.
Computational security is not a question of unbrekability of the
algorithm but of the effort needed to do so.
Happy New Year!
-- Lauri
---
<a href="http://www.ee.oulu.fi/~lapi/">For more info.</a>
------------------------------
** 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
******************************
