On 6/7/02 2:23 AM, "Barney Hamish" <[EMAIL PROTECTED]> wrote:
> Public and private keys can both generally be used to encrypt and decrypt.* > With this algorithm it's just as hard to try and crack the key in either > direction. In fact site X encrypting the message with it's private key is > the only way you can be sure that the message originated from site X. > > Hamish > > * This is the case for RSA encryption for instance, one of the most widely > used public key encryption algorithms. RSA takes advantage of the fact that > it's very hard to find the prime factors of very large numbers. The prime > factorisation is the private key and the large number is the public key. > Both can be used to encrypt the data in analogous ways. Did not know that! Good stuff, thanks for the explanation. fillup > > -----Original Message----- > From: Nikola Milutinovic [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 07, 2002 11:14 AM > To: Tomcat Users List > Subject: Re: Security problem? > > >> On 6/7/02 1:54 AM, "Barney Hamish" <[EMAIL PROTECTED]> wrote: >> >>> - the amount of money the user is to pay encrypted with the private key > of >>> site X as a digest. >>> >>> On site Y you recieve both. You decrypt the encrypted amount with site > X's >>> public key. If the clear text amount matches the encrypted amount then > you >>> know the request originates from X and that the user hasn't tampered > with >>> the request. If the amounts differ then you know the user has tampered > with >>> the request and it should be rejected. >> >> Is this backwards? >> >> I thought public keys encrypt and private keys decrypt.. >> >> so site X would need to use site Y's public key to encrypt the amount, and >> site Y would then decrypt it with its private key. Am I wrong? > > I don't know if I have to say this, but... I believe that with X.509 > certificates there are two courses of action: > > encrypt > -------- > A public entity uses the certificate (which is publicly available) to > encrypt an object to the owner of the certificate. Only the owner has the > private part of the certificate with the private key, which can decrypt the > object. > > sign > ---- > The owner of the certificate ca use the private part of certificate/key to > digitally sign the object. All public entities, who have that certificate, > can verify the integrity and authenticity of the object. > > 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. > > I must say that this is a bit ellaborate. I think that Java Servlet/JSP > should serve as a "Web portal" towards the Enterprize application. This > would be a typical case where the application design would benefit from a > real JEE environment. IOW, there would be no redirection, the "shopping > cart" servlet would fire up an Enterprize Java Bean component on the > "financial transaction" server and that EJB would do the work, return the > result to the servlet. There is no "browser leaving the server", one point > of entry. > >> Also, why even send the cleartext version? > > Why not use HTTPS? It is a must in payment web applications. > > Nix. > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
