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

7

ECC is indeed used by CloudFlare's website but only for the session key agreement. The authentication is performed using an RSA 2048 bit private key. The corresponding RSA public key is in the certificate. In other words, although ECC is being used, it is not used for authentication and therefore not part of the certificate. The ciphersuite is: ...

4

The short answer is that no, the length of validity would not help in a major way. First you have to consider how the attack on the collision resistance of SHA-1 applies to certificates. The idea, and how it actually worked in the case of MD5, is basically: Attacker finds a collision in the hash function that generates two certificates with the same hash. ...

4

There are four issues (basically all you can get at once I think) going on with your connection to this site which is why Chrome warns you. The first one is quite easy to spot: The usage of SHA-1 for the certificate signature. SHA-1 is generally considered deprecated and should not be used for scenarios where collision resistance is required, like ...

3

But if Server’s certificate is checked sucessfully by Client, how is it possible to consider that Server has been authenticated by Client, while at this time none message signed with Server’s private key has been sent to the Client and verified by it ? If only consider the key exchange to be what the RFC says it is, then yes this key-exchange can ...

3

Among the reason why root public keys are often expressed as a self-signed certificate are: It cryptographically protects against a deliberate alteration of an attribute of the public key (e.g. extension of validity period, or of what the key can be used for). It strongly protects against accidental alteration of the public key value. It is a reasonably ...

3

My question is how do I authenticate my App to the CA, to prevent something else to request these Client Certificates? There is generally no way to authenticate the client code. Any secret you embed in the app could be extracted. You must assume an attacker can send requests that an authentic client would. Instead, what you can do is authenticate the ...

3

I would think these numbers would have been put on the google search engine, and yield (probably) many hits. This assumption is wrong. Certificate serial numbers are not indexed by common search engines, nor are they typically posted to any HTML site. Frankly, I'm not sure why you would assume they'd be indexed. The Wordpress certificate is used for ...

3

You should keep the private key as safe as possible. How safe depends on the security requirements and risk assessment. A key store, such as a PKCS#12 key store or Java key store enables you to store a key protected by - usually - a password. This is obviously more secure than storing it as plaintext at the same location. It is possible to mitigate the risk ...

3

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

3

The certificate is not encrypted. It contains signatures (basically hashes) that are encrypted with the private key. The public key can decrypt that and the hash can be verified. In SSL/TLS there is a signature that the client supplies via private key to prove they are the owner, and the CA has signed it the cert with their private key, which can be ...

2

There is no need for a trust anchor to be distributed as a certificate at all, let alone a self-signed one. The certificate path validation requirements in RFC5280 make this reasonably clear; it even says in §6.2: The path validation algorithm presented in Section 6.1 does not assume that trust anchor information is provided in self-signed certificates ...

2

Well, they say they use gpg to sign the file (yubico-utf-ca-certs.txt) and the signature is in the linked file. So gpg --verify yubico-u2f-ca-certs.txt.sig yubico-u2f-ca-certs.txt gpg: Signature made Tue Sep 2 11:18:24 2014 CEST using RSA key ID 32F8119D gpg: requesting key 32F8119D from hkp server keys.gnupg.net gpg: key 54265E8C: public key "Simon ...

2

A X.509 certificate contains the following information: The name of the subject the certificate belongs to. The public key of the subject. This public key corresponds to a private key. The subject is assumed to have exclusive access to this private key. A reference to the issuer of the certificate (e.g. VeriSign or some other certificate authority). For a ...

2

Signature generation and encryption are two different concepts. The fact that both can use the same one way function does not change that fact. In the case of RSA, both signature generation and encryption (as well as verification and decryption) uses modular exponentiation. These are called the RSA primitives. They have however different inputs: one uses the ...

1

Simply put, there are two key-pairs for DHE_RSA instead one key-pair of RSA_RSA. For example, for AES128_CBC_SHA(long name is RSA_RSA_AES128_CBC_SHA), you have one key-pair for both key-exchange and authentication. for ECDHE_RSA_AES_CBC_SHA, you have two key-pairs. The ECC key-pair is temporary for key-exchange. The RSA key-pair from cert is used for ...

1

You don't need to hide the certificate at all. The certificate only contains the public key and additional info of the owner (in this case the server). It shouldn't contain any private information. What you need to do is to store the certificate in such a way that you can trust the origin of the certificate. So what you need to think about is certificate ...

1

The reason for this is because it is impossible to generate an MD5 for just any $y$, where $y$ is the output of any $x$ that isn't pre-computed. MD5 is broken but it is not completely broken. Using the common terms, MD5 is broken with regards to collision attacks, but not broken with regards to pre-image attacks. So your assumption that "Both methods ...

1

The signature value is contained in the certificate - right at the end to be precise. The signature value is not for human consumption, so it doesn't make a whole lot of sense to display it. Instead the verification result is shown. You need to parse the certificate yourself to view the signature value. For this you can use OpenSSL (openssl asn1parse) or you ...

1

Now when i am validating the certificate do i need to trace back the whole chain to validate the certificate? Not each time, no. You can do some caching, if you like (since root CAs tend to be valid for many years). But I don't think performance gains will be worth the added complexity of the caching idea. Also: if you plan to honor the expiration ...

1

Of course, since the X509 is statically signed, you have to check the signature only once.

1

You are missing the entire TLS protocol. The TLS protocol first establishes session keys. These can be randomly created at the client and send encrypted to the server. After that the session keys can be used to protect the data for confidentiality, integrity and authenticity. Encryption and authentication is performed in both directions. The TLS protocol is ...

1

Great question. I'll answer it in several parts. Which Keys does Alice send? There are two cryptographic operations that Alice may want to do: encryption/decryption, and signing/validation. You can either use the same keypair for both, or have two separate pairs of keys. 1 keypair method: Here Alice would sign outgoing messages, and decrypt incoming ...

1

Alice sends a CSR (certificate signing request) to the CA, which contains her public key, her name and usually her location. This CSR is then signed to prove ownership of the associated private key. The CA uses the data in the CSR to derive a certificate which will be handed to the user afterwards. The user can then prove his identity. The CA needs to ...

1

This only works if you are absolutely certain that you're properly erasing the old private keys. This is harder than it seems; you have to be sure that you're leaving no traces anywhere, including on backup media or scattered around your hard drive. With proper forward secrecy methods, the keys never leave RAM, which makes erasing them securely much, much ...

1

You'll want to integrate something in the request that is unique for the device or the user. This can be an iOS specific identifier or a hardware specific identifier. Furthermore, what you want is to make sure that the request came from your software. You can do this by authenticating the request somehow. For this you need a secret key. I guess the most ...

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