Hot answers tagged

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


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


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


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


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


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


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


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


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


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


2

The primary risk to your organization is that of someone else who gets tasked with creating an intermediate certificate, and googling for and following the exact same internet guides you found, thus producing another certificate with the exact same serial number. This could eventually cause problems with a certificate management database, where the ...


1

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

Theres lots of way to detect this scenario. 1: You can detect the double login since Host_A and Host_C would be logged in at the same time, unless the attacker somehow prevents Host_A from accessing Host_B. 2: You can use the IP of the host to detect if the client IP suddenly switches. I suppose you want to have a API client that communicates with a API ...


1

Yes, your scenario is acceptable when CA itself has SHA1 certificate, while signing issued certificates with SHA2. Refernces: Internet PKI: CA Browser Forum (CAB Forum) baseline requirements, §6.1.5 Microsoft: Windows Enforcement of Authenticode Code Signing and Timestamping Google: An update on SHA-1 certificates in Chrome All these references from ...


1

As you already noted, there are two ways to exchange symmetric session keys: through key encipherment or through key agreement (which is based on Diffie-Hellman algorithm). Both algorithms are not used at the same time. For example, Microsoft SChannel client reads bits from server certificate's KeyUsages extension (which is a bit string) and depending on ...


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


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



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