Any hardware crypto wallet supports signing a transaction without the private key leaving the hardware, so theoretically it should be possible to sign a CSR as well. Is this true? If so, how can I do that?
PS I am also wondering if this is a good way to store the private key of a root CA offline, and maybe also splitting the private key into a couple of hardware wallets, say any 2 of 3 keys can recover the private key.
Related
I want to sell some of my collectable items that I have been collecting over the years. But I don't want to just sell it, I want to add a QR code to the item (back of the painting, on the deck of cards etc.) and have that link to a website that can verify the item is the real thing.
I was thinking of using pgp-keys (public/private) to verify the item.
Is there already a way to do this or would I have to write something to decrypt the private key for validation? What language would be able to do this, can I do it in python?
This depends on what you are actually seeking to do.
You could embed a message that you sign with your private key, which can then be verified to be authentic with your public key.
If you want the message to be encrypted, you will need to pass a private key to the buyer and encrypt the message with the corresponding public key.
Generally, you don't need the private key unless you are doing encryption or signing. There are libraries for PGP in essentially all programming languages, python has python-gnupg for this.
I have started learning GPG and I am a bit confused about the infos I have found. The GnuPG documentation says that
A signature is created using the private key of the signer
But at the Apache's site, they say:
The signature file is a digest of the original file signed by a public key...
And on the same site, in another section, they say the following:
A digital signature is created from an original document using a private key.
Now I suppose that the process of signing involves signing the hash of a release using the private key of the holder and not the public one like Apache says in the second link I have posted, or am I wrong? Otherwise, how could someone be ever able to decrypt the hash of a release signed with a public key if he/she doesn't have the private key of the holder?
Then, could someone simply explain in what the processes of signing and verifying a signature consist and what are the passages, e.g. for a software release like Apache Maven?
TL;DR: There is a mistake in the documentation, your understanding of signatures is right.
The signature file is a digest of the original file signed by a public [sic, this is should be private] key...
Signing a document usually is performed by calculating the hash sum of the document (asymmetric cryptography is very slow for large amounts of data), which finally is encrypted using the private key, so anybody can decrypt it using the public key. If the decryption process results in the same hash sum as is calculated from the original document, it must have been encrypted using the private key - which is only known to the signer; thus the authorship is verified.
Encryption (leaving apart the aspect of hybrid cryptosystems like OpenPGP is, but the general concept stays the same) works the other way round; the public key is used for encryption, so only the private key can be used to decrypt the information.
I added a bug report for the documentation issue (closed/fixed since 2015-07-29).
Then, could someone simply explain in what the processes of signing and verifying a signature consist and what are the passages?, e.g. for a software release like Apache Maven -> https://maven.apache.org/download.cgi?Preferred=ftp://apache.mirrors.tds.net/pub/apache.org/ ?
You need to fetch the public key used for signing the software (usually, you will download it from a keyserver using gpg --recv-key [key-id].
Verify the key's integrity, for example by speaking with the developers, your web of trust, the products HTTPs-encrypted website (depending on how paranoid you're at verifying the authorship).
Issue a signature to certify the key if it is not already verified through your web of trust, if you don't want to create a public one, there are also local signatures which are never transmitted to the key server network.
Finally, use gpg --verify to check that the signature was indeed issued by the product maintainer's key.
The RSA algorithm is used for encryption (plain text to cipher text) and decryption (cipher text to plain text) of data. What is the need for using public keys in these sites; why is data encrypted as everything is viewed by everyone?
Why do we need to use public key cryptography in Google; how does it provide security?
What is the need for using public keys in these sites?
It is required to set up a shared secret (a big random number) that is used for further symmetric crypto. Public-private key crypto allows one to share a secret message (symmetric key material) even when each and every message is monitored and eavesdropped. See Hot does SSL works? for more info.
The problem with public-private key crypto is that it is dead slow, whereas symmetric crypto is dead fast. The benefit is that public-private key crypto uses two keys for encryption and decryption and this is what allows to securely share a secret through the insecure channel, whereas symmetric crypto uses a shared key for both operations and you need both parties to have the same shared key.
Why is data is encrypted as everything is viewed by everyone?
When data is encrypted all that an observer can see is pure random noise. An observer cannot understand anything from the encrypted communication. Unless storing encrypted communication, like NSA does, and later asking Google and other companies for their private key. In this way they can decrypt old communication.
Why do we need to use public key cryptography in Google; how does it provide security?
Many agencies would like to know what people search for: "how to make a bomb", political disputes, etc. Advertisers would like to know what people interested in so that they can bring relevant ads. If something is provided to you for free, you are the product. You sell your information (your interests) and when this is done on a global scale suddenly huge money become involved.
Public-private key crypto in this sense provides privacy. Only you and the server can understand the traffic, but no one else: no intermediate hubs, your ISP or government body.
Before Facebook switched to SSL-by-default, all traffic was indeed plain text. This made it possible to build a graph of connections on a truly global scale. The rational I guess was to possibly aid anti-terrorist forces to catch the bad guys. From the other side all population's activities were tracked. See PRISM for more info.
This topic continues to confuse me. I thought I'd write out my current understanding and hopefully find out the things I'm right about/things I'm wrong about.
When you create a development certificate, there is a concept of a public and private key. The certificate available thru the provisioning portal holds on to a public key, while your private key is stored within your keychain. In order to code sign your app, you've got to have both.
In order to run an app, the device must have a provisioning profile, which essentially holds on to an app identifier, a set of recognized certificates (the app must've been signed by one of these certificates), and a set of device identifiers (which indicate which devices are allowed to run the app).
The 'recognized certificates' have references to the public key, while the private key is essentially passed on by the app.
Thus, with regards to the App Store, we can think of a normal device as coming with a default prov profile that already has apples 'public key' and apple performs their own code sign operation before distributing whereby they add their private key.
Perfect? Close? Way off? Insane?
For what it's worth, here is my updated understanding:
A Provisioning profile is a file that tells you which apps (via an AppID), signed by which developer (via the certificate) can run on which devices (the UDIDs).
With certificates, there is a concept of a public and private key. Public and private keys are mathematically linked such that one can encrypt the plain text, and one can decrypt the cipher text. Certificates allow apple to ensure two things: 1, that only registered developers can distribute their code, and 2, that the code that is being distributed isn't altered on its way to your device.
When you build your code in Xcode, you 'code sign' your application with the private key located in your keychain, thereby 'locking' it. In order to unlock/decrypt the code, the destination device must have access to your public key. The device gets the public key from your certificate that is included in the provisioning profile.
In order to verify that the code remains unchanged on its way from the developer to the device, your certificate includes an algorithm that can convert your code/data into what is known as a 'digest.' On the developer side, the data/code is run thru the algorithm, generating into a separate digest, which is then locked with the private key.
When the app package is received by the device, the device can ensure the code hasn't been altered by doing the following: unlocking the digest with the private key, running the unencrypted data thru the algorithm (remember, the device can access the cert thru its prov profile), and making sure the result is a digest identical to the one sent over from the developer.
Beyond that, the prov profile need only check the UDID of the phone, and make sure the AppID from the profile matches the identifier in the app.
The reason we don't need separate prov profiles for apps from the appstore, i assume, is because each iPhone ships with the public key used by apple to code sign distribution apps.
Ray Wenderlich has it explained reasonably well here. To improve your description, instead of
The 'recognized certificates' have references to the public key, while
the private key is essentially passed on by the app.
I would say:
The app .ipa includes a developer certificate. The developer
certificate is signed with your private key - as well as with the
official Apple private key.
Thus, by verifying the developer certificate with Apple's and your public keys, the iPhone can verify that:
you are the developer of this app
you have been certified by Apple for app development
this app is allow to be run on the iPhone (as long as there is a provisioning profile on the phone that refers to this developer certificate).
Your private key is not stored in any of the certificates or profiles, it is only used for signing. Not sure whether the public keys are stored. In order to be fully secure, the phone should fetch the public keys from Apple when verifying.
This question already has answers here:
Whose key is used to encrypt a HTTPS response?
(3 answers)
Closed 4 years ago.
What I understand about RSA is that Alice can create a public and a private key combination, and then send the public key over to Bob. And then afterward Bob can encrypt something using the public key and Alice will use the public and private key combo to decrypt it.
However, how can Alice encrypt something to be sent over to Bob? How would Bob decrypt it? I ask because I'm curious how when I log onto my banking site, my bank sends me data such as my online statements. How does my browser decrypt that information? I don't have the private key.
Basically, the procedure is:
The client connects to the server and asks for the server's certificate. The certificate contains the public key and information about the server's identity.
Assuming the client is happy with the server's identity, it generates a random number P and encrypts it with the server's public key.
Only the server can decrypt P (with it's private key - not shared with anybody) so when the client sends the encrypted random number to the server, the server decrypts it.
The client and server both use P to generate a symmetric key for use in a symmetric encryption algorithm, safe in the knowledge that only the client and server know the value of P used to generate the key.
Alice will use the public and private key combo to decrypt it
Alice would just decrypt it with her private key.
However, how can Alice encrypt something to be sent over to Bob? How would Bob decrypt it?
Alice would need Bob's public key to send something to him.
Typically, public key encryption is used for authentication, non-repudiation (like signing), and distribution of symmetric keys (which are faster for encrypting/ decrypting long messages).
Simple, you need a key.
SSL/TLS solves this problem by creating a symmetric session key during the connection setup. The public key cryptography is used to establish this session key, which is then used for bi-directional data communication. Read more about TLS
I didn't create this, but someone shared this video with me and it helped the theory make much more sense. As always the devil's in the details (implementation).
http://www.youtube.com/watch?v=YEBfamv-_do
On a general note I struggled to understand Public Key Cryptography for quite a while along with the other elements of PKI such as Digital Signatures and Certificates whilst preparing for Microsoft C# certification.
I came across an explanation in the form of a concise and detailed PDF at cgi.com. I know it's back to good old Alice and Bob! but it really cleared things up for me with its diagrams and notes and also has some thought provoking questions at the end. Definitely recommend it.
Visit http://www.cgi.com/files/white-papers/cgi_whpr_35_pki_e.pdf
However, how can Alice encrypt something to be sent over to Bob? How would Bob decrypt it? I ask because I'm curious how when I log onto my banking site, my bank sends me data such as my online statements. How does my browser decrypt that information? I don't have the private key.
This is where you're wrong; you do have a private key. As part of the handshaking process, each side generates two keys: a public key and a private key. The client sends its public key to the server, who will use it to encrypt all data sent to the client. Likewise, the server generates both keys and sends its public key to the client, which will use it to encrypt all data sent to the server.
In many scenarios, the asymmetric key algorithm is used only to exchange another key, which is for a symmetric algorithm.
In this situation, Alice would use Bob's public key to encrypt the data and Bob would then decrypt it with his private key.
Essentially, a public key encrypts data and a private key decrypts that data. Since every user has both a public and private key, you can securely send data to any other user.
If you connect to the site of your bank it works a lot of cryptographic things. The most important is that you use public key of the bank to send a piece of information to the bank, because in every SSL (https) connection server send to client it's public key packed as a certificate.
Usage of certificate and world wide PKI is important. You want be sure, that if you gives to the bank your bank pin, that on the other side is really your bank and not an other person. This will be solved, because on every computers there are a small number of public keys of well known organisations (like VeriSign) and bank send you not only his server public key, but a certificate. certificate is a message signed by VeriSign for example, which say "this public key is really from the bank XYZ". So because you have public key of VeriSign you can first verify, that server certificate of the bank is correct. So you can be sure, that you communicate really with your bank.