Recently I'm reading code of bouncycastle(java), I noticed that when using EdDSA, we are using org.bouncycastle.asn1.x509.SubjectPublicKeyInfo#getPublicKeyData to get publicKey in org.bouncycastle.jcajce.provider.asymmetric.edec.BCEdDSAPublicKey#populateFromPubKeyInfo. But when using RSA we are using org.bouncycastle.asn1.x509.SubjectPublicKeyInfo#parsePublicKey in org.bouncycastle.jcajce.provider.asymmetric.rsa.BCRSAPublicKey#populateFromPublicKeyInfo.
The comment of parsePublicKey is for when the public key is an encoded object - if the bitstring can't be decoded this routine throws an IOException. and getPublicKeyData's is for when the public key is raw bits..
I am confused that how can we decide which method to use? Is this written in EdDSA spec or somewhere? I googled around and found nothing.
Edit:
Following is the info I collected, corret me if I'm wrong.
Both EdRsa publicKey and RSA publicKey is ASN.1 encoded，the use of org.bouncycastle.asn1.x509.SubjectPublicKeyInfo#getPublicKeyData is simply because EdRsa publicKey only contains one component (a simple byte array) while rsa key contains two component(modules and publicExp).
Almost all private key is pkcs#8 encoded, after all it's named "Private-Key Information Syntax Standard". But rsa privateKey can also encoded in pkcs#1 which cames before pkc#8, and those two formats can be converted back and force.
RFC 5280 specifies that X.509 public keys be encoded in a SubjectPublicKeyInfo ASN.1 SEQUENCE. This has two parts: the first ('algorithm') is an AlgorithmIdentifier which tells you what algorithm the key is for, and the second ('subjectPublicKey') is an ASN.1 BIT STRING whose interpretation is algorithm-dependent.
In the case of EdDSA, its use in X.509 was specified in RFC 8410. That RFC provides the OBJECT IDENTIFIER to use in the 'algorithm' for Ed25519/Ed448 and retains the public key format specified in the original EdDSA RFC - RFC 8032 i.e. a byte string, so that's what goes in the 'subjectPublicKey'.
Related
I was reading the docs provided for fabric-client and stumbled upon
Here, it states getCaName() method returns CA name of Certificate Authority, while getCaName() returns name of Certificate Authority.
What is the difference between these two? and how is Name and CA name of the Certificate Authority different from each other?
Thanks in advance
They are intended for different purposes. It also looks the the docs for the constructor do not show the optional parameters (which include caname as well as name).
getName() returns the value of the name parameter passed into the constructor and is basically just any name you want to give to the CA in order to identify it.
getCaName() returns the value of the caname parameter passed into the constructor and should match the ca.name property which is set when running multiple CA instances within the same fabric-ca process.
I have a private key from which I want to generate public key using Python.
This is what I understand:
privateKey = "XXXXXXXX"
from Cryptodome.PublicKey import RSA
I read that publickey() can be used to generate public key, but I'm not sure how to proceed ahead. Can someone help/point to good reference material.
Cutting short to
I have a private key from which I want to generate public key using Python.
if your private key is called private_key then the command
ssh-keygen -f private_key -y > public_key.pub
should generate the public key as public_key.pub.
EDIT : Keep in mind that the email ID used to generate the key cannot be recovered using this method. (Though that should not be a problem I suppose)
RFC 6488 specifies the following content of Signed-Data content type:
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }
The text explains:
The digestAlgorithms set contains the OIDs of the digest algorithm(s)
used in signing the encapsulated content. This set MUST contain
exactly one digest algorithm OID [...]
Then, inside SignerInfo, there is another DigestAlgorithmIdentifier:
SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
And the explanation is:
The digestAlgorithm MUST consist of the OID of a digest algorithm
that conforms to the RPKI Algorithms and Key Size Profile
specification [RFC6485].
In a couple of PKCS#7 files I peeked in, these two elements had equal value.
Is this a duplication of the same attribute? If not, what is the meaning of either?
Is this a duplication of the same attribute? If not, what is the meaning of either?
In case of RPKI yes.
The reason is that this standard does not introduce a specialized new structure but merely a profile of an existing one:
The RPKI signed object is a profile of the CMS [RFC5652] signed-data object
A CMS signed-data object in contrast to your RPKI one may contain multiple SignerInfo object in its signerInfos set, and each of them might make use of a different digestAlgorithm. Thus, in a CMS signed-data object the initial digestAlgorithms set may sensibly contain multiple entries.
Actually that field is even more liberally specified:
digestAlgorithms is a collection of message digest algorithm
identifiers. There MAY be any number of elements in the
collection, including zero. Each element identifies the message
digest algorithm, along with any associated parameters, used by
one or more signer. The collection is intended to list the
message digest algorithms employed by all of the signers, in any
order, to facilitate one-pass signature verification.
I'm trying to implement two way authentication flow for java card applet. Following is my approach.
Create EC (Eliptic curve) key pair for offcard applications.
Store the public key of the offcard application in the java card.
Sign input data from offcard application private key.
Verify it using offcard application public key stored in the java card applet.
I'm struggling at step two. All others seems trivial. I need to find a way to encode the public key created outside to card into byte array and then transfer that byte array to java card applet and reconstruct the public key and store it in the persistent memory.
Any hint on this.
Create an APDU with the following command data:
a short with the key size (the size of the order N)
send all the parameters except G (the base point) and W (the public key) and H as statically sized octet string (or byte array, if you are used to Java)
strip initial byte set to 00 if present
left padded with zero's bytes until you get the key size
send the G and W as uncompressed points
one byte 04
followed by both coordinates, sized using the method above
length is 2 times key size in bytes, plus one for the 04 indicator
optionally send the cofactor H as byte (but it's always 01 anyways)
use the set... methods to set the key
And presto, one EC key for you.
You can of course also parse a PKCS#8 EC key or use length indicators for each and every field, but this method is probably the most compact one.
To Achieve this you have to create a Javacard applet which....something like below
class MyApplet extends javacard.framework.Applet
{
// ...
public void process(APDU apdu)
{
// ...
byte[] buffer = apdu.getBuffer();
//Other stuff
}
}
To reach in public void process(APDU apdu) method you should select your applet with its AID after that every command will start reaching to this method.
You can create your own proprietary APDU to send "offcard application private key" and can get that here
byte[] buffer = apdu.getBuffer(); and then you can store it in a persistent array of your applet.
I'm considering a Symmetric Encryption scheme that uses an encryption key that itself derives from an X509 certificate. I realize this is not Asymmetric, and perhaps odd, but its an experiment.
My goal is to access the private key, or some portion, from the x509 Certificate as input to a "key" derivation function.
Dumb question: What property on the x509Certificate2 is the private key? The PrivateKey is itself just the alrogithm. The algorithm's ToXmlString enumerates several values (Modulus, Exponent, P, Q, DP, DQ, InverseQ, D) that I suspect are vendor specific. Also the x509Certificate2.RawData is available.
When talking about the Encrypt-with-public-key / decrypt-with-private-key Asymmetric algorithm...which of the above properties, if any, is that private-key?
Thanks in advance,
Howard Hoffman
According to the documentation here: http://msdn.microsoft.com/en-us/library/system.security.cryptography.x509certificates.x509certificate2.privatekey.aspx the PrivateKey property is a link to the private key and not the algorithm.
See also the example on the provided link to see how to print the private key.