search

travist / jsencrypt

A zero-dependency Javascript library to perform OpenSSL RSA Encryption, Decryption, and Key Generation.
http://www.travistidwell.com/jsencrypt
Other
6.68k stars 2.02k forks source link

why not privateEncrypt and publicDecrypt #115

Open dyyz1993 opened 6 years ago

amywarble commented 6 years ago

That's how public-private key cryptography works. You always encrypt with the public key, and decrypt with the private key.

typehorror commented 6 years ago

@amyhickman there is no such thing as "how public-private key cryptography works". Both sides exist and have different purpose.

amywarble commented 6 years ago

@debrice

there is no such thing as "how public-private key cryptography works".

What is that supposed to mean? There's no such thing as "how that thing works"?

wat?

https://en.wikipedia.org/wiki/Public-key_cryptography

Both sides exist and have different purpose.

I said what those purposes are.

Spark-NF commented 6 years ago

It is indeed possible to "encrypt" with a private key and "decrypt" with a public key (even those are not the right terms, hence the quotes).

That's called signing/verification.

This library does not support it at the moment however, and there are a few related issues, as well as pull requests open to fix that.

developeranirudhprabhu commented 6 years ago

I'm not sure if signing and verification is what is exactly being asked. It is possible in Java and Python AFAIK to encrypt and decrypt with any key. Even I'm struggling with same requirement where I have been asked to decrypt with public key. However i didnt find any libraries that are supporting this

lvhuat commented 5 years ago

Here is an example to explain why any company encrypt with a private key.

A is a company of setting up a APP to serve. people use accounts registering from A to login onto the APP and get a encrypted data named token within some info of identification. B is a company that supporting some mainly function of the APP. C is the user accessing the APP.

The key point is that B must ensure that C is the really user of A. so B could:

  1. Identify C with token from auth server of A.
  2. Or C is authorized to decrypt the token. If use 2, and A don't trust B completely, So A could give the public key to B and some other partners. after that,B could try to decrypt the token with given public key,if success,the auth done.No need to access to the auth server of A.