I'm trying to encrypt a message using asymmetric private-public keys.
In Botan, using Load_key() functions, I read the private key and want to extract it's public key from it. For constructing of an RSA public key in it's constructor, I'll need a "Algorithm Identifier" object and "key bits" which I have. The algorithm identifier object using pcks8_algorithm_identifier() function.
The problem is the "Key Bits" which returns a secure_vector<unsigned char> instead of a vector<unsigned char> and I encounter a bad::alloc exception when I want to pass it to RSA_PublicKey constructor.
Does anyone encounter such problem? If there is an alternative way of asymmetric encryption by loading keys from an input file in Botan I'll appreciate that
Botan uses two interfaces to represent asymmetric key pairs: Public_Key and Private_Key. The Private_Key interface inherits from Public_Key. Therefore, when you obtained e.g. an RSA_PrivateKey via PKCS8::load_key, this object already represents both the public and the private key. That is, you can plug this object into other methods that expect a Public_Key.
For accessing the raw key bits, the Public_Key interface defines a std::vector<uint8_t> public_key_bits(). The Private_Key interface has an additional secure_vector<uint8_t> private_key_bits(). Therefore, every Private_Key instance should have both public_key_bitsand private_key_bits available.
Reference: https://github.com/randombit/botan/blob/master/src/lib/pubkey/pk_keys.h
Additional note: The secure_vector class is a std::vector with a special allocator that ensures the underlying memory is overwritten when the object is destructed, so that sensitive information like private key bits are not remaining in memory. If you actually have to convert a secure_vector to a normal vector, the convenience function Botan::unlock is available (https://github.com/randombit/botan/blob/master/src/lib/base/secmem.h).
Related
What is the difference between full Access Key and Private Keys?
The explanation here is quite limited. It would be great to know
The Difference
Examples when you would use which kind of key
Here is the link to the docs https://docs.near.org/docs/roles/integrator/integrating#access-keys
Comparing private keys to full access keys is like comparing apple to oranges. When we talk about an access key, regardless of its permissions, we usually talk about a public-private key pair. The public key of the key pair is added to the account state that is stored on chain while the private key is stored on some local device that can be used to sign transactions through some client.
It's somewhat of a misnomer situation.
There are 2 types of keys in Near:
Full Access Key
Limited Access Key or Function Call Access Key
Every key "pair" has a public and private part. These are often also called keys on their own i.e. my "public/private key." Keys are just data and usual looks like some random bytes. In near we use base58 encoding for string representations of these parts.
A private key is sometimes also called a secret key.
I am having a problem when trying to match a password of a user using spring-security-core:2.0-RC4 with Grails 2.3.3.
I'm getting the following error when doing passwordEncoder.matches(rawPassword, encodedPassword)
No signature of method grails.plugin.springsecurity.authentication.encoding.BCryptPasswordEncoder.matches() is applicable for argument types: (java.lang.String, java.lang.String)
I've checked the BCryptPasswordEncoder source to search for clues and ended up in PasswordEncoder class definition.
The import in BCryptPasswordEncoder looks wrong though as the new PasswordEncoder is in org.springframework.security.crypto.password.
Doing passwordEncoder.isPasswordValid(rawPassword, encodedPassword, null) works (as in, there are no errors), but I don't know how to get the salt.
Is this working properly? If so, how do I get the salt?
EDIT:
I tried using NullSaltSource too but it gives me the error:
Salt value must be null when used with crypto module PasswordEncoder
As the error says, you can't use a salt with bcrypt. That's fine though - the algorithm is very robust and acts as if it's using a salt already.
The point of a salt is to ensure that if you and I have the same password, we don't have the same hashed password (assuming we each have our own salt value). Unsalted passwords cannot be de-hashed, but it's possible to create a table of hashes for all combination of passwords up to a certain length and use that as a lookup to find the cleartext password given a hash. Do an internet search for "rainbow table" and you'll find sites that have lookup tables for MD5, SHA-1 and other algorithms.
If you run encodePassword with a null salt value using bcrypt you'll get a different hash string for each run. The isPasswordValid method implementation with simpler algorithms usually hashes the cleartext password with the provided salt if there is one, and checks that this value is the same as the stored hash. But with bcrypt that's not sufficient, so it has the logic to verify that they are equivalent, but not necessarily equal.
The plugin uses a mix of implementations of the two interfaces for backwards compatibility, and will drop support for the old interface in a future release.
In Google reCaptcha, why two different key used e.g. Private Key and Public Key
My question is - What is the specific purpose for each keys ?
I know this is a relatively old question, but in the hope that it can still help you or someone else in the future..
Recapcha uses the standard public/private key cryptography implementation. To quote the link (Wikipedia)
..two separate keys, one of which is secret (or private) and one of
which is public. Although different, the two parts of this key pair
are mathematically linked. The public key is used to encrypt plaintext
or to verify a digital signature; whereas the private key is used to
decrypt ciphertext or to create a digital signature.
I have a scenario in which there are three parties: one user,one content provider and a proxy. The data is to be transferred between user and content provider anonymously though the proxy. I have two questions.
1. If the user has a pseudonym based on its public key, can it apply for another public key?
2. For data confidentiality between user and content provider such that proxy cannot read the transferred contents, Diffie-Hellman key exchange can be used. But can I use the public key obtained in part 1 to get the encrypted data between user and content provider?
Best Regards
Alexandera
Diffie-Hellman is a method for establishing a shared secret between two entities.
So, that's a part of secret key cryptography.
No number of public keys, unless you manage to generate the current shared secret, will get you the information shared between two parties using secret key crypto. A public key should be matched to, and used with, a private key. That's public key cryptography.
For part 1, I guess I don't understand what you want to do with the public key other than generate a pseudonym with it, I don't see why not.
Maybe I'm misunderstanding your question but I believe the answer for part 2 is no.
I've been looking through the documentation for Go's openpgp package, and I think I must be missing some obvious points. For example, there's a ReadKeyRing function, but no WriteKeyRing. I can, on the other hand, Serialize an Entity, but I have no way to read it back. What's going on here? Does anyone actually use this package?
An entity represents public+private GPG key information. The ReadKeyRing function allows you to read a list of GPG keys.
The Entity.Serialize function documentation states:
Serialize writes the public part of the given Entity to w. (No private key material will be output).
As it is only the public part of the entity, you can create a new entity with the serialized data as the public key.
A WriteKeyRing does indeed not exist. It would go through the list of entities and extract the public keys into an array.
I was also struggeling quite a lot with this - in the end I just learned it by example:
Encryption and Decryption example: https://gist.github.com/jyap808/8250124
Decryption Example: https://gist.github.com/jyap808/8250067
The thinking behind this is not made for a user, but seems to come strongly out of the actual way pgp is technically implemented.
I would suggest to generate the keys not via the package but just with a pgp command line tool.