tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phillip Morelock <>
Subject Re: Security problem?
Date Fri, 07 Jun 2002 09:25:46 GMT
On 6/7/02 2:23 AM, "Barney Hamish" <> 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.


> -----Original Message-----
> From: Nikola Milutinovic []
> 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" <> 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:   <>
> For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message