New answers tagged

3

The self signed ones are the root nodes, which are generally drawn on top (i.e. the tree or trees are bottom up). You can distinguish them by looking at entries where the subject is also the issuer (J and K, in other words). After that you simply draw edges from the root nodes to the underlying nodes. So in the end you should have a branch or chain going ...


0

IIRC, and I could be wrong, This is because it was using self signed certs that were generated psuedo on-the-fly. Because of this, if you reverse engineer the interception mechanism you could extract the private key


1

For instance the procedure never asks you to create a private key, instead they magically create one for you. I know cryptography is magic, but in this case it is also secure... :-) Because when using a Let's Encrypt client the key pair is generated locally on your server and not send to Let's Encrypt servers* - in contrast to some other commercial CAs, ...


0

The browser examines each certificate in the chain that terminates with a self-signed Trusted Root Certificate of the Certification Authority. This would be in the local certificate store. It verifies that the signature is valid, that the current time is within the validity period of each certificate as well as checking the CRL published location (http or ...


0

Certificate authority is the one issuing SSL and other digital certificates. It is highly trusted entity who verifies the information provided by web server such as its domain name, public key, the company’s identity. If all the information provided, are legal then the CA will issue the respective SSL certificate duly signed using its private key. Moreover ...


5

Subject identification in SSL/TLS server certificate is DNS name(s) usually and/or IP address(es) rarely, which are matched against the requested URL. Neither of these determines location. EV certificates must contain some physical location information verified by the CA, and other certs may, which the browser cannot further check; some browsers display some ...


2

Your question reveals the lack of some basic conceptual understanding in how cryptography and encryption works. Is using digital signatures an examples of using asymmetric cryptography? Yes it is. Asymmetric encryption means 2 keys are used to encrypt and to decrypt a message. A example of a widely used asymmetric cryptographic algorithm used for ...


13

It is not always so easy as described in the other answers. It works only with the old PEM keys. New openssh format of the keys (generated with -o option, more secure, since openssh-6.5) looks the same if you check the headers: $ head rsa_enc -----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAACmFlczI1Ni1jYmMAAAAGYmNyeXB0AAAAGAAAABCYdi7MhY $ head ...


8

The "RSA key" is actually a set of values stored as an ASN.1 structure in the standardized DER binary format, then encoded in base-64 to get the final PEM file. A very easy way to determine whether a key is encoded or not is simply to check whether the ASN.1 header is present, and this is usually as simple as checking if the "key" begins with the letters ...


29

The keyfile will have a different header if it is password protected. Here's the top of a key without a passphrase: -----BEGIN RSA PRIVATE KEY----- MIIEogIBAAKCAQEA3qKD/4PAc6PMb1yCckTduFl5fA1OpURLR5Z+T4xY1JQt3eTM And here's the top of a key which is passphrase-protected: -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,...


2

Using a symmetric password-based encryption scheme on the keys. Where you have to "enter your passphrase" before you are allowed to use the key. Since the passphrase is used to decrypt the actual key. Most of the security concerns about the usage of passphrases are discussed here: Security of passphrase-protected private key


0

I am aware of the option, white-box cryptography. Essentially, keys are embedded a specific implementation of the crypto algorithm. White-box techniques are typically hardended by code/data obfuscation, which makes debugging more difficult.


2

Yes, why not. Key generation (including key generation for ECDH) and private key operations are relatively efficient compared to other cryptosystems such as RSA. There are some things to keep in mind: standard ECC operations such as ECDSA do require a good random number generator to be present; the small key size makes it relatively simple to use quantum ...


3

Hushmail does something like this (or used to). The private key was stored locally and the website would send a Java applet to handle encryption/decryption and signing operations. It would protect you against the vector you describe... but... the whole model of a web application handling PGP has serious limitations. When you log on to the compromised ...


0

In this case you have to wait until the time period you set in max-age is passed. In this situation it's better to roll back to the old certificate, add a new pin to Public-Key-Pins header and wait for some time until the vast majority of clients receive the updated header. In future, just don't rely on only one pin - always have a reserved certificate.


1

You can only use one key to sign the data… … However, it's way more convenient to use 2 pairs of key (ZSK & KSK). There are 2 important points to take into account: You need to regularly refresh the key (ZSK) used to sign the records. (For security reasons.) You need to be sure that the DS record in the parent zone corresponds to the key used in the ...


24

Yes, the number of compromised certificates are much larger with Root Certificate compromise. But it's not just the number certificates. Getting a new root certificates deployed due to compromised root is massively more difficult than replacing the certificates whose intermediates are compromised. For starters, replacing Root Certificate of a public CA, ...


13

Is that correct? Is there another benefit? An offline Root CA sacrifices convenience to gain security. But, anyway, CA must issue new Intermediate CA certificates and revoke the old ones... so the only benefit that I can find is that CA issue different Intermediate certificate for different purposes. Yes, in case of a compromised Intermediate, ...


4

So the "universe" of compromised certificates is smaller that if Root CA would have signed all of the certificates. Sure, you could put it that way. But until the intermediate CA has it's certificate revoked (and even after that, it could still be problematic), it could continue to create bad certificates that users will trust. Because revocation isn't ...


1

Would a service be impacted if the system does not have any interaction with browsers? Not by the browser sha-1 deprecation. However, sha-1 is used and being deprecated on many other scenarios. Digital signatures, TLS communications in general (clients may start refusing it soon or already refusing it), authentication systems. It should be abandoned as ...



Top 50 recent answers are included