Hot answers tagged key-management
111
Serious certification authorities use heavy procedures. At the core, the CA key will be stored in a Hardware Security Module; but that's only part of the thing. The CA itself must be physically protected, which includes proactive and retrospective measures.
Proactive measures are about preventing attacks from succeeding. For instance, the CA will be stored ...
46
DSA is faster for signature generation but slower for validation, slower when encrypting but faster when decrypting and security can be considered equivalent compared to an RSA key of equal key length. That's the punch line, now some justification.
The security of the RSA algorithm is based on the fact that factorization of large integers is known to be ...
31
My answer is that using public key pairs is a much wiser thing to do than using passwords or lists of passwords. I will focus on things that are not widely known about different forms of SSH authentication, and I see no other answers mentioning them.
First of all, you must understand that user authentication is a different and separate process than the ...
20
On the physical side they first keep the root CA completely offline. Typically what happens is that they set up the root CA, make subordinates, then take the root CA completely offline and take the hard drives and HSMs (sometimes even the whole server) and essentially lock them in a safe.
Next, they segment the network to keep those subordinate/issuing ...
19
The chance is very much lower than any of these events:
The computer spontaneously catches fire during the key generation process.
Great Britain is wiped out by a falling asteroid during the very same second.
A rogue gorilla escaped from a zoo enters your living room and mauls you.
You win millions of dollars at the lottery three times in a row.
So the ...
17
Simple explanation
The only way this will ever happen is if you give someone your private key. It will never happen by random chance. Never. You'd have a better chance of winning the lottery twice, getting struck by lightning and being mauled by two gorillas all in the same day. Instead of worrying about generating a private key that someone already has, ...
17
I would say that their suggestion isn't a very solid one, unless you're using horrifically small key sizes - in which case you have a different problem altogether.
A 2048-bit key, by most estimates, will keep you safe until at least the year 2020, if not longer than that. If you're running with 1024-bit keys or less, you're below the standard, and I ...
16
"I have absolutely no experience with security and encryption": Yikes. It is probably not the best idea to be designing new cryptographic schemes, given this sentence, if security is important for your application. Cryptosystem design is a tricky subject. Folks who try to invent their own schemes without knowledge of the field often make non-obvious ...
14
Public/Private key crypto is used in a wide variety of protocols and data formats, which are implemented by a huge range of application and system software:
SSL (https) protocol
SSH (secure remote login, tunneling, etc) (public/private authn/authz is optional)
Digitally signed PDF files (including attachments within the PDF)
Signed Applets and jar archive ...
14
There is no risk of exposing your private key, or invalidating your public key, by publishing your public key in the ways you and @Mark described. As @pboin stated, it is designed to be available to the world.
However, there is another issue at hand... One of the core purposes of having and publishing your public key (indeed, this is probably THE MAIN ...
14
You are best to distribute your key is using one of the key servers that are available such as http://keyserver.ubuntu.com:11371/, http://pgp.mit.edu/ and https://keyserver.pgp.com.
If you use seahorse (default key manager under Ubuntu) it automatically syncs your keys to one of these servers. Users can then lookup your key using your email address or keyid. ...
14
Since Java 6, you can import/export private keys into PKCS#12 (.p12) files using keytool, using -importkeystore (not available in previous versions).
For example:
keytool -importkeystore -srckeystore existing-store.jks -destkeystore new-store.p12 -deststoretype PKCS12
The PKCS12 keystore type is also supported as a standard keystore type in the default ...
13
In SSH, on the client side, the choice between RSA and DSA does not matter much, because both offer similar security for the same key size (use 2048 bits and you will be happy).
Historically, version 1 of the SSH protocol supported only RSA keys. When version 2 was defined, RSA was still patented, so support of DSA was added, so that an opensource ...
13
There isn't a good answer. But here are your possibilities:
Tie the encryption key to your admin login (e.g. encrypt the the encryption key with your admin login). This is only marginally useful as it requires you to be logged in in order to encrypt/decrypt anything. But on the plus side, no one can encrypt/decrypt anything unless you're logged in (i.e. ...
12
A general solution is to upload it to a keyserver. Another good idea might be to make an entry at Biglumber. This helps to get in contact with other people and maybe to sign each other keys.
Furthermore you should have a look into your inbox and look for contacts who already sign their emails. You could send them an informal mail, that you now have a key ...
12
While some good information has been provided in previous answer, there is a critical design flaw, which is not really noticed - but comes from some of the implicit assumptions in the question.
The difference should not be between:
Web app and DB on same server
Web app and DB on different servers
application vs. db encryption
The design should ...
12
With a proper TLS-with-AES session, the time needed for an eavesdropper to "decrypt information" would range in centuries, at least if the "enough resources" are limited to, say, converting the whole mass of Jupiter into energy. At that time I am pretty sure that the involved computers will have turned into a compact mass of rust, so the point is kinda moot. ...
12
Changing the private key is not a best practice, it is a widespread practice; it has in fact very little to do with security, and a lot to do with how common CA handle certificate renewals, i.e. most of the time like a new certificate, with a new private key generation. It is simpler, on the CA side, not to do anything special for a renewal. Hence the habit ...
11
Symmetric encryption does not provides integrity. The amount of control that an attacker can have on encrypted data depends on the encryption type; and some specific details of some encryption modes can make the life a bit harder for the attacker if he wants to make surgical modifications. With CBC, the attacker can flip any bit he wishes, provided that he ...
11
They said encryption of the whole data would cost more and is expensive (in term of performance).
This is correct. RSA, an asymmetric key algorithm needs a lot more computing power/time to encrypt/decrypt data compared to a symmetric key algorithm like DES/3DES.
Asymmetric key algorithms are usually used as a means to communicate a key for use in ...
11
The public key is public, meaning that everybody can know it without endangering security. No problem in putting it in an email, then.
The potential issue would be an active attacker modifying the email while in transit, to replace your public key with his public key. To guard yourself against such attacks, compute a fingerprint of the file you are about to ...
10
This quickly turns into a 'turtles all the way down' problem. You just have to decide at which point you stop encrypting things and rely on another method. I think the goal should be to stop casual users, but not determined hackers, to easily get at the protected data.
I wrestled with a similar method in a web application which needed to store the DB ...
10
Compared to a stored list of (long and random) passwords, a stored SSH private key offers the same security: things are safe as long as your private file remains private.
The private key, however, is much more convenient, both practically (right now, the SSH clients support it out-of-the-box, contrary to a custom file of passwords which you must use with ...
10
If I understood what you're saying, you're describing what is known as "Known-plaintext attack".
Modern ciphers are not susceptible to this kind of attack.
Quoting Wikipedia:
Modern ciphers such as Advanced
Encryption Standard are not
susceptible to known-plaintext
attacks.
Of course, Bruce Schneier can break AES. Without knowing the ...
10
Anything which is encrypted with PBE (as in "Password Based Encryption") can be the subject of an offline dictionary attack (i.e.: the attacker tries potential passwords). This is a worry unless you have a super-strong password, which is not as easy as it can seem because you also have to remember it, and to type it regularly (if you note it down somewhere, ...
10
It is bad practice to spread the same private key across multiple servers providing different service: Any exploited security issues in any service will reveal the private key used for everything.
But it is common to use wildcard certificates to isolate user contributed web content in user specific subdomains to leverage the same origin policy. The same ...
10
If someone gets access to your private key, he can decrypt messages encrypted for you and sign messages in your name. So he basically can do everything, you can do with the key pair.
Although there had been bugs in the past, it is reasonable unlikely that someone else will generate the same key pair.
The main risk is, that the private key gets stolen by ...
10
According to the white-paper they use SK-KEM, which is an identity-based encryption scheme. This explains why you do not need the public key of B in order to send an encrypted message to him (the email-address is the public key).
Usually identity-based encryption relies on a trusted third party. So their claim that they cannot decrypt the messages ...
10
Not every CA (government, commercial, or private) stores private keys the same way. Most legitimate operators use a HSM. It's possible that the vendor publishes CRL revocation lists using a one way link from the root to the SubCa. (Transmit-only serial cables, audio cables, QR codes, Ethernet with only a few pins connected.... etc.)
To get specific then ...
9
The cold boot attack can be limited by setting an EFI password, so that the attacker can't get to the memory during the limited time window following a reset. Notice that if the firmware password is set, the FireWire device driver disallows DMA requests which is another very similar (and IMO more likely) attack.
The key place where the password should be ...
Only top voted, non community-wiki answers of a minimum length are eligible
