Cryptography-Digest Digest #807, Volume #8 Tue, 29 Dec 98 00:13:03 EST
Contents:
Re: Session keys in Elliptic Curve (Mr. Tines)
Re: seeking SSH shell account (James J. Lippard)
Re: History of Cryptanalysis (Bruce Schneier)
Re: RSA-Broken!!! (Bruce Schneier)
Re: DS5002FP Secure Micro Crypted Buses (Andy Glew)
Re: symmetric encryption with a user-supplied password
Re: symmetric encryption with a user-supplied password
Re: History of Cryptanalysis (MKinneyJR)
seeking SSH shell account ("jason hathaway")
Re: seeking SSH shell account (James Pate Williams, Jr.)
Opinions on S/MIME (Brad Aisa)
AFAIK (Andy)
Re: RSA-Broken!!! (Bruce Schneier)
Re: ppdd - Encrypted filesystem (incl root filesystem) for Linux - rev (Brad Aisa)
Re: RSA-Broken!!! (Dr. Yongge Wang)
Re: DS5002FP Secure Micro Crypted Buses (Peter Gutmann)
Decoder for Reed-Solomon codes? ([EMAIL PROTECTED])
Re: seeking SSH shell account (James Pate Williams, Jr.)
seeking SSH shell account ("jason hathaway")
----------------------------------------------------------------------------
From: Mr. Tines <[EMAIL PROTECTED]>
Subject: Re: Session keys in Elliptic Curve
Date: 27 Dec 1998 19:00 +0000
###
On 27 Dec 1998 16:34:52 +0100, in <[EMAIL PROTECTED]>
Anonymous <[EMAIL PROTECTED]> wrote.....
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Mr. Tines wrote:
>
> >> Mr. Tines wrote:
> >> >In the simple case of elliptic curve encryption where
> >> >there is a known generator point P, with secret key x,
> >> >and public key P,P*x then key exchange could be
> >> >accomplished by taking random r and transmitting P*r,
> >> >and using (P*x)*r as the session key - so to that extent
> >> >the EC algorithm participates in the key generation.
> >>
> >> So the session key itself is not completely random?
> >
> >A random number (r) times a constant (P*x) is just
> >a re-scaled random number (or given that we're
> >working in a finite arithmetic, a random number over
> >a shuffled range). There's no loss of entropy; the
> >session key P*x*r has as much entropy as the original r.
>
> There is as much entropy as with the original r, however
> the session key is not completely random since it can be
> mathematically reconstructed. Completely random session
> key would be unrecoverable, right?
Taking a trivial example; consider a much smaller
arithmetic, say arithmetic mod 8; where P=3, and
x=5 say. In this case r is a random number 1-7,
with an equal probability of occupying each value.
We have P*x = 7, and for each r, the value of P*x*r
is
r 1 2 3 4 5 6 7
P*x*r 7 6 5 4 3 2 1
While it is fortuitous in this case that the numbers
are reversed, the important point is that each value
appears once - so the resulting key is equiprobably
any of the numbers 1-7, so is just as random as the
original.
The reconstruction of the session key is not from thin
air, but by passing an intermediate value P*r
r 1 2 3 4 5 6 7
P*r 3 6 1 4 7 2 5
again, equiprobably occupying each of the possible values.
> Forgive me for being a bonehead, but could you please
> detail this a bit further? For this approach to work,
> the comstant (P*x) must be something from which the
> x can't be easily determined by knowing P.
That's the trapdoor function in elliptic curve cryptography;
performing the division P*x/P requires one to extract
discrete logarithms in this arithmetic - which is a hard
problem of similar nature to the factorization used for
RSA.
> >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.
>
> Am I correct in understanding that r is the result of
> this process of slicing and concentrating, and altough
> you transmit two packets, the original 256 bits of
> entropy are never used as r, not even when encrypting?
Yes, I would not use the raw 256 bits, but some shuffled
quantity of equivalent entropy that can be computed
by both the two parties without needing to do anything
equivalent to breaking the cryptosystem.
> Then comes to the question, how to generate
> 256 bits of entropy, provided you need to
> generate it transparently and in software?
PGP uses timing intervals between keystrokes; I have
used the low bits of mouse pointer motion and the
content of the message to be encrypted, hashed down[*];
Java's self-proclaimed secure random class uses timing
information between contending threads. Unix systems
may offer an input called /dev/random/, but its quality
will be implementation dependent.
[*] since you need to know the message to deduce the
value used for the key, this doesn't compromise security.
-- PGPfingerprint: BC01 5527 B493 7C9B 3C54 D1B7 248C 08BC --
_______ {pegwit v8 public key =581cbf05be9899262ab4bb6a08470}
/_ __(_)__ ___ ___ {69c10bcfbca894a5bf8d208d001b829d4d0}
/ / / / _ \/ -_|_-< www.geocities.com/SiliconValley/1394
/_/ /_/_//_/\[EMAIL PROTECTED] PGP key on page
### end pegwit v8 signed text
3295301ed3aec343b66c83e0819a71f8f6c57594fe62ecc3a15b4dbf8938
b9613f7f072a193cfcc42318430c2427ca38b528bef636cb6fce9d5e9dab
------------------------------
From: [EMAIL PROTECTED] (James J. Lippard)
Crossposted-To: comp.security.ssh,alt.security
Subject: Re: seeking SSH shell account
Date: 28 Dec 1998 21:58:49 GMT
In article <766cu8$kp9$[EMAIL PROTECTED]>,
James Pate Williams, Jr. <[EMAIL PROTECTED]> wrote:
>"jason hathaway" <[EMAIL PROTECTED]> wrote:
>
>>Also, anyone know of a Windows 95 SSH client that is
>>better than SecureCRT?
>
>I use F-Secure SSH which has RSA authentication. I don't know whether
>is it better than your current SSH client, however.
>
>http://www.datafellows.com/
Most people seem to prefer SecureCRT to F-Secure SSH, in my experience.
--
Jim Lippard [EMAIL PROTECTED]
Frontier GlobalCenter, Phoenix, Arizona
PGP Fingerprint: EE 97 6A 90 9F 33 09 76 DD 53 30 A1 5C 64 F9 D5
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: History of Cryptanalysis
Date: Mon, 28 Dec 1998 23:48:32 GMT
On 28 Dec 1998 20:03:42 +0000, Ian McConnell <[EMAIL PROTECTED]>
wrote:
>Plenty has been written about the cracking of the German and Japanese codes
>during World War II, but there seems to be little information on the
>cryptanalysis that was carried out pre-WW2. I have only found a few oblique
>references to the UK Admiralty's Room 40 that operated until the 1920's.
>
>Does anyone have any information on the early history of cryptanalysis. I
>realize that the early codes would have been primative, but people still
>wanted to crack them.
David Kahn, THE CODEBREAKERS.
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: RSA-Broken!!!
Date: Mon, 28 Dec 1998 23:49:33 GMT
On 28 Dec 1998 20:28:49 GMT, [EMAIL PROTECTED] (STL137) wrote:
>Uh HUH. And you've also done the following, I take it:
>Solved the Riemann conjecture, and did it in an elementary proof.
>Solved Goldbach's conjectures, again with elementary proofs.
>Found a way to unify the four fundamental forces of nature.
>And so on.
Well if you're so smart.... How many licks DOES it take to get to the
center of a Tootsie Pop?
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
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 19:52:22 -0600
Markus Kuhn wrote:
> The small block size of the data bus cipher was the critical feature
> used in this attack.
Q: does this imply that large cipher block sizes are advantageous
for secure processors?
And, is it reasonable to assume that cipher block size is related
to cache line size (aka transfer block size, aka sector size)?
I.e. if we want to build encrypted processors, should we be always
transferring 64 byte cache lines? Or 4K byte cache lines?
(Hmmm.... did the DS5002FP have a cache at all, or was the block
size a typical microcontroller bus width *4?)
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: symmetric encryption with a user-supplied password
Date: 29 Dec 98 01:21:54 GMT
denis bider ([EMAIL PROTECTED]) wrote:
: Well, since the encryption should depend solely on the user's password, it
: follows that the secret key cannot have more entropy than that password.
Note also that one could simply generate 128 random bits, use that as the
key, and keep it on a floppy disk, encrypted with the password. If it is
easier to get at the encrypted file or message than it is to that floppy
disk, then for the case when the adversary does not have access to the
less-secure key file, this increases security.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: symmetric encryption with a user-supplied password
Date: 29 Dec 98 01:15:40 GMT
denis bider ([EMAIL PROTECTED]) wrote:
: Can anybody think of a method for raising the entropy of the password
: without straining the user into remembering kilobyte-long streams of random
: data?
Well, PGP asks, not for a password, but a pass phrase, when performing
conventional encryption. That is one way to make it at least possible for
a user to memorize something with a fair amount of entropy without having
to enter, say, 16 characters that have to include several special
characters.
John Savard
------------------------------
From: [EMAIL PROTECTED] (MKinneyJR)
Subject: Re: History of Cryptanalysis
Date: 29 Dec 1998 03:24:40 GMT
I don't know if this helps but there is a book a little about Room 40. It is
titled THE MAN NAMED INTREPID. Though it is more about spies during WWII, it
talks little about the cryptanalysis done by the British between the two world
wars. Sorry, this is the only book about this that I know of. Hopefully it
will help you.
------------------------------
Subject: seeking SSH shell account
From: "jason hathaway" <[EMAIL PROTECTED]>
Date: 27 Dec 1998 00:49:07 GMT
Crossposted-To:
news.software.nntp,alt.gothic,soc.culture.jewish,uk.test,sybase.public.jconnect,comp.security.ssh,alt.security
"BICUSPID" BARRY BOUWSMA BORINGLY BITES BIG BAD BRITISH BISEXUAL BACKSTREET BULLDOGS
!!!
------------------------------
Subject: Re: seeking SSH shell account
From: [EMAIL PROTECTED] (James Pate Williams, Jr.)
Date: 27 Dec 1998 00:49:01 GMT
Crossposted-To:
news.software.nntp,alt.gothic,soc.culture.jewish,uk.test,sybase.public.jconnect,comp.security.ssh,alt.security
"BICUSPID" BARRY BOUWSMA BORINGLY BITES BIG BAD BRITISH BISEXUAL BACKSTREET BULLDOGS
!!!
------------------------------
From: Brad Aisa <[EMAIL PROTECTED]>
Subject: Opinions on S/MIME
Date: Mon, 28 Dec 1998 22:59:07 -0500
This is a cryptographically signed message in MIME format.
==============ms9CAD64021B7DA3FE9B60DF9C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hello,
I am interested in opinions on the S/MIME system for email/usenet
authentication and (email) encryption.
Also, is it typical for S/MIME signatures to be invalidated when a
message is passed through an automoderation bot onto a mailing list or
moderated newsgroup? Does PGP suffer from this problem?
thanks
--
Brad Aisa
[EMAIL PROTECTED]
S/MIME signed using freemail ID from www.thawte.com
"Laissez faire."
==============ms9CAD64021B7DA3FE9B60DF9C
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
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk4MTIyOTAzNTkwN1owIwYJKoZIhvcNAQkEMRYE
FC+PZHjMEWZur2lo0RnHzp1q8WZHMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G
CSqGSIb3DQEBAQUABIGAZ3jIO4tCa90COtfDIaHCQlmOAz9UaWzhUENsTrmCQdc4wgqmaL0t
63b2U3kxKAjnLe0YJ1saKUpUozf8ksYkP6RBKaZKf2kYQjAJo7znbueISLyWLRaR33xz0nYI
C1TdP+WMnOJ0Xruy+vPYuCU7diVNcp/ZKWvUVljFkPA5rqA=
==============ms9CAD64021B7DA3FE9B60DF9C==
------------------------------
From: Andy <[EMAIL PROTECTED]>
Subject: AFAIK
Date: Tue, 29 Dec 1998 15:00:49 +1000
Reply-To: [EMAIL PROTECTED]
I've seen "AFAIK" twice this week in sci.crypt
Anyone care to say what it stands for?
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: RSA-Broken!!!
Date: Tue, 29 Dec 1998 03:30:49 GMT
On 29 Dec 1998 01:24:02 GMT, Michael J. Fromberger
<[EMAIL PROTECTED]> wrote:
>>Well if you're so smart.... How many licks DOES it take to get to
>>the center of a Tootsie Pop?
>
>See W. O. Owl's seminal paper on this subject, "Three Licks: Getting
>to the Centre of the Tootsie Pop Controversy" in Journal of
>Idisyncratic Cryptanalysis, v.II #5, Feb. 1992, pp. 324-335.
But he missed the meet-in the-middle attack.
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: Brad Aisa <[EMAIL PROTECTED]>
Subject: Re: ppdd - Encrypted filesystem (incl root filesystem) for Linux - rev
Date: Mon, 28 Dec 1998 23:11:54 -0500
This is a cryptographically signed message in MIME format.
==============ms0CE37EAC0EAA0E18CED04373
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"Alexander Majarek, Sascha, SAM" wrote:
>
> Has anybody considered building something like this (ie root filesystem
> encryption) for Win X (95/98/NT) systems ???
>
> ... sounds GREAT!
RSA sells something called SecurPC that supposedly has this and more.
Windows 2000 (aka NT 5.0) NTFS has a new encryption capability. How
strong/secure it is, I don't know -- but it does use a key escrow or
multi-key system (sysadmin escrow) to insure that the data does not
depend upon a single key.
--
Brad Aisa
[EMAIL PROTECTED]
S/MIME signed using freemail ID from www.thawte.com
"Laissez faire."
==============ms0CE37EAC0EAA0E18CED04373
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
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk4MTIyOTA0MTE1NFowIwYJKoZIhvcNAQkEMRYE
FKqbRoKivvsb0RvuE3V71YE0DDv8MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G
CSqGSIb3DQEBAQUABIGATEFMWy0FAPPyA25WvYxDyoEfpiAy1TLbVlunYo+Lsxnjxg2GpIlb
TapH5bvykOyhdE8aLZnlYYENYNjtvasykl3lGKTvQPBUpjfK6wWahZBfy7+aZ2PxcWqf0vu4
a7aUeyegCTKUcMXPaxqAa0nZ2upG71aY9tHZdxCMk9ck6h4=
==============ms0CE37EAC0EAA0E18CED04373==
------------------------------
From: [EMAIL PROTECTED] (Dr. Yongge Wang)
Subject: Re: RSA-Broken!!!
Date: 29 Dec 1998 03:39:54 GMT
[EMAIL PROTECTED] wrote:
: Hello all,
: It is vary easy to find private key knowing
: correspondent public one.
: To find a private key only one message, which
: is not equal 0 or 1, should be attacked.
: For more details please refer to
: www.online.de/home/aernst/rsa.html
Today I have some time to have a look at
silly things:) (generally, I never check such
kind of things:-))
>From your page, it seems that you have not graduated
from high school (or your German equivalent: Arbitur).
Since any one who have finished high school mathematics
will not make the mistakes you made in your "proof".
Good luck!
--
======================================================.
Yongge Wang | |
Dept. of EE & CS | |
Univ. of Wisconsin--Milwaukee | |
P.O.Box 784 |Yongge Wang |
Milwaukee, WI 53201 |2545 N.Frederick Ave. |
|Apt. 104 |
Tel: (414)229-5731 |Milwaukee, WI 53211 |
Fax: (414)229-2769 | |
[EMAIL PROTECTED] |Tel: (414)3324794 |
http://www.cs.uwm.edu/~wang |Fax: (414)3324794 |
======================================================'
------------------------------
From: [EMAIL PROTECTED] (Peter Gutmann)
Crossposted-To:
alt.security,alt.technology.smartcards,comp.arch.embedded,comp.arch,comp.security.misc
Subject: Re: DS5002FP Secure Micro Crypted Buses
Date: 29 Dec 1998 04:27:45 GMT
Andy Glew <[EMAIL PROTECTED]> writes:
>Markus Kuhn wrote:
>> The small block size of the data bus cipher was the critical feature
>> used in this attack.
>Q: does this imply that large cipher block sizes are advantageous
>for secure processors?
>And, is it reasonable to assume that cipher block size is related
>to cache line size (aka transfer block size, aka sector size)?
>I.e. if we want to build encrypted processors, should we be always
>transferring 64 byte cache lines? Or 4K byte cache lines?
>(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.
Peter.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.dsp,sci.math
Subject: Decoder for Reed-Solomon codes?
Date: Tue, 29 Dec 1998 04:00:52 GMT
I'm trying to implement a decoder for "Reed-Solomon" codes.
I checked out the ECC codes page, and found a few encoders/decoders,
but they all are designed for codes based on GF(2^m), m usually being
something in the range 6..16.
Unfortunately, my problem requires me to decode for codes built around
GF(929).... any ideas? I'm stumped. And my math ain't what it used to
be.... not that aceing Calc 101 would help!!
Appreciate any pointers to freely accessible C code...
--
don't believe anything below this line.... ;-)
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
Subject: Re: seeking SSH shell account
From: [EMAIL PROTECTED] (James Pate Williams, Jr.)
Date: 27 Dec 1998 01:59:13 GMT
Crossposted-To:
news.software.nntp,alt.gothic,soc.culture.jewish,uk.test,sybase.public.jconnect,comp.security.ssh,alt.security
"BICUSPID" BARRY BOUWSMA BORINGLY BITES BIG BAD BRITISH BISEXUAL BACKSTREET BULLDOGS
!!!
------------------------------
Subject: seeking SSH shell account
From: "jason hathaway" <[EMAIL PROTECTED]>
Date: 27 Dec 1998 01:59:19 GMT
Crossposted-To:
news.software.nntp,alt.gothic,soc.culture.jewish,uk.test,sybase.public.jconnect,comp.security.ssh,alt.security
"BICUSPID" BARRY BOUWSMA BORINGLY BITES BIG BAD BRITISH BISEXUAL BACKSTREET BULLDOGS
!!!
------------------------------
** 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
******************************
