Hot answers tagged keys
20
The public key blob doesn't consist of just the numbers that make up the public key: it begins with a header that says “this is an SSH public key”. The repeated prefix encodes this header.
RFC 4254 specifies the encoding of public key in SSH key format.
The "ssh-rsa" key format has the following specific encoding:
string "ssh-rsa"
mpint e
...
10
It's not a security problem but a necessary feature. It's not an exact science to distinguish a "good decryption" from a "bad decryption". What if the user had encrypted random data? you would not be able to figure out if the key is correct or not from that sole information, since in both cases the decrypted output would look completely random!
Similarly, ...
7
Sure, use AES with a fixed key. Since the key is fixed, it could be considered keyless in the traditional sense. Someone with only access to the ciphertext could not crack it as long as you use a good mode (say GCM, CCM, or EAX) using proper nonces, IVs, or whatever else is required.
This is security by obscurity as the plaintext is only as secure as the ...
6
First off, many block modes of operation require a message to be padded so that its length is evenly divisible by the block size of the cipher. CBC mode (Cipher Block Chaining), for instance, typically pads a message either with an entire block of zeroes if it happens to be exactly divisible by the block size, or with a given number of bytes that will extend ...
5
Lets take your idea to the extreme to see its weakness. For simplicity I'll scale things down. Let's assume an 8 bit key chosen randomly. Call this key $k$. If I break into your database and get $d=H(k,s)$ along with $s$ (where $H$ is a hash function and $s$ is the salt), it would take on average $2^{8-1}=2^7=128$ computations (or calls to $H$) to find $k$.
...
5
If your alphabet (set of all possible characters) has size $s$ and your password has length $l$, a randomly generated password has a strength of $\log_2s^l = l\cdot\log_2s = l\cdot\frac{\log_{10}s}{\log_{10}2}$ bits.
This means if you want to create a 128-bit password using a 80-character alphabet, you need at least ...
5
By using padding, one can tell if the decryption is correct. Padding is used when the message length is not a multiple of the block size. You append predictable data at the end of the message (one "1" followed by several "0" for example) and then you encrypt it. If you find the correct "1000..." sequence at the end of decrypted message, it means it's ok.
...
5
No, your formula isn't correct. I don't know how you came to it, so I don't know what's wrong with your intuition.
You can check whether your formula makes sense with dimensional observation — it's the same kind of reasoning that helps a lot in physics. Write all numbers with their units:
entropy rate = 1.5 bit/character
random key size = 128 bits
...
4
No, Quantum Key Distribution is not any safer than conventional crypto is against an active Eve impersonating as Bob to Alice using the same equipment and knowledge as the rightful Bob (or/and impersonating as Alice to Bob using the same equipment and knowledge as the rightful Alice). Otherwise stated, QKD can resist Man Eve In The Middle only inasmuch as ...
4
A key, in the context of symmetric cryptography, is something you keep secret. Anyone who knows your key (or can guess it) can decrypt any data you've encrypted with it (or forge any authentication codes you've calculated with it, etc.).
(There's also "asymmetric" or public key cryptography, where the key effectively has two parts: the private key, which ...
4
The three terms (key, IV, nonce) you mentioned, and another, the salt, basically describe random numbers and each term is used in another context. The key is used as input for a cryptographic primitive and should be kept secret.
A nonce is a random number only used once and for a short time with the intention to get replaced by or converted into something ...
4
We often mock "security through obscurity", but it is not without value, especially in today's web environment.
Most attacks today are statistical in nature: a virus attempts to infect 10,000 computers by blasting out random attacks. If it infects even two more computers out of those 10,000, it has achieved its goal.
Those viruses are aggressive in ...
4
If all the components share the same certificate, then they share the same private key. This raises the two following points:
When a secret is shared by more than two people, can it still be considered really secret ? Secrecy dilutes fairly fast. If all components share the same secret value, then breakage of any single component reveals the private keys ...
3
At a purely technical level, having the two group elements and secret exponents enables a proof, in the random oracle model, that the scheme is CCA secure assuming that decision Diffie-Hellman is hard. For regular (hashed) ElGamal, we only know how to prove CCA security in the random oracle model under a stronger assumption (in our paper we called it strong ...
3
Yes, these are key derivation functions basically deriving a shared secret from information identifying the two parties (like their respective MAC addresses) and nonces and other session communication relevant information. See e.g. the PBKDF2 derivation function.
3
Have a look at the corresponding paper.
The key is a 128-bit string $K$. The round keys for round $r=1,...,8$ are derived as follows:
take the version of $K$ cyclically rotated to the left $25\cdot r$ times;
split the string obtained into eight substrings and call them $Z_1^{(r)}$, ..., $Z_8^{(r)}$.
The keys $Z_7^{(r)}$ and $Z_8^{(r)}$ are never used. ...
3
The usual meaning of signature (in cryptography) is this:
Bob has a pair of keys, a public and a private one. The public one is known to Alice, too. (And to any possible attackers, too.)
Bob wants to send a message to Alice.
Bob does some operation with the message and his private key (he signs the message), and obtains a signature.
Bob sends message and ...
3
Whenever you have information to hide, something related to protecting it needs to itself be hidden. There needs to be some secret involved, and there needs to be some system of using the secret to achieve the desired security goal. The difference between the practice of keys in cryptography and Security by Obscurity is how they treat the relationship ...
3
Well, whether it would be safe to use the same keys to encrypt and to decrypt depends a great deal on the ciphersuite. In particular, TLS supports ciphersuites where it would cause a serious security problem; hence TLS was designed to have different keys in two directions (so that it could use those ciphersuites safely).
In particular, the RC4 encryption ...
3
An analogy often given to security through obscurity vs encryption is the following: The former is hiding a letter somewhere and challenging someone to read it. The latter is picking a key from $2^{128}$ keys, locking it in a safe and challenging you to read the message. If I've understood you correctly, your question in terms of this analogy is the ...
3
Sure. Assuming that you're using the encoding $A = 0$, $B = 1$, etc., just choose your plaintext messages to be the one-block strings:
$$
BA \dots A \\
AB \dots A \\
\vdots \\
AA \dots B
$$
The encryptions of these strings will then directly give you the columns of your key matrix.
3
The write up on Wikipedia is pretty good. I won't go into all the detail that they do there, but your private key is a randomly selected integer $d_A$ selected from $[1,n-1]$ where $n$ is the order of the group. The public key is $Q_A=d_AG$ where $G$ is the base point on the curve defined in the publicly agreed upon parameters.
3
Take the following points into consideration:
A 32 character password composed of 95 ASCII characters only has $\log95^{32}\approx 210$ bits.
As long as there are no quantum computers (which would reduce the key strength to 105 bits), that's not a practical problem.
Not taking the previous point into account, if your password really gets generated ...
3
The point of a KDF is to take a low-entropy input and significantly increase the amount of computational power (and thus time or cost) it requires to brute-force, hopefully to a level on-par with a truly random value.
If you're already using a 256-bit value generated from a CSPRNG, there is no need to use a KDF.
In fact, using a KDF can only reduce the ...
3
There are two forms of entropy here at work. First there is "uncertainty" entropy from the user password which is typically very low (on the order of 20 to 40 bits for most passwords out there). And then, there's "computational" entropy, which is artificially obtained by forcing an attacker to do work to calculate keys.
Essentially, if you run your KDF for ...
2
Short story: Ultimately, your question comes down to a question of the quality of the Windows RNG. Your approach is fine if your RNG is good, but you're trusting the largely opaque Windows RNG to give you a perfect 32 bytes of entropy. I would recommend generating more bytes and then using a hash or KDF to compress it to 32 bytes.
Slightly longer story: All ...
2
The attacker can distinguish $\langle C_1, C_2 \rangle$ from a random pair if the attacker knows a value $q < p-1$ such that $g^q = 1 \mod p$.
Here's how the distinguisher would work: he simply computes $C_1 ^ q$ and checks to see if that value is 1. If this $C_1$ corresponds to a valid ciphertext, then that value will always be 1. If this $C_1$ is ...
2
RFC 5958 and RFC5959
seems to be the latest standard for storing encrypted private keys.
It obsoletes RFC 5208, also known as PKCS#8.
My understanding is that AES is one of the many encryption algorithms supported by RFC 5958.
The GNU Keyring File Format is a another standard for a file format that stores private keys using AES-128.
The Gnome Keyring ...
2
Sure. Needham-Schroeder (e.g., Kerberos) solves exactly this problem. If each party shares a key with a trusted party Trent, then it provides a protocol that Alice and Bob can use to establish a session key good for use for encrypting traffic between the two of them. Kerberos v4 uses this in a purely symmetric-key setting: no asymmetric (public-key) ...
2
Instead can't we generate object specific keys "on the fly" using HKDF using a master key and object id as inputs, so that we dont have overhead of storing and managing keys each time?
Sure you can. I've got an even easier method. Just use the same key for everything. No key derivation or key management needed. Or even better, don't encrypt anything. No ...
Only top voted, non community-wiki answers of a minimum length are eligible
