# Tag Info

14

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

7

Yes, obviously if the CA generated your private key, they might keep it and share it with anybody. Yes on both counts. In fact, the normal way to generate a certificate -- whether for a Web server (TLS) or for yourself (S/MIME or TLS client) -- is to create a "Certificate Signing Request" and send it to the CA. The CSR includes your public key, not your ...

7

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

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

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

4

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

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

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

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

3

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

2

There was a post on security.stackexchange last week about this. SSL/TLS with Certificate Authorities for all intents and purposes is now completely insecure from governments and any organisation who has a CA pre-trusted inside the standard web browsers. DNSSEC will also fall under the same scenario because at the top level you have a particular government ...

2

I am a master's student in cryptography, and I have had a few summers worth of experience in applied cryptography. Cryptography is a broad field, and there are many aspects to it. If you are looking at cryptography in academia, I would definitely recommend having a strong background in mathematics and computer science, and as strong a ...

2

The revocation status of a certificate is application depended, meaning that if the application under which you perform the encryption or decryption does not check for revocation status with the CA, then you may still proceed and encrypt or decrypt the message. You should consider the loss of a private key of a certificate as a loss of your password in a ...

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

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

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

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

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

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

1

Another approach is done by the Perspective Project. With it you setup your server and it will monitor the certificates of the sites. You can then subscribe to any number of these monitoring servers and verify them against each other. Since you decide which ones you want to trust, instead of 1 certificate being certifiable by just 1 person, it should be ...

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