Hot answers tagged key-generation
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 ...
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 ...
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, ...
15
You are creating something called "entropy". Random number generators within computers can, if implemented within software, only be at best pseudo-random. Pseudo-random number generators (PRNG) start with a seed. If the seed is well-known, then anyone with knowledge of the PRNG algorithm can derive the same values you derived (this is actually really good ...
12
I just answered to the same question on stackoverflow, so I will duplicate my answer here (I don't think duplication is the way to go; maybe the question should be migrated):
Let's assume that you select a prime p by selecting random values until you hit one for which Miller-Rabin says: that one looks like a prime. You use n rounds at most for the ...
12
As per the SSH standard (RFC 4251 and subsequent), a DSA key will work everywhere. In practice, a RSA key will also work everywhere. ECDSA support is newer, so some old client or server may have trouble with ECDSA keys.
ECDSA is computationally lighter, but you'll need a really small client or server (say 50 MHz embedded ARM processor) to notice the ...
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
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
Strictly speaking, a 2047-bit prime (with regards to discrete logarithm and the Diffie-Hellman problem) is theoretically very slightly weaker than a 2048-bit prime, since resistance to discrete logarithm increases with the prime size. However, both 2047 and 2048 bits are sizes in the range of "cannot break now, cannot break in 15 years either" (unless a new ...
9
Mixing the two functions would not really help. Bcrypt and PBKDF2 both have a configurable cost: you are supposed to set the number of iterations at the maximum value which is still tolerable in your situation, given the available hardware and the environmental constraints (e.g. average user patience). If you want to use both function together, then they ...
9
A salt is not a secret, it is meant to make the Hash/PBKDF2 result unique to each used instance. As far as a know, the very definition of salt requires it to be random for each computed hash. If it was password derived, two users with the same password could end up with the same verifier -> Bad.
8
It depends on how much you want to separate roles.
Basic system: your "signature" is a MAC. The "API key" is a secret value with is shared between the server and the user. Normal MAC algorithms like HMAC can use arbitrary sequences of bits as key, so a key is easily generated by using /dev/urandom (Linux, *BSD, MacOS X), calling CryptGenRandom() (Win32) or ...
7
Cryptographic keys are usually fixed-length values. Unfortunately, humans can't remember long strings of numbers, so we use passwords instead.
For example, this might be your 256-bit key:
d4f6d068b4e8c4e924ce9b28585a6009672e56d61215e7d9251b5d36283edd5d
Not too easy to remember, is it?
However, the above was generated by computing a cryptographic hash ...
7
Once you've reached the "cannot break it" zone, increasing the key size does not change security: you cannot be more secure than that. A 128-bit key is already far into the "cannot break it" zone. Larger keys are for marketing people who need to impress gullible buyers, and for military people who must, by statute, make extensive displays of their collective ...
7
Loosely-speaking, you can treat the Keyfile as something you have. You can store it on a USB stick for that sole purpose. Whenever you want to decrypt your secret file, you plug that stick and decrypt.
You can add an extra layer of security by making that USB stick a TrueCrypt volume, thus protecting your Keyfile with a password.
Of course, you can hide ...
6
It basically works like this: the server has a master key (the BDK) and each client device has a unique serial number and a counter (which when combined are the KSN).
To set up a new device you encrypt the KSN using the master key (the BDK, the process described in the link in Yoav's answer) and you get a new key (the IPEK). It's kind of like where you ...
6
Couldn't find many resources online, but I imagine this should be spec'd quite comprehensively somewhere. What I did find out however is this description of the derivation process.
If I understand this correctly, the derivation function works roughly as follows:
The KSN is normalized using some form of padding
The normalized KSN is then encrypted with the ...
6
Actually it is not that hard. It may be slightly expensive, computationally speaking.
A good DH modulus and generator is what you get when generating DSA key parameters; see the DSA specification. You get to choose the subgroup order (q, a prime number), the modulus (p, such that p-1 is a multiple of q), and a generator for the subgroup of size q. OpenSSL ...
6
A weak key for a block cipher is a key such that encryption and decryption turn out to be the same function. This means that with such a key, a black box which nominally encrypts things only can also be used to decrypt things. A semi-weak key is a key such that the decryption function with that key is identical to the encryption function with another key.
...
6
You can use match in sshd_config to select individual users to alter the PasswordAuthentication directive for.
Match User root,foo,bar
PasswordAuthentication no
Match User Rishee
PasswordAuthentication yes
This would give root, foo and bar key authentication, and Rishee password authentication.
An alternative is to match by negation, like this:
...
6
There is an experimental API for this: window.crypto.getRandomValues. I believe Chrome and Firefox support it so far.
Opera does not support this API, but its Math.Random is secure.
Opera has not yet implemented window.crypto.getRandomValues(). However,
our Math.Random() is using a cryptographically secure random generator.
If used carefully ...
6
Supposing there are no vulnerabilities in the cipher for different key lengths, and that the key derivation function generates output indistinguishable from random, with no collisions, then:
Mathematically speaking 2^256 = 2^128 * 2^128. The 2^X algebra in this case refers to the total number of unique keys, called the key space. Since each bit can be ...
6
Simply put, the problem is with the assumption you've stated.
Suppose that there are no vulnerabilities in the cipher regardless of key length.
Security is about defense in depth. Just as a safecracker isn't going to bang at a safe with a hammer for days on end, attackers aren't generally sitting around brute forcing encryption keys.
It's probably ...
6
There is no known issue with reusing the salt used in PBKDF2 for the IV of CBC encryption, and it would be mildly surprising if it did have an impact because the salt enters as input to hash functions, and the output is used as key for the block cipher. Thus, there are "two layers" between the salt and the IV. However, surprises do happen sometimes. Reuse of ...
6
The statement is weird, because it comes from a knee-jerk ritualistic reflex about key lengths.
The full text from the page is:
Specifies the length in bytes of the output that will be generated. Typically, the key length should be larger than or equal to the output length of the underlying digest function, otherwise an attacker could simply try to ...
5
DES is defined to use a 64-bit key. Only 56 of these bits are really used, so the "effective key length" (for resistance against exhaustive search) is that of a 56-bit key. Yet, any implementation will expect a sequence of 64 bits (hence, 8 bytes, not 7).
Triple-DES (aka "3DES") is three DES instances in due sequence. The "middle" DES instance is used in ...
5
SIgning a key is effectively a way of saying that you trust the key is correct and associated with a particular individual or identity (thanks @Bruno). People who trust you may then choose to trust it based on the fact that you have signed it.
Signing means you digitally sign the key certificate. You don't need it, but you will see with PGP for example, ...
5
PBKDF2 is designed exactly for the purpose you're thinking of: to make the time tradeoff for attacking a low entropy source comparable to that of attacking the resulting output as if it were a purely high entropy source.
In a contrived example, I might make my password using one of four numbers. The resulting key could be one of 32 numbers. To make them ...
5
whilst I agree with @Thomas's very thorough response above I'd like to add that I installed the root CA system for a UK banks own debit card system (each wee chip on the card is actually a certificate).
We used Thales HSM devices (6 figure £ costs) that had proper tamper proof systems for tilt, temperature, physical attack and so on.
in terms of the key ...
5
Your problem is transmission of a secret piece of data; that the piece of data is a cryptographic key is mostly irrelevant (it just means that it is really secret). Thus, what you want boils down to making sure of who gets it.
Since you talk about processes, I assume you are talking about a transfer within a single machine. "Who" then depends on the ...
Only top voted, non community-wiki answers of a minimum length are eligible
