I am trying to encrypt with BC and decrypt with pgp 6.5.8 .
The encryption aspect of it works and i am able to decrypt i pgp 6.5.8 . But pgp 6.5.8 complains the signature is bad. Can anyone help me with this ?
Thanks
To save someone possible frustrations in the future I can provide some more details.
When encrypting the file with Bouncy Castle be sure to set the integrity packet to false. Without this PGP6.5.8 might not be able to decrypt the file.
JcePGPDataEncryptorBuilder builder = ...
builder.setWithIntegrityPacket(false);
When signing the file you might have to use V3 signatures, but this depends on the key your signing with. Use the PGPV3SignatureGenerator instead of PGPSignatureGenerator.
The reason why it did not work because I needed to construct the signature using RFC 4880 Version 3 signature, I did it using Version 4.
Related
I'm working with the enccc example, I'm able to encrypt and decrypt with a shared key, so the same key is used for both encryption and decryption. I need to use different keys, one to encrypt (like a public key) and another to decrypt (like a private key). Could someone guide me or tell me where I could read about it? Thanks and regards!
You can use the crypto/rsa package for encrypting using RSA.
I want to create and manage user sessions with AES256 encrypted tokens.
I am using node's crypto library and followed this stackoverflow question.
I am using this to create session token that will be sent to frontend and stored in the backend for verification purpose and the data is stringified JSON.
Here I see two things one is password and other is iv.
so two questions,
Is the iv is safe to sent to frontend (iv + "." + encData)?
How should the password be generated? How about a SHA256 of (e.g. user's password that I store in db at signup)
This way I will be using a different password for each user. Is this approach correct?
P.S. Both of the answers below helped a lot, If you are here, do read all the comments and attached So question and the linked articles.
Let's keep to the question at hand:
Is the iv is safe to sent to frontend (iv + "." + encData)?
Well, yes. The IV may be public knowledge; as long as it is unique and - in the case of CBC mode encryption - random then this is fine. Of course, the IV and encData should be suitably encoded, for instance using hex (as in the linked answer) or base 64. This is not often done as the IV is always 16 bytes for AES, so it is easy to simply prefix the binary IV to the encData instead.
Beware of hackers changing the input; if the dot or colon is removed then you may have just an array of one element and accessing the ciphertext may result in an error or the decryption of empty data.
How should the password be generated? How about a SHA256 of (e.g. user's password that I store in db at signup)
No, you should use a password hash for that; SHA-256 is a cryptographically secure hash but not a password hash such as PBKDF2, bcrypt, scrypt or Argon2. And if you want to store something in the DB, then please do not let that be the AES secret key generated from the password.
This does not in any way invalidate any of the concerns in the answer of TheGreatContini. This is not security advice, just the cryptography related advice you asked for.
You may want AES encryption, but encryption is not what you need! For the security of your application, message integrity is more important than encryption.
Encryption does not generally provide message integrity (see section 7 of Top 10 Developer Crypto Mistakes) unless you specifically use a mode of operation that provides it (such as GCM mode). Therefore, the solution you are designing in inherently wrong. More info in footnote (!) below.
Understand what you need -- message integrity + encryption, or message integrity only. If it is message integrity only, then use HMAC.
Another thing you need to understand is that functions like AES and HMAC do not use passwords, instead they use cryptographic keys. See section 6 of Top 10 Developer Crypto Mistakes.
It is not clear whether your question on IV matters, given that your approach is wrong, but to answer it anyway, the IV does not need to be secret. See section 2 of Top 10 Developer Crypto Mistakes.
I generally agree with the comments above: use JWT the way it was meant to be used rather than trying to build your own solution. JWT has a claim reserved for expiration, so there is no reason not to.
footnote (!): If you want to see how confusion between message integrity and encryption gets abused, you can try this exercise from Pentester Labs (unfortunately it requires a subscription, but it is cheap). Granted that this is for ECB mode, a similar concept can work for CBC mode.
I am not an expert (not even a novice :))) in security certificates and such - thus the question - but I was wondering if one can generate a new certificate by using a known fingerprint? :D (lost my certificate for a google play app and was wondering about this workaround)
Thanks.
This is practically impossible. The fingerprint uses a cryptographic hash like SHA-1 or SHA-256. With current technology it is impossible for a normal user to create the input which results in a specific hash value. It is doable with lots of efforts (i.e. still very very expensive) when MD5 was used for the fingerprint (not common), it might be doable by the NSA for SHA-1 and it is considered impossible to do it today for SHA-256.
Apart from that certificates are commonly not validated by the fingerprint but because a trusted CA has signed this certificate. This signature is part of the certificate so that you would not only need to recreate the certificate but also somehow get a valid signature which is impossible without having the private key of the CA which of course you don't.
I am considering building an API system that uses HMAC. The server and client will have a shared secret, the client will sign the requests, the server will validate, and proceed if all is well. The trouble with this sort of system is that the secret has to be stored in a way where it can be retrieved, such as a database. If someone were to steal the secret, they have the key needed to do basically anything that user is authorized to do.
I was thinking that there must be a more secure alternative. Are there any flaws with using RSA?
Client has the "public" key instead of a shared secret. (The public key must still be kept secret for my use case.)
Client will hash the message with SHA-1 or whatever as normal.
Instead of adding the hash to the message directly, the hash will be encrypted via it's public key, and then sent with the message.
Server has the "private" key (to decrypt messages) but has no knowledge of the "public" key. (This is the part that makes this more secure than the normal approach. If the database is stolen, no keys are stolen that can impersonate a user.)
Server will decrypt the hash and validate the message as normal.
Is there anything wrong with this approach? Are there known implementations of this or something similar?
It depends on the asymmetric cryptosystem you chose:
(EC)Diffie-Hellman: It does not work. Publickey is directly derived from the privatekey via the generator, e.g. [d]G = Q
RSA: Usually people chose fixed publickeys like 0x010001. This is done for efficiency reasons. If you take a large enough, fully random e and derive d from it there is no possibility to calculate p and q given d and N OR e and N. Actually they are pretty equally then and the label private and public don't make much sense anymore. All that relies on a smmyetrical property of RSA. Be sure not to walk into textbook RSA issues. And be sure to ask enough clever people about it, this is just my thoughts on it.
If you base your crypto system on a proof of possession of a secret you need to, well - keep it secret :)
But yes, if you dont need the speed of a symmetric authentication then you can use a assymetric signature. Typically it is done with a signed hash, but you can also use a signed hmac.
The terminology is normally, that you sign with a secret key and validate with the public key (even when the signing operation looks like an encryption).
I know how asymmetric cryptography works. I know there are two keys (one private and one public).
When someone wants to communicate they exchange their public keys encrypt messages with those public keys AND then the respective message could be decrypted ONLY by the user that has the private key.
Now, I'm using Node.js and I need to do something like this...
I need an application that EACH hour reads a database, extracts data and saves it to a file that I need to send to another server.
My problem is that I DON'T WANT that file will be visible to other, I do the transfer using SSH so there is no problem BUT
I must encrypt that file because I'm not the admin of that server SO maybe someone could read it. Unfortunately the admin is the same for both servers.
So my idea is to encrypt the file with a public key, and then only he who has the private key(me) could decrypt it.
I think it is pointless using something like:
var key = 'blablabla'
If I use a public key, there is no problem, all can read it..... it is public indeed. But with this public key, nobody can decrypt the message, so it is
something like one-way encryption.
Now, could someone tell me if I need a signer/verifier to do this job, OR maybe I have to generate two keys (public/private) with openssl and pass those keys to a cipher/dechiper?
I'm looking at crypto modules, but there are no examples....
In general, your idea is right - you encrypt using public key and decrypt using private key of yours. However, practically the procedure is more complex. Random symmetric key is generated and the data is encrypted using that key. Then the public key is used to encrypt the random key. Encrypted key is sent to recipient together with encrypted data. On the other side encrypted key is decrypted using a private key, then the data is decrypted.
You can use OpenPGP keys or X.509 certificates to do the job.
In case of OpenPGP the standard offers encryption and decryption as atomic procedures (on the user level). In case of X.509 certificates you need to use PKCS#7 / CMS.
OpenSSL library offers operations with PKCS#7 / CMS, however when I look at nodeJS API for OpenSSL, that API is very limited and doesn't expose those functions. Maybe you can write your own nodeJS module which will interface with OpenSSL and provide missing functions.
Another alternative is to use OpenPGP keys and node-gpg module. That module uses gnupg to do the actual job, so gnupg must be installed.
Unfortunately I don't see any other suitable libraries in the 3rd-party module list provided in nodeJS wiki.