Tag Info

Hot answers tagged

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


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


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


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


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


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


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


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


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

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


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


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


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


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


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


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


2

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


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.


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


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

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


1

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

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


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


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



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