Tag Info

A non-random serial number does not imply, by itself, a security issue with the signature scheme, but, as @Jack points out, it can be used to leverage an attack. On a general basis, signature algorithms begin by hashing the input message with a given hash function; if the message or hashing process is fully controlled by the attacker, then collision ...

Predictable serial numbers were used (along with serious weaknesses in MD5) to create a rogue CA certificate in 2008. Randomizing the serial numbers would have prevented this attack. And, obviously using a sequential serial number reveals the number of certificates signed, and requires careful state management. In general I would say using a large (large ...

It has to do with optimizing RSA. It turns out that using the Chinese Remainder Theorem with $p$, $q$, $d\pmod{p-1}$, and $d\pmod{q-1}$ (i.e., prime1, prime2, exponent1, exponent2 from the data structure in the question) to run the decryption operation faster than if you only had $d,n$. For more information on how it is done, I found this reference ...

RSA is two algorithms, one for asymmetric encryption, the other for digital signatures. For asymmetric encryption, the main competitors of RSA would be: The Rabin cryptosystem ElGamal NTRUEncrypt Diffie-Hellman key exchange (in practice, key exchange is almost as good as asymmetric encryption, since most usages of asymmetric encryption are for sending a ...

This has more to do with how Microsoft decided to implemented their certificate inspection GUI, than about the actual fields of the certificate. Most signature algorithm identifiers present in contemporary certificates specify both the public key algorithm (RSA in this case) and the digest algorithm (SHA-1 in this case). The identifier "sha1RSA" is most ...

If the CA issued something with a CSR as the dominant part of the To-Be-Signed field, it wouldn't be a X.509 certificate and hardly any existing software would know what to do with it. I guess the original CSR could be added as an extension, though. Therefore, I suppose you are really asking why the X.509 certificate format wasn't originally specified to ...

Short version: SPKI links not only names, but authorizations to keys. Also, it uses a better syntax (S-expressions) than X.509 certificates. Long version: What problem does it solve? Both the traditional CA-based public-key infrastructure (PKI) and PGP's web of trust (and other similar systems) do mainly one thing: Linking names to public keys. The ...

The "Common Name" is part of a X.500 name; here, the one called "SubjectDN", which designates the owner of the public key which is contained in the certificate. That name is part of the certificate, in the part which is covered by the signature; as such, it is exactly as trustworthy as any other element in the certificate.

If all the components share the same certificate, then they share the same private key. This raises the two following points: When a secret is shared by more than two people, can it still be considered really secret ? Secrecy dilutes fairly fast. If all components share the same secret value, then breakage of any single component reveals the private keys ...

The answer is simple: The original signature of a CSR is not needed in a signed certificate issued by a CA. If a CA does somthing wrong (e.g. change attributes of the CSR), the CSR creator doesn't have to use the cert (since he's the only holder of the private key, he is also the only one who could use it -> create signatures).

It seems we have aligned interests. I'm also a university student (although I am a math/comp sci double major) looking to pursue a career in cryptography. To that end, I have been self-studying it for a while now. So, take what I say with a grain of salt. As a forewarning, this post focuses specifically on what topics cryptographers often encounter and less ...

To sign a message $M$ under RSA, one should NOT build the signature as $\mathcal{Sign}(M)=M^d\bmod N$, for several reasons: either that limits to messages $M$ in range $[0..N-1]$, or that allows forgeries of the form $\hat M=M+k\cdot N$, because $\mathcal{Sign}(\hat M)=\mathcal{Sign}(M)$; that allows forgeries of the form $\hat M=R^e\cdot\prod{M_j}^{a_j}$ ...

Such certificates are basically just an implementation of digital signatures. One certificate is used to sign the data using a private key, and a corresponding verification certificate is given to the user along with the signature and the data. The user uses the verification certificate to verify that the file matches its signature. You can't reverse ...

Your question is only slightly ill-defined. The problem is that the word "cryptography" is horribly overloaded. I think there are at least three different regimes of cryptography: Cryptography in academia. As Reid said, academic cryptography mainly springs out of complexity theory. With very few exceptions, you don't need much math knowledge to succeed ...

I am not sure to fully understand your question, but what you can do is the following: take $r=2^{512}$, and compute $p=r+\delta$ and $q=r-\delta^\prime$ such that $p$ and $q$ are prime numbers, and $0\leq \delta, \delta^\prime < 2^{32}$. Then you have an RSA key at you disposal that can be broken by a brute force search on $\delta$, which should take ...

1. Was I right? Pretty much. I want to add something to help clarify though: The Verisign public key in his store is of the Verisign CA (It is also stored in the form of a certificate). Also I think this process would qualify at decryption, no? 2. Verisign creates the digital signature over my certificate data. Which data? I'm not really sure what you ...

In Theory In theory, either method works and has its advantages and disadvantages. Sending the entire chain up to the root means the other party (e.g., web browser) has everything they need to do the validation. A disadvantage is that more bandwidth is used. Sending only the one certificate could yield better bandwidth usage (the verifying party still has ...

Time stamps are also signatures; see for instance RFC 3161 which is the most commonly used time stamp format. In particular, such time stamps also rely on certificates (the TSA certificate), and thus also expire. So you need regular time stamping; whenever the latest time stamp is about to expire (but before expiration), you need to obtain a new time stamp ...

It would seem that the answer is no. If the TSA's private key is compromised (and thus revoked), the time stamp signature cannot be trusted as whoever compromised it could sign documents with old time stamps. Surely users would want to be warned before accepting a time stamp signature from a compromised certificate. It seems then if this is your threat ...

I believe the SignatureAlgorithm is the algorithm used to sign the content using the private key, while the SignatureHashAlgorithm is used to hash the content before signing (so as to not sign as much data, which is a relatively slow process). In this case, it's easy enough to figure out that the SignatureHashAlgorithm is SHA1 because it's in the name of the ...