The point of encrypting with the private key is exactly that it can be decrypted by anyone _with_ the public key. If a message can be decrypted with the public key then that means that only the someone who knows the private key could have encrypted it.
In our example, if you're sure that the only person that knows site X's private key is Site X itself then you can be sure that the message originated from site X. In response to M. Schwarz, with public key encryption schemes know the clear text of really doesn't help very much at cracking the private key. Besides which, the user (presumably) knows what the price of the thing they are buy anyway right? So they know what the cleartext of the message is whether it's sent with the message or not. Although this does bring to my mind a real weakness in my suggestion. Once the user knows the Cypher text for $1 they can just resend the price for whatever they want as $1. A nonce or something similar is therefore required in the cyphertext to prevent from this kind of attack. Certificate Authorities for instance always sign the key's they issue with their private key (or certificate). This signature can then be decrypted with the certificate authority's public key confirming that the certificate was in fact issued by that certificate authority as sent by the website. Do you really think CA's would use such a technique if it allowed people to crack they're private key? That's one of the attractive properties of algorithms like RSA. Knowledge of the algorithm and the public key don't help you find the private key because finding the prime factors of a number is a hard problem and takes a _long_ time... Even knowing the cleartext of a couple of messages doesn't really help. Hamish -----Original Message----- From: Nikola Milutinovic [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 11:31 AM To: Tomcat Users List Subject: Re: Security problem? > > So, what is suggested is that the "shopping cart" server creates the final > > payment report and signs it with it's private key/certificate. The "financial > > transaction" server would verify that *that* is an authentic request from the > > "shopping cart" server. > > Ok, it was signing. This still doesn't mean that it's "encrypted" right? > Just that there's a high-tech version of a "checksum" in a sense? I guess > maybe I don't understand signing. I thought that signed files were > unencrypted, and that the process of "signing" generates a sort of MD5-style > one-way hash and this is verified against the x.509. Is this wrong? Just as Barney Hamish pointed out, with RSA (and I think DSA) keys, you can encrypt/decript both ways. It is just that these two modes of operation have been established as common. And yes, a signed object is not encrypted. What would we encript it with? Our private key? the anyone can decrypt it with our public key, so what's the point? There is a third mode of operation, which is a combination of the two. Say we both have digital certificates and we exchange public parts. Then I can digitally sign a message from me to you, using my private key and encrypt it all with your public key. That message is decryptabel only by you and using my public key, you can verify that the mesage came from me. They used to call it "digital handshake". I believe it is a part of SSL/TLS handshake. > Yeah -- the redirect thing sounds like a very bad idea. Yup. Nix. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
