In yodlee development, we are asked to upload a public key. What is the required type of the keys as all types that PuTTY Key Generator can generate.
If anyone know, please let me know how to do it.
You have to generate an RSA key pair in the PKCS#8 format, using a key size of 2048 bits.
Related
I have a file encrypted with AES using a 256-bit (or 128-bit) key. Passing to and asking the file owner to keep the 256-bit key would be humanly difficult.
How can a more friendly password be used by the owner to remember or retrieve the actual 256-bit key?
For this kind of issues, we have Key Derivation Functions (KDF), as Argon2, PBKDF2, or BCrypt. Argon2 was the winner of Password Hashing Competition. You can see a detailed answer in crypto.stackexchange
In your case, first, you need to choose a password, and use it to generate a key by a KDF for the AES encryption then use this key to encrypt. Depend on the security you may use the random input to increase the entropy, though it will be hard to remember, too.
You can also encode the AES key into base64, however, it will not be easily remembered either.
Note: you can also transfer it with a small Veracrypt Volume.
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.
My question is: Does the public key in a asymmetric key have to be used to encrypt data or can it go either way (be used to decrypt)?
In RSA the public and private key technically fulfill the same role, one can decrypt what the other encrypted. The only difference is that one is made available to all parties.
Public keys can only be used to encrypt data, and private keys can only be used to decrypt data.
If you could decrypt data using a public key, that defeats the purpose of encryption.
Imagine you put your public key on your Facebook profile so that people can encrypt emails to you if they wish. If public keys could decrypt, then anyone that viewed your profile would have the key to all your emails (that were encrypted using that key pair).
I have a question about when AES generate a key and IV how would the user know what the key is or how the program would know which key to use like it is generated. For example like if there is a encryption method that encrypt the file and generate the key and IV. When the program restarts or be used another day they would want to use the decryption but how would you know or the program knows thats the key for that file.
I understand the decryption and encryption by looking at it. I just dont know where the information is store to retrieve the key?
Key management is a large part of any cryptography related protocol. It takes a book or so to explain.
One of the most known methods is using a password (see password based encryption in PKCS#5, where a key is generated from a (stored) salt, number of iterations and of course the password (encoded to bytes). Another option is to store the key on some removable device like an USB key.
Usually the main key is not used to encrypt the data, but an intermediate key called the data or session key is used. For instance PGP encryption generates a data key and encrypts it with a public key of an asymmetric key pair.
Then there are smart cards, TPM modules, HSM's, key containers (possibly provided by the OS), key sharing protocols etc. etc. etc..
So ... it depends.
Sometimes it is easier to think of a key as another secret. By encrypting something you've only "compressed" your larger secret (your plaintext) into a smaller secret (the key) that you have to keep and manage. This secret however may have been generated in advance, or may have been generated by other means. If you just generate your key at the same time and location as your ciphertext, you haven't solved anything yet, you only made your secret smaller.
It's easier for the IV, the IV can simply be stored with (commonly, in front of) the ciphertext.
How do the Public key fingerprint and Digital Signature differs ? Or both are same ?
if they are different, what is the application of public key fingerprint ?
Thanks
a public key fingerprint is a short sequence of bytes used to authenticate or look up a longer public key. Fingerprints are created by applying a cryptographic hash function to a public key. Since fingerprints are shorter than the keys they refer to, they can be used to simplify certain key management tasks
A digital signature is a mathematical scheme for demonstrating the authenticity of a digital message or document. A valid digital signature gives a recipient reason to believe that the message was created by a known sender, and that it was not altered in transit. Digital signatures are commonly used for software distribution, financial transactions, and in other cases where it is important to detect forgery or tampering
A public key fingerprint is a short version of a public key which is used to authenticate a longer public key, if they do not match that means that the longer public key has been tampered with. So basically a digital signature is something that is signed by a user which only that user can sign so you can be sure that it is coming from that user.
So a public key fingerprint is used by a client and the digital signature is used by the server
The fingerprint is the hash of a key. A digital signature is tied to some message, and is typically a one-way encrypted hash of the message.
The two serve different purposes: You can put the public key fingerprint on your card or, if you recognize the other person on the phone, use it to verify you got the right public key(s). It doesn't say anything by itself. The digital signature, on the other hand, says that the message was signed with that key over there, and you don't need any other channel for verification of that fact.