# Tag Info

10

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 ...

10

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: ...

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 ...

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 ...

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 ...

2

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 ...

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 ...

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, ...

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.

1

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 ...

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