Tag Info

Hot answers tagged

7

Although x.509 is the standard for PKIs with CAs, different certificate formats have been defined for the other 2 major PKI approaches: SPKI has defined its own certificate format , still (forever?) in draft status. Web-of-Trust models usually use the OpenPGP certificate format defined in RFC2440 RFC4212 "Alternative Certificate Formats for the ...


6

A lot of sleepless nights for the CA, their customers, web browser and OS developers, and Slashdot users, that's what. I don't know if a CA has ever had their private keys compromised, but there have been incidents where their systems were broken into and fraudulent certificates were issued. (There's a difference between a private key actually being taken, ...


6

If the KGC gets compromised it will break security, so why should a KGC generate private keys. Certificateless crypto tries to overcome the problem which exists in identity based crypto, i.e., that the KCG generates all the private keys of the users (that is necessary in IBE, see below) and thus knows all the private keys of users (which in turn enables ...


4

That's correct. If this happens, then your PKI is doomed and you have to set it up again and roll out all the certificates again. Actually, then not all the certificates are "compromised" in the sense of key compromise, but you cannot longer trust them, since if someone is in possession of the root private key, this person can issue arbitratrily dated ...


4

To answer this question, we must have a look at how TLS/SSL works. I guess you know that the aim of TLS/SSL is to authenticate communicating parties before setting up an encrypted connection through which application data will flow. And as you may already know, an SSL handshake/session will use asymmetric crypto for authentication and session setup and ...


4

If you use public key crypto in the correct way, then every user has it's own private key and corresponding public key (included in the certificate) and the keys of users are not related. Consequently, compromising the private key of one user does not affect any of the other users. So in the case of compromise of the private key of one user the remaining ...


3

Card verifiable certificates (CVC) are rather important for smart card technologies. In general X509 certificates have a rather complex structure and may take a lot of room compared to the RAM and EEPROM/flash memory that is available in a smart card chip. It is certainly possible to parse an X509 certificate in a processor card (it's a generic processor, ...


3

Quote from http://www.digi-sign.com/node/10922 All Types of Digital Certificates Are Also a X509 Certificate A X509 certificate *refers to all types of digital certificates, regardless of how they are utilized, and implies the current standardization used to design and create digital certificates. This standardization recognizes that the ...


3

You've stumbled on the requirement for authentication. Recall that signature schemes have a private key and a public key. The private key is used to sign the document in question, and the public key is given to the verifying party so that they can verify that the signature is correct. You're correct that it is possible to strip a digital signature and ...


2

There is "PGP network of trust" (also implemented by other OpenPGP-compatible systems like GnuPG) which does exactly that. You start off with nobody to trust except yourself. You decide to trust some friends of yours and hand your public key to them to have it signed. This signed public key will be automatically trusted by anyone else who trust your ...


2

If you can put the entire PGP certificate in a proprietary non-critical extension then you don't need to find the PGP certificate in a store. This solution depends on the condition that you are able to create your own OID and insert the PGP certificate in the extension. Furthermore, the server should accept such a certificate and contain methods of ...


2

I still got the impression that you did not really have read my answer to a related question. But still, I try to briefly answer your questions here. First of all, private key extraction essentially means private key generation. Extraction, because the partial private key ($D_A$) is generated with repsect to an identity string $ID_A$ uniquely identifying ...


2

That depends on the concrete CRL. As long as you have access to your private key, you can sign the revocation request. This prevents anyone without access to the private key from issuing a faked revocation request. With access to the private key, a faked revocation request can be sent. But in this case the damage is already done, and a revocation is ...


2

$ openssl genrsa | openssl rsa -text -noout Private-Key: (512 bit) modulus: 00:e7:be:c0:b7:7a:8a:e6:58:c3:dc:3e:eb:ed:bc: a7:15:04:78:8d:9d:fe:a2:83:aa:ca:85:5f:4b:ae: 5c:fa:3d:bd:2b:a9:91:58:e1:da:d8:8a:bd:25:6d: 07:10:74:52:2f:ee:ce:bd:3c:c6:89:01:2e:ff:9a: 3b:61:4d:e7:81 publicExponent: 65537 (0x10001) privateExponent: ...


2

Well, as it says in your link the problem is authentication. So somehow Alice and Bob must set up an authenticated channel. One way of implementing such a channel is by Alice and Bob holding each others public verification key for a signature scheme. A CA would probably not hold a secret key for Alice and Bob. However, using a CA to get an authentic copy ...


2

Firstly, PKI makes use of a private key and a public key. The private key is known only to the user, while the public key is communicated securely via the use of certificates. To provide authentication and non-repudiation, users may sign a message with their private keys and obtain a digital signature. Any other users can verify that the signed signature is ...


1

The question Alex linked in comments explains why authentication works to prevent a man-in-the-middle attack on Diffie–Hellman. So, whenever you can do the key exchange in an authenticated channel, you can be sure there is no MitM attack. (Assuming DH problem remains unbroken, of course.) Now, your questions: Is one solution for both Alice and Bob ...


1

The problem about Man-in-the-Middle attack on Diffie-Hellman is that both sides are not confident about other side's public key (g^a and g^b). If they were sure that they have correct public key of their's friend Man-in-the-Middle attack wouldn't be possible, because MITM attack is based on the forgery of public keys by adversary! If for instance Bob and ...


1

In Kerberos, if the Key Distribution Center is compromised then all the stored keys are exposed. In PKI, if a Certificate Authority is compromised then certificates may be forged. So, I guess we typically assume that the "trusted" third party will not be compromised so easily? Because either method you choose, there are still some inherent risks.


1

No, in general re-using keys is not advisable. Even if you would have a secure token then it would be better to have multiple keys stored in it. In general the level of security required for certificate authorities is higher than the security required for personal use of a key. If you later want to your CA key within a smart card or HSM then it should also ...


1

You can search for root certificates of a given CA. E.g.: http://www.symantec.com/page.jsp?id=roots, but this page is served over plain HTTP so maybe you shouldn't trust it! or https://www.mozilla.org/projects/security/certs/included/. From there when you want to check a certificate you can check whether it belongs to/was signed by a root CA you trust. ...


1

I'm not quite sure if I understand you correctly. As far as I understand it, you want to produce a threshold signature on the hash value of an X.509 certificate. It is not sure if you require a distribute key generation of the private key, or you are in possession of the signing key and distribute shares of the key to all stakeholders. 1) Actually, in ...


1

This is impossible - the receiver knows nothing about you so there's no way he can assure that the sender is in fact you.


1

First of all, as already mentioned in the comments, there is absolutely no mathematics or cryptography involved. Independent of the model used, i.e., public key cryptography, identity based cryptography, or certificateless public key cryptography (as i summed up in my answer here), the identity verification must be established by other means. In the wild ...


1

SSL offers protection against Man-in-the-Middle only if the client can make sure that what it believes to be the server's public key is, indeed, the true server's public key. X.509 certificates aim at providing this information, but this is relative that no rogue CA was involved. A "rogue CA" is here one of: An evil or gullible root CA ("subverted" CA ...



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