This is a two part question, if that is OK here. I maintain an application that reads Google data, using a .p12 key file that is downloaded from Google by our customers. One customer for some reason can't make a .p12 file, but has a .json file containing a property called "private_key" that begins with "-----BEGIN PRIVATE KEY-----\n" then has what looks like base64 encoded binary data.
I found this Stackoverflow question: Is it possible to convert JSON private key into PKCS12 format?
I tried to follow the instructions, making a text file that looks like this:
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAg...ctlG0=
-----END PRIVATE KEY-----
(of course, with the full data in place of ...)
But when I execute the command: openssl -rsa -in jsonkey.key I get the error "Could not read private key". Any idea what the problem is here?
Here is the second part of my question. Ideally I would prefer to convert the json key using my own code. In my original application code, basically what I am doing is opening the .p12 file and reading all the binary data into memory, then calling "d2i_PKCS12(&p12_cert, &pkdata2, flen)" where pkdata2 is a pointer to the p12 data. Could I assume that the data from "private_key" could be decoded from base64, and it would be the equivalent to the .p12 binary data?
Related
I have a public and private key that I receive as strings in Go and need to verify that they are valid keys. The default crypto library is deprecated (I tried it, and it doesn't work; I think my format is too new).
I know I have 2 valid keys are
They were recently generated and
They have been validated through other means
So, how does one actually validate GPG keys in Go? Do I need to deconstruct the key myself?
This actually breaks down into a lot of separate questions to understand the overall process.
From what I understand a JWT is just three JSON objects encoded into base64 separately from one another. Then the Base64 strings are separated by periods. This is done purely for "shorter message" purposes?
These include a header, "payload," and signature. The header and payload are 100% available to read by anyone who intercepts them. They are just base64 strings that can be decoded into JSON and read.
Then the MAGIC: The server receives the SIGNATURE, which cannot be decoded. The signature is actually a hash of the header, payload, AND a secret key. So the server takes the header, the payload, and ITS OWN secret key, and makes a hash. If this hash MATCHES the signature that came with the message, the message is trusted. If the signatures DO NOT match, the message is invalid.
My problem with all this? Where are the two separate keys here? It seems that the key used to encrypt the message and the key used to decrypt the message are the same. This is the root of my question - if you answer nothing else, please help with this.
Other than that, I wonder if I understand the process correctly? Also, where is the standard "agreeing on a public key" and then trading "mixtures" of public/private keys occurring here? All I see is the same key being used to encode/decode. But when did the agreement happen? Viewing this in context of .NET and Auth0 btw, but overall q.
Random stuff I watched/read/used if anyone is interested on seeing this q later:
Summary of JWTs: https://scotch.io/tutorials/the-anatomy-of-a-json-web-token
Public-key/Assymetric Cryptography: https://youtu.be/3QnD2c4Xovk
Hashing: http://www.webopedia.com/TERM/H/hashing.html
Base64: http://en.wikipedia.org/wiki/Base64
Firstly, JSON Object Signing and Encryption standards (JOSE) use base64url encoding and not straight base64 encoding, which differs slightly.
JWT header and payload are JSON objects but the signature is not, that's a base64url encoded binary blob
the whole JWT is available to anyone who intercepts it, all 3 parts of it
you're describing a symmetric key algorithm, where sender and receiver use the same shared key; that is just one option for JWTS, another option is to use public/private key pairs for signing/validation/encryption/decryption
As with all crypto, agreement on keys needs to happen out of band.
Then the MAGIC: The server receives the SIGNATURE, which cannot be decoded. The signature is actually a hash of the header, payload, AND
a secret key. So the server takes the header, the payload, and ITS OWN
secret key, and makes a hash. If this hash MATCHES the signature that
came with the message, the message is trusted. If the signatures DO
NOT match, the message is invalid.
There is no magic here. JWT supports four well-known signature and MAC (message authentication code) constructions: HMAC (a symmetric algorithm), and ECDSA, RSASSA-PKCS-v1.5 and RSASSA-PSS (public-key algorithms). Each of these may be used with the SHA-256, SHA-384 or SHA-512 cryptographic digest. See also the table of Cryptographic Algorithms for Digitial Signatures and MACs from RFC 7518 - JSON Web Algorithms (JWA).
My problem with all this? Where are the two separate keys here? It
seems that the key used to encrypt the message and the key used to
decrypt the message are the same. This is the root of my question - if
you answer nothing else, please help with this.
There are not necessarily two separate keys - if a public key algorithms is used, the signature will be created using the server's private key, and verified using the corresponding public key. But if an HMAC algorithm is used, a shared secret key must be used for both signing and verification.
I'm taking a user inputted NSString, converting it to NSData with NSUTF8StringEncoding. I'm then using CCCrypt to encrypt that data using a random salt and IV and a user inputted password.
My question is, how do I convert this encrypted NSData into a format that could be decrypted by a plain text AES decryptor such as http://www.everpassword.com/aes-encryptor?
Furthermore, does CCCrypt automatically add the salt & rounds to the encrypted data? Or do I need to manually add them in some way before the data can be decrypted with access only to the secret password?
Any help on this would be greatly appreciated.
The website you posted uses Gibberish-aes and giberish aes uses an openssl compatible format. CCCrypt will not give you that format by itself, however you don't have to do it yourself. RNCryptor happens to have an OpenSSL format mode RNOpenSSLEncryptor.
So I have implemented salts and IVs, but the decryption is now a bit buggy. Of course, I need both the salt and IV for decryption as well, but the user can't enter that... I need to be able to store both the salt and IV in the encrypted file, then retrieve the salt and IV when the user is decrypting the file. How would I go about doing this? How would I go about storing and retrieving that data?
As Peter said, the initialization vector and the salt for key derivation should be stored together with the encrypted file, in a header or such.
Instead of creating your own ad-hoc file format for encrypted storage, have a look at the OpenPGP message format (as used by both PGP and GnuPG, and maybe other programs). It is specified in RFC 4880. You will likely not have to implement all of it, but grab the portions that you need for your application.
As an added bonus, the user can then use PGP/GPG (with the right options and the password/key) to decrypt the data, if your program should somehow cease to work.
Store them along with the ciphertext. You'll need to come up with a suitable file format in which to do it; a keyed archiver will make it easy.
I'd like to use openssh to sign a file, and then pack
the file
the public key
the signature hash
Into one self-contained file. In a container file like pem. Oh, and I understand that what will be signed and verifiable is the file, not the self-contained thingie.
Yes, I can. All I have to do to is
Sign the file
Put the public key in the file
Put the hash in the file
You can add info like this to all kinds of file types.
Your file can also be an archive itself, in witch case the problem is solved.
To verify the file, first extract (in the proper sense of the term : Read then erase) the hash and the key, then verify.