Tag Info

New answers tagged

1

Assuming that there is no time delay between compromising the private key and revoking the public key and that there is a way to reliably find out when the key has been revoked, this could work if you time-stamp the signature, not the file. This way, it can be shown that the signature was made before you lost your private key. However, typical key ...


2

No. The dialog doesn't add these properties to certificates. It has nothing to do with the currently selected item – it merely adds them to the filter-by-property listbox at the top of the main window. (That's the one that says "Intended purpose: <all>".) (The more specific name is a "certificate purpose", and the technical name is extendedKeyUsage ...


0

That is a good thing that not all properties are check by default because trust should not be enabled by default. As the Microsoft documentation says, the purpose of that property is: Certificates that server programs use to authenticate themselves to clients. Yes, not only the server needs to trust the client, but the client also can request the ...


-1

Is not the solution to encrypt with the recipient's public key? Anybody could have written it but only the intended receiver can read it.


0

On Windows, there is a small root certificate scanning tool called RCC that you can use to detect if your root store has been compromised. This won't prevent a malicious certificate insertion, but for detection purposes it is fine. http://www.wilderssecurity.com/threads/rcc-check-your-systems-trusted-root-certificate-store.373819/


7

Deploying internally is easy. The hard part is getting all the procedures right so that it is convincingly uneasy to obtain a fake certificate. This is the condition for signatures: a signature has any value only inasmuch as people believe in it. Of course, if your signatures are not meant to have legal value, then things are a lot simpler. But then, why ...


1

There are several usable Broadcast Encryption(BE) schemes. The most popular of them is the Subset Difference(SD) scheme by Naor-Naor-Lotspiech(NNL) that was proposed back in 2001. Here is a link to the full version of the paper describing the scheme: http://eccc.hpi-web.de/report/2002/043/. It was suggested for use by the AACS standard for digital rights ...


5

As per X.509, no problem. You can mix algorithms at will. Each signature is independent. (X.509 includes a special provision for when a CA uses DSS and issues a certificate that also uses DSS with the same group parameters, in which case the issued certificate may omit the group parameters. This is called "parameter inheritance". This is never used in ...


2

To my knowledge, there is no requirements on the algorithm for the subordinate CA other than the one the root CA wants to enforce. In fact, rather than looking for a rationale why it would be unacceptable, I would look into a rationale why it is acceptable. Any subordinate CA certificate must be signed by the root CA. And the root CA is representing the ...


1

That does indeed severely compromise security. There are no ifs, ands, or buts about it: if you have CAs that your computer trusts but are not the real ones, anything that relies on the OS store won't work (I believe Firefox has its own certificate store, but then that has to stay secure). See: the Superfish debacle, where the problem was that a hardware ...


0

Smart Cards have capabilities to process data, while the private key is stored on them and never leaves them. HSM (hardware security module) does similar things, with much better processing power than a smart card, but also for a much higher price.


4

There a few reasons for using different keys for signing and authentication: When using two keys associated certificates can be issued from different CAs with allows web sites to ask user only for authentication certificate on login. The certificates can be issued with different key usage - authentication one don't need non-repudiation, and signature one ...


1

A digital signature is a technological mechanism by which you can do several things, one of them being proving your identity to another entity: this is an authentication protocol. Your identity is a property inherent to, say, yourself; the notion of "electronic identity" really means "something which designates your identity and is amenable to an ...


2

Certificates are transient in nature: they expire, and must be renewed. Even worse, the validity of a certificate is the property of the current time, since certificates may be revoked at any time. Therefore, if you want to store signed documents, and be able to validate them at a later date, then you need time stamps. See this answer for some details. ...


0

It seems as though they will last until the expiration of the certificates (as in, past the shutdown of the CA) Quoting from this reddit thread IIRC, If the certs are not in a CRL, they should work until their expiration date regardless of if the CA is online. The CA will continue to function after being p2v'ed so long as the server name doesn't ...


3

Should wildcard certs be used? Generally not, and here's a good list of reasons why. Subject Alternative Name (SAN) certs provide most of the functionality without the same level of security drawbacks. Wildcards had turned mostly into a lazy shortcut for people who didn't care about security, which is why they're discouraged these days. Should wildcards ...


0

I have a feeling this is really a graph theory puzzle. -- I kinda like those. -- But this is very different from a real live PKI implementation. Anyway: here's what you could do in a real live PKI: I am supposed to add exactly one certificate so that T trusts G, but not D. Add G to T's list of trusted sites. Another certificate is searched ...


1

In a PGP setup, encryption occurs with the recipient's public key. In SSH authentication, this is (internally) a signature with the client's private key. If Alice sends a message to Bob and also connects to Carol's server, then Alice will use Bob's public key to encrypt, and here own private key (from a distinct key pair) to sign. No problem here. A ...


0

This seemed to be the command you want: openssl req -new -x509 -nodes -newkey ec:<(openssl ecparam -name secp384r1) -keyout cert.key -out cert.crt -days 3650


4

You are essentially correct in your last paragraph: Is the sole purpose for authentication purposes so that one who has a public key knows that this piece of encrypted hash information is signed by the person that issues this public key (has the private key) since he/she is able to decrypt it. Though, as mentioned in comments, and in various places ...


3

q1) Correct. Every message needs to be sent with its own signature. But if lots of information has to be sent this way, it is not very efficient because public key cryptography is rather slow. Usually the two parties would rather use a protocol allowing to share a secret, then use symmetric-key authentication, like a message authentication code (MAC). q2) ...


2

It might be least-problematic to set up a new root CA for Department-New for dev work. On their machines install both root certs (rootCA-general and rootCA-dev) into the trust store, on everybody else's machines only install rootCA-general.


0

What are you using the certs for? You can constrain the certs at at an intermediary using EKU policies (HTTPS vs Email vs SmartCards) Name Constraints The combination of above might accomplish what you're looking for


-2

I don't know any standard techniques, but the closest I can think of is the folowing: If Bob has a public key publicly available, Alice can use it to encrypt the secret message, then send him a link to a specific, detailed stenography technique, in the "hey, look what's interesting" spirit, applying that same technique for embedding the encrypted secret in ...


-3

Yes. You have only been searching for the wrong term. This is called subliminal channel.


13

This is the first I've heard of keyed steganography, so I'll recap the article you linked, for the benefit of others who might be confused about it. They have narrowed down the number of steganographic algorithms they're analyzing quite a bit. The message must be embedded in a JPEG image (perhaps any raster image format?), and it can't utilize the entire ...


-2

How about this: Encrypt message with random symmetric key. Check randomness of resulting cyphertext, if it is distinguishable from noise, try another random key. Encrypt key with public-key of Bob Hide encrypted key + message with steganography. When the eavesdropper intercepts the message and uses steganography, he will only get the encrypted message ...


2

A cyphertext generated with a proper encryption algorithm is indistinguishable from random noise. That means with most steganography methods, cyphertext might be harder to detect than paintext, because statistic analysis does not work. However, the details depend on the steganography method used. Implementations vary greatly. For example, it might be ...


6

"One of the draw backs of traditional steganography is that both parties need to exchange a secret key." No, steganography does not require any key (symmetric or asymmetric) as it doesn't use encryption at all. The real drawback of steganography it's that it is just security by obscurity; you hope the adversary won't discover the hidden message (or that ...


23

One of the draw backs of traditional steganography is that both parties need to exchange a secret key. Don't infer from the implementation of one specific tool to the limits of steganography itself. Steganography is just the hiding of information within other data. It does not matter if the information you want to hide by itself are unencrypted, rot13, ...


2

You've got a plaintext that you want to send me. Encrypt it with my public key first to generate the ciphertext. Then, using absolutely standard steganography interleave the bits of the ciphertext into the carrier: images, music, and so on. Had you not used public-key encryption then you'd just intermingle the plaintext into the carrier. To the steganograpy ...


0

It is unclear what you are asking but you should not send private keys over unsecured channels. As others have stated they are called "private" for a reason. There are tools that are windows compatible for generating keypairs. That being said if the communication method is secure you can transfer private keys. An example would be to generate keypair on ...


0

You should keep the private key on the machine it was generated on. As Aron mentioned, by doing so, you are turning it in to a symmetric key. Instead, I would generate a private key per machine that needs one. With Windows, as Tara Hodges mentioned, you can use PuTTY and Pageant. This will allow you to generate keypairs on Windows too. However, there's one ...


0

Your ssh private key will allow anyone, that has file permissions to read it (and know the optional password) to act as you: log in to any server that trusts your key etc. If you need to store your private key outside your personal computer, be sure to at least protect it with strong password and check the server for visible signs of rootkit infection, to ...


4

I wouldn't. Private keys are meant to be private, the intention is that you protect the private key intensely and provide the public key to whichever other party needs it (which can be used to decrypt the information encrypted with your private key). This is the beauty of PKI. If you're concerned about generating a keypair on Windows, use PuTTY. It's got a ...


2

If the protected system is not that critical, yeah sure. Go ahead. But do take note that whatever that key is guarding, it's effectively being replaced by your passphrase. Think of a vault being replaced by a cash box. You should take responsibility in the event that the passphrase somehow leaks (as a result of being drunk, torture, etc.)


8

Compare putting the encrypted private key onto some untrusted storage with putting the unencrypted one into an encrypted container like TrueCrypt or LUKS. Technically, the result is pretty much the same, apart from OpenPGP meta data being visible for the encrypted private key. Your key is as secure as the symmetric encryption algorithm applied for ...


2

It depends, but probably not. Even if the passphrase is sufficient, you can use weak or insecure algorithm to encrypt the private key. Then, we also need to assume that the key have some validity period. The validity period must not be longer, than it would take to crack the algoritm. We also need to assume that Dropbox can make a copy of it, so the ...


1

Well the issue here is that Microsoft should have updated their Root Certificate Program member list PDF document and notified their corporate and government customers at the very least, which they haven't. Also, SilverlightFox is wrong: you cannot "simply check your Windows OS's certificate store for root certs.", as this only provides a list of currently ...


0

I found the answer from (RFC2818) http://tools.ietf.org/html/rfc2818#section-3.1 According to rfc If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is ...


3

No, new root certificates are added on a regular basis. Microsoft have a Trusted Root Certificate programme enabling CAs to enroll. This happens with most products that handle certificate verification. For example, this is Mozilla's list where you can see that there are several added per year. For Microsoft's list you can simply check your Windows OS's ...


3

The simple answer is no you can't have an RSA cert which has a ECC public key. By definition an RSA cert is a cert which has an RSA public key. The CA could sign your ECC cert with their RSA key but that wouldn't make it a RSA cert it would make it a ECC cert signed with an RSA key. Likewise a CA could sign a RSA cert with their ECC key but that wouldn't ...


3

Yes the hostname on the cert must match the hostname portion of the url the cert is requested from. That is a requirement because there is an expectation that SSL not only secure the communication (encryption) but also ensure the user is connecting to the proper server (authentication). Without that requirement it would be trivial to spoof users with a ...


0

Mike Scott posted a great answer. But it might be worth noting why it matters. On a technical level your data will still be encrypted. However your users might be turned away because they can't trust the certificate as most browsers will warn them of the error and usually make them perform extra steps through warning messages. The messages are made to look ...


10

First, it's not a URL, it's a host name or domain name. The host name is one part of the URL. http://security.stackexchange.com/questions/92838/is-it-neccessary-the-website-certificate-must-have-site-url is a URL, and the host name is security.stackexchange.com. Next, yes, at least one host name in the certificate must match the exact host name used to ...


2

What you describe is https with self-signed certificates, i.e. Setup a new server with SSH, it makes it's own keys. Setup a https server with a self-signed certificate. ssh to a new server and get a new fingerprint: "This is new, accept?" Connect to the new server with the browser. You get a warning but can tell he browser to add an ...



Top 50 recent answers are included