Tag Info

New answers tagged

0

I think you need to decide do you want to encrypt the whole Db, or do you want to Encrypt Each record individually. Encrypting the whole Db - is easy to accomplish. There are various mechanisms that you could implement. This mechanism provides good protection from being hacked/db stolen, but will be easy for your IT staff to read/steal the data. Encrypting ...


1

Advantage of Using Subkeys Using subkeys has the main advantage that in case you have to revoke them, you're not losing all reputation in the web of trust do not have to exchange new keys with other participants you're communicating with. For example, if you stored your subkeys (and your public primary key, not your secret primary key!) on a mobile phone ...


1

Usually when generating keyrings the program will generate both an encryption key and a signature key in the public keyring. If you run gpg --edit-key KEYID it will probably show usage: SC and usage: E for your key and subkey respectively.


3

The option names are not part of the SSH protocol; they are specific to a given implementation. I suppose you are talking about OpenSSH. As per the documentation: RSAAuthentication Specifies whether pure RSA authentication is allowed. The default is “yes”. This option applies to protocol version 1 only. So this does not apply to your case, ...


1

In the end, is your quesiton: "Should I encrypt my Private Key when I email it to myself, or backup on cloud storage, or some other place?" Then the answer is yes--absolutely encrypt your PGP Private Key before "backing it up" some place, (encrypt pre-generated Revocation Certificates as well). An example to create an encrypted ASCII Armor .gpg file, ...


2

Theoretically, you could apply the following method: Delete all root CA certificates except the ones that are absolutely needed by Windows itself, as indicated here. Install the current list of trusted root CA from the current package. Note that validation of this package requires that you still trust one of the "necessary" root CA, which is why you must ...


0

If you do decide to use asymmetric crypto alone, you must include some randomness in each message. If you don't: Suppose an eavesdropper captures a military communication and he knows the message will be one of two things: Attack from the East Attack from the West Although he can't decrypt the message, he knows the public key, so he can try encrypting ...


3

If you have messages to send, and you use an asymmetric encryption algorithm, and that algorithm happens to be able to process each message wholesale because the messages are small enough, then indeed you can design the protocol without any recourse to extra symmetric encryption. However this may lose some flexibility, and have a non-trivial performance ...


3

PKCS#8 is a flexible standard; it is a syntax for encoding private keys with optional password-based encryption. The security level that can be achieved depends on the algorithm used to convert the password into a key, and the cryptographic algorithm that works with this key. PKCS#5 defines a number of combinations of password-based key derivation and ...


0

An alternate approach and a legitimate one is to simply use a random Class 4 UUID1. This way you detach your keys from any changes in material circumstances and any shifts in your privacy attitude in your personal or professional life. If you intend to use key servers so that people may contact you securely from the onset (instead of sending a signed ...


3

I believe that I'm now safe from all phishing and pharming attempts. Since only few CAs can issue such "green bar" extended validation (EV) certificates you are mostly right if you trust EV certificates. It might still be possible that the CA got hacked, like done with Comodo and DigiNotar in 2011. It is not possible for an attacker to just add a new CA ...


4

It's possible but highly unlikely: An attacker could have created a fake certificate based on compromising a CA certificate or reverse-engineering an valid one. These are both believed difficult, which is why the system is believed secure, but they have happened before. Typically, once the extent of the compromise is known, your OS or browser developers ...


2

The protection is called "luck". The probability that such an event occurs are sufficiently low that it can be neglected. Provided that the RSA keys are generated properly. In 2012, some researchers made an interesting study in which they collected 11.5 millions of publicly available RSA keys (e.g. keys from SSL server certificates). They found that some ...


1

Native certificate-based authentication is available in unmodified upstream OpenSSH. It is not, however, based on x.509. First, generate your CA: ssh-keygen -f ssh-ca Next, install your CA key in .authorized_keys with a cert-authority prefix: echo "cert-authority $(<ssh-ca.pub)" >>.ssh/authorized_keys From that point, whenever a key is ...


10

Probability. When generating a 1024-bit RSA keypair, one of the first jobs is to pick a pair of primes p and q such that the product of those numbers (i.e. p multiplied by q) is 1024 bits in size. The simplest way to do this is to pick both values to be somewhere around 512 bits in size each, as 2512 × 2512 = 21024. Note that I'm picking 1024-bit as ...


1

Basically, statistics. The chances of generating two identical private keys in an environment with good randomness are effectively nil.


0

I'm probably a few years late but anywasy... One problem that comes to mind is that a mitm can prevent the client from negotiating for multiple certs and only get the one they hacked from a CA. The easy solution IMO is to use another port or just make up another protocol name so that the client KNOWS it should get MORE THAN ONE certificate.


-1

I'm fairly certain SHA-1 will be deprecated by most OS's by 2017. Especially with browsers taking the initiative and flagging certificates secured by SHA-1 by mid 2016 and Google's project Zero cracking the whip on implementing encryption over the web. The issue here isn't about connectivity. It's about pressuring network administrators/device ...


1

I think you're putting two encryption forms together and getting confused. First you need to look at encryption in two ways encrypting data and encrypting a tunnel. Encryption of data is done at the endpoint before the information is send over the wire. This can be done using Symmetric or Asymmetric encryption. Symmetric encryption is an exchange of the ...


1

A man-in-the-middle attack, by definition, involves impersonation. The basic idea is something like this: Alice wants to have a conversation with Bob. Mallory tricks Alice into sending the first message to him instead of Bob (exactly how can vary greatly). Mallory contacts Bob, pretending to be Alice, and passes on Alice's message. Bob replies to ...


1

The answer to your question is: no. MiTM is done to steal information that the user THINKS they are sending to a legitimate site. HOW it accomplishes this usually involves "impersonating" whatever party you're trying to send your data to, and sometimes involves traffic decryption (although most of the time, decryption isn't feasible without some sort of ...


1

It depends. With some ciphers, it is possible to passively eavesdrop the communication once you have the private key. It may be done even for connections wiretapped before you obtained a copy of the private key used. However, for another class of ciphers, those providing forward secrecy (PFS), the client and server generate a new ephemeral key for the ...


2

Generally the main use for MitM at the moment is for the attacker to impersonate the website to the victim. The aim being, usually, to get hold of the victim's credentials in order to impersonate them, authenticate correctly to the website and make off with the contents of their bank account, data store, intellectual property etc. This is done, typically, ...


0

If a Commercial CA believe they are compromised they will revoke the sub-CAs that they believe are affected. This does not mean that all software that trusts that CA will automatically distrust the compromised CA. Browsers for example should check a certificate revocation list (CRL) before trusting a certificate chain. However, these checks are ...



Top 50 recent answers are included