Hot answers tagged

29

Disclaimer: I don't know Javascript and I do not practice BouncyCastle. However, I do know Java, and ASN.1. ASN.1 is a notation for structured data, and DER is a set of rules for transforming a data structure (described in ASN.1) into a sequence of bytes, and back. This is ASN.1, namely the description of the structure which an ECDSA signature exhibits: ...


14

The question's bytestring 2a 86 48 86 f7 0d 01 01 01 is the Value field of an ASN.1 BER/DER TLV with type 6, which is the Object IDentifier for an RSA key (the Type and Length just before are coded as 06 09, and won't be further discussed). In order to parse that Value bytestring, we first separate the bytes into blocks ending after each byte which high-...


8

For a binary field $\mathbb{F}_{2^m}$, the polynomial necessarily has degree $m$ (otherwise the field would not have cardinal $2^m$), and its least significant coefficient must be $1$, not $0$ (otherwise the polynomial would not be irreducible, and the field would not be a field). Therefore, for $\mathbb{F}_{2^{193}}$, if the polynomial is a trinomial, then ...


7

The first octet in a DER encoded BITSTRING is the number of unused bits (0 in this case). The remaining 65 octets are the elliptic curve point encoded as described in SEC 1 (http://www.secg.org/collateral/sec1_final.pdf) section 2.3.4. The first octet distinguishes the identity point and whether point compression is being used. Since you have 65=1+32+32 ...


6

From RFC 5280 r.e TBSCertificate.signature This field contains the algorithm identifier for the algorithm used by the CA to sign the certificate. This field MUST contain the same algorithm identifier as the signatureAlgorithm field in the sequence Certificate (Section 4.1.1.2). I think it's because the authoritative signature is on the ...


5

There is no difference. RFC 5280 even requires $\tt signatureAlgorithm$ and $\tt signature$ to be the same. According to this discussion on the PKIX mailing list, the reason for the redundancy is that it allows to consistently process signatures independent of the signed data, e.g., verifying the signature without knowing about the structure of $\tt ...


5

Background When defining protocol compliant with NIST SP 800-108, you just need to pick suitable options, which work well with your protocol. If there is a need to be compatible with a specific pre-existing protocol, you may want to take a look at NIST SP 800-135Rev1, which defines application specific key derivation functions. It is notable to recognize ...


3

The public key structure is an X.509 SubjectPublicKeyInfo for ECC (public) key, using explicit format instead of (more common and popular) 'named' format. SPKI is a generic ASN.1 structure that supports multiple (and extensible) algorithms: SEQUENCE { AlgorithmIdentifier = SEQUENCE { algorithm: OBJECT IDENTIFIER -- identifies the algorithm ...


3

According to http://www.oid-info.com/ bcrypt has no official OID. You could register a private enterprise number with IANA and assign your own OID for your purpose. But that's going to make interaction with 3rd party application more complicated. Or you could use PBKDF2 instead of bcrypt. PBKDF2 is a public-key cryptography standards. Libraries such as ...


3

Annex E of X9.62-2005 says: Annex E provides the syntax for elliptic curve cryptography, including domain parameters, keys and signatures, according to Abstract Syntax Notation One (ASN.1). Although it is not required that elliptic curve domain parameters, keys, and signatures, be represented with ASN.1 syntax, if they are so represented, then their ...


3

The are the $d_P$, $d_Q$ and of course $q_{inv}$ - in that order - in the Wikipedia article. As you can see in the formulas relating to the Chinese Remainder Theorem the primes are also used but $d$, the private exponent, isn't. The CRT calculations can be used to speed up RSA private key operations, which are the slowest part of the RSA cryptosystem after ...


3

Without knowing which domain parameters were used this question is impossible to answer. The problem is that the value of the private key is random within the domain. So although we know that the key size is about 224 bits, there is no way to validate any public key value, because the public key is calculated using the random private key as input in the ...


2

An EdDSA signature is a sequence of bytes encoded according to the EdDSA paper or its extension to more curves, or according to RFC 8032, which should be treated as opaque by callers. In particular, for an instance of EdDSA on a curve $E$ over a field $\mathbb F_p$ of order $p < 2^{b-1}$: A public key is a $b$-bit bit string $n \mathbin\| \underline y$ ...


2

The practical answer to this is: use a library. There are many available, and they already handle the complicated details below plus many more that exist in PKCS7/CMS in general but are not in this rather simple case. However, that is offtopic for crypto; try softwarerecs for help selecting one, and stackoverflow if you have specific problems using it. The ...


2

However, at least for the rsaEncryption algorithm, there's ASN.1 DER data inside (representing the signature). This is not actually the case. It is the case for - for instance - DSA and ECDSA, where the signature consists of two parts: the $r$ and $s$ value. However, it is not the case for RSA. Let's take a look the the signature of this site, which can ...


2

The contents of the signature field is dependent on the signatureAlgorithm being used. So it can hold anything (including DER serialisation) for as long as it's eventually encoded as a BIT STRING. Therefore the length of the signature can be different. Using BIT STRING allows you to know the exact number of bits being used in the signature. With OCTET ...


2

Yes, hybrid crytography is generally used; hybrid crypto combines asymmetric cryptography with a fast symmetric cipher to do the bulk of the work. Either the keys are generated using RSA-KEM (and a Key Derivation Function) or - and this is much more common - a random symmetric key is encrypted using RSA with PKCS#1 padding or the more secure OAEP padding - ...


2

According to Section 6 of X9.62-1998, any encoding may be used: While it is likely that these ASN.1 definitions will be encoded using the Distinguished Encoding Rules (DER), other encoding rules may also be used.


2

I'm assuming you're talking about these two fields: signature signatureAlgorithm following the names defined in RFC 5280 section 4.1. And section 4.1.1.2 then goes on to state (for signatureAlgorithm): This field MUST contain the same algorithm identifier as the signature field in the sequence tbsCertificate (Section 4.1.2.3). So, yes, they have to be ...


2

Ok, if there is no standard, then "I do it my way": Let $i$ be a root of a fixed minimum polynomial of $GF(p^2)$ and $x$ be an element in $GF(p^2)$. Then $x:= x_1+x_2*i$ can be represented as a vector $(x_1,x_2) \in GF(p)^2$. Now convert $x_1$ and $x_2$ with the FE2OSP function form IEEE P1363 and concatenate them $FE2OSP(x_1)|| FE2OSP(x_2)$. An ...


2

Yes, it seems related: the private key just misses a 00 value (not a 01 value) in front. The problem that the I2OS primitive seems to round down instead of up if the value is smaller than 520 bits (65 bytes). Fortunately the public key seems to be OK. The next byte boundary from 521 is 528 (512 + 16 bits). 2 x 528 = 1056 bits. However, the first 8 bits of ...


2

It depends. If the entire input itself is within a DER encoded structure, then I would bug out. There is nothing defined for BER, CER or DER that would allow padding of structures within constructed values. If the input is just followed by additional data or junk bytes then it is up to the protocol or otherwise your discretion if you want to accept the data....


2

I don't think there's an exact "correct" behaviour in this case. It would be up to the implementation to decide, since the spec is only concerned about the DER encoded portion. If your implementation parses the input as it moves along only, and doesn't concern itself with the overall size, then it would work fine. Having said that, I believe the best ...


1

I'll port the contents of the link of Henrick: Within the United States, one key forum for profile collaboration is the Open Systems Environment Implementors Workshop (OIW), which is hosted by NIST. OIW recently expanded its domain of concerns from communications to the full range of Open System Environment issues (interoperability, portability, and ...


1

For the algorithm you should use the AlgorithmIdentifier type of RFC5280. Block size and key size can be derived from the algorithm id and the key itself, so there is no need to store them. So, if you want something really lightweight, just store that into a sequence: SymmetricKey ::= SEQUENCE { algorithm AlgorithIdentifier, key BIT STRING }


1

Bouncy Castle is correct. Bouncy Castle contains a BER/DER encoder that changes ASN.1 objects into encoding by explicitly coding it that way - manually, as far as I understood. As this structure is represented using the distinguished encoding rules (DER) the structure should be empty. DER uses the minimum number of bytes to encode values. DEFAULT ASN.1 ...


1

An ECDSA private key is just an integer, not a pair of integers. Therefore you simply need to interpret this bitstring as an integer, per the ASN.1 specs.


Only top voted, non community-wiki answers of a minimum length are eligible