# Tag Info

## Hot answers tagged certificates

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

7

You are looking for Proxy Re-Encryption. From a high-level viewpoint, a proxy re-encryption scheme is an asymmetric encryption scheme that permits a proxy to transform ciphertexts under Alice's public key into ciphertexts decryptable by Bob's secret key. In order to do this, the delegator $A$ gives a special re-encryption key $rk_{A \rightarrow B}$ to the ...

5

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

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

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

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

2

In short: The parent CA would sign the public key of an n-time signature scheme, as opposed to the public key of a signature scheme which is valid for an unbounded number of signatures (the current design). n-time signature schemes are usually just constructed by generating n instances of a one-time signature scheme and then accumulating their public keys ...

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

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

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

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

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

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

That scheme is effectively the same as having the parent CA counter-sign all issued certificates, since the parent will have to make a new signature (on a new accumulator) for each newly issued certificate. What are the features you want from such a scheme? To frame the question, here's a trivial scheme: client sends certificate request to child "CA"; ...

1

In short, they retrieve the entropy directly from a source on the chip. From Wikipedia: In computing, a hardware random number generator (TRNG, True Random Number Generator) is an apparatus that generates random numbers from a physical process, rather than a computer program. Such devices are often based on microscopic phenomena that generate low-level, ...

1

This is a very interesting question, in the sense that every smart card provider claims the inviolability of its own process. Nowadays, Smart cards can generate their cryptographic keys on the card itself using appropriate hardware. Entropy is generally generated by an embedded random generator. The hardware of the generator is generally certified by ...

1

I think that this is not possible with a conventionnal public Key (Probably I'm wrong ?). But this question could easilly be solved by IBE as introduced by Dan Boneh in the seminal paper "Identity-Based Encryption from the Weil Pairing. This new system introduced in the early 2000, allows the Delegation of Decryption Keys, but this require the set up a new ...

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