Tag Info

Hot answers tagged

144

Go with RSA. 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 ...


134

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


67

I like to store mine on paper. Using a JavaScript (read: offline) QR code generator, I create an image of my private key in ASCII armoured form, then print this off. Note alongside it the key ID and store it in a physically secure location. If you have a large key or lots of keys I recommend paperbak, although be sure to write down instructions on how to ...


46

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


37

This is Brian Spector; I'm the CEO of CertiVox. Thanks for starting this discussion on PrivateSky, our secure information exchange service. I’ll do my best to answer the intelligent comments and criticisms on this thread. Second, I’ll try my best to walk the reader through step by step on how our integrated key management and two factor authentication ...


34

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


32

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


32

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


27

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


27

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


27

Right now the question is a bit broader: RSA vs. DSA vs. ECDSA vs. Ed25519. So: A presentation at BlackHat 2013 suggests that significant advances have been made in solving the problems on complexity of which the strength of DSA and some other algorithms is founded, so they can be mathematically broken very soon. Moreover, the attack may be possible (but ...


25

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


25

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


23

Some technical factors that may be relevant: Performance - across whatever matters for your application (if any): encryption/decryption/key generation/signing, symmetric, asymmetric, EC, ... Scale: Is there a limit to the number of keys it supports, and could that limit be a problem? How easy is it to add another HSM when your application becomes more ...


22

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


22

In general, one key per identity should be fine. One key can include: Several UIDs (for separate mail addresses, ...) Several subkeys (for different devices, so you can put some subkey on your mobile, if it gets lost, revoke only this) Advantages: Less hassle when signing keys, interacting with keyservers, cross signing your keys Less hassle ...


21

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


20

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


18

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


18

It depends on your definition of "compromise". The main concern is privacy, for which parcimonie and tor are solutions, as noted below. But first lets look at data integrity. The notion of "end-to-end" security is most helpful when it covers the actual application you have in mind for the data. Since the objects moved around by the OpenPGP HTTP Keyserver ...


18

Another important advantage of RSA over both DSA and ECDSA is that you don't ever need a secure random number generator to create signatures. To generate a signature, (EC)DSA needs a value that has to be random, secret/unpredictable and can never be used again. If one of those properties is violated, it's possible to trivially recover the private key from ...


17

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


17

A "wildcard certificate" is a certificate which contains, as possible server name, a name which contains a "*" character. Details are in RFC 2818, section 3.1. The bottom-line: when the server certificate contains *.example.com, it will be accepted by clients as a valid certificate for any server whose apparent name matches that name. In the certification ...


16

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


16

What you do is the following: Generate a long key (this is just a randomly generated amount of bytes in hex, you can use 128 bytes) You use this key to encrypt your file with AES (meaning you use it as a password) You encrypt the key itself with AES using your password (which is a bit shorter but easier to remember. Now AES requires this again to be either ...


15

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


15

You can use Match in sshd_config to select individual users to alter the PasswordAuthentication directive for. Enter these Match rules at the bottom of sshd_config file ( generally /etc/ssh/sshd_config ) Match User root,foo,bar PasswordAuthentication no Match User Rishee PasswordAuthentication yes This would give root, foo and bar key ...


15

A HSM will not avoid complexity; rather, it will add quite a lot of complexity to the whole system. What HSM do best is key storage: the key is in the HSM and does not get out of it, never. However, you still have to worry about the key life cycle. With a "software" key, stored in a file or in the entrails of the operating system, backups are a ...


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

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



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