I've added my answer here as I feel the existing ones don't directly address your question enough for my liking.
Let's look at RFC 4868 (regarding IPSec, however it covers the HMAC-SHA256 function you intend to use - em mine):
Block size: the size of the data block the underlying hash algorithm
operates upon. For SHA-256, this is 512 bits, for SHA-384 and
The reality is if other processes can access your process memory or features of your
virtual machine, the game is probably over as you're already compromised. If a process
has access at this level, it can probably gain other information, such as the initial
credentials used to authenticate before obtaining the token or just modifying
results to make token ...
I think this question can be considered from two different angles: security and convenience.
When we create a SSH key pair, we are asked for providing a passphrase to add a more layer to protect the private-key, as following:
$ ssh-keygen -t rsa -b 4096 -C 'With_OR_Without_Passwd'
Generating public/private rsa key pair.
Enter file in which to save the key (...
As gilles says DSA is risky because if you make signatures (and using your key with a ssh client to log in is effectively making signatures) on a box with a bad RNG your key can be compromised. AIUI this made Debian basically abandon DSA for keys used on their infrastructure in light of the Debian OpenSSL random number generator fiasco.
$ man ssh-keygen
It is possible to specify a passphrase when generating the
key; that passphrase will be used to encrypt the private
part of this file using 128-bit AES.
So this passphrase just encrypts the key locally. An attacker with access to your system will not be able to read the private key, because it's encrypted. (They could install a ...
The difference between using some hardware backed key store (i.e. TPM, HSM, smartcard ...) and a "pure software" solution like openssl genrsa is not so much about the security of the key generation but about the security of the key storage.
HSM and similar are designed to never actually provide the created private key but only do operations like ...
The point of hashing passwords is that if the attacker can gain access to your password file (by breaking into your server, stealing backup media, hacking your hosting provider, etc.) he/she still can't recover the password from the hash and log in as the user.
According to RFC 7518 - JSON Web Algorithms (JWA):
A key of the same size as the hash output (for instance, 256 bits for
"HS256") or larger MUST be used with this algorithm. (This
requirement is based on Section 5.3.4 (Security Effect of the HMAC
Key) of NIST SP 800-117 (sic) [NIST.800-107], which states that the
effective security strength is ...
Reading bytes from a device can be troublesome (you have to account for syscall specificities, e.g. interrupted system calls) and can potentially be inefficient if reading many small chunks (a syscall has a non-negligible overhead). A custom software PRNG, seeded with bytes from /dev/urandom, gives more control over performance.
(Also, there might be a bit ...
One of my favourite gems on encryption is from Bruce Schneier in his book Applied Cryptography.
One of the consequences of the second law of thermodynamics is that a
certain amount of energy is necessary to represent information. To
record a single bit by changing the state of a system requires an
amount of energy no less than kT, where T is the ...
128 bits of entropy are enough. The whole and only point of considering entropy is to make sure that the system can resist brute force attacks: the space of possible values must be so large that any attacker could only try a negligible proportion of the values in non-ludicrous time. There are strong reasons why 128 bits are highly sufficient for that. ...
Each bit of a key increases the difficulty of a brute-force attack exponentially but there is a trade-off. Adding more bits to the key will negatively effect the speed of encryption/decryption. The actual amount of this speed loss depends on the algorithm, for example in RSA (in theory) for a n-bit key, computational effort for encryption is proportional to ...
If you're asking why openssl rand or RAND_bytes() do not simply regurgitate /dev/random or /dev/urandom, it's because their function is to serve only as a PRNG, and they do exactly that:
The rand command outputs num pseudo-random bytes after seeding the random number generator once.
A correctly compiled and operating OpenSSL will read 32 bytes from /dev/...
Well, using simple math: If checking one key takes 1000 clock cycles, and the computer has 2,000,000,000 cycles per second, it checks 2 million keys per second. The best case is that the first key you try is correct: total time is half a microsecond. The worst case is that the last key you try is correct: you have 2256 keys divided by around 221 checked a ...
First, my apologies for the math, and for overly simplifying the math!
The difference between DHE and ECDH in two bullet points:
DHE uses modular arithmetic to compute the shared secret.
ECDH is like DHE but in addition, uses algebraic curves to generate keys (An elliptic curve is a type of algebraic curve).
The overall method in both cases is still ...
An elliptic curve is defined over a finite field of size q for some integer q. Each curve element is a point and has two coordinates X and Y, which are curve elements.
The "size" of the curve, which is the important parameter for its cryptographic strength, is close to q. It can be shown that the total curve size n is such that |n - (q + 1)| ≤ 2*...
I would not recommend combining random number generators in this way without having some underlying theory to support your case.
A simple way to illustrate the issues is to consider the behavior of low-end LCG algorithms, the popular "one-liner" schemes for generating random numbers.
These can be made to produce sequences that will pass certain statistical ...
Use RSA. Not for security reasons, but for compatibility reasons.
I don't recommend using DSA keys. As of OpenSSH 7.0, SSH no longer supports DSA keys by default. As the release notes for OpenSSH 7.0 say, "Support for ssh-dss host and user keys is disabled by default at run-time". Therefore, using DSA keys (ssh-dss) is just going to cause headaches.
It is called threshold encryption (or, here, decryption).
A well-known scheme is Shamir's Secret Sharing. It allows splitting a secret value into n shares, such that any t shares are sufficient to rebuild the secret. n and t can be chosen at will (although you will want to have n greater than t in practice). For the threshold encryption problem, you apply ...
The RFC 2104 defining HMAC functions answers this question:
The key for HMAC can be of any length (keys longer than B bytes are
first hashed using H). However, less than L bytes is strongly
discouraged as it would decrease the security strength of the
function. Keys longer than L bytes are acceptable but the extra
length would not significantly increase ...
In this post in the chromium forum there are alternatives mentioned
Within the browser space, alternatives exist such as:
Use the device's native management capabilities if an enterprise use case. On Windows, this is Group Policy. On iOS/Android, this is the
mobile device management suites. On OS X, this is Enterprise settings.
On ChromeOS, there is chrome....
If your passwords are n characters randomly drawn, with equal probability, from a set of 95 characters (which is about all the ASCII printable characters minus space), then each character gives you about 6.6 bits of entropy, so the strength of a random password with n characters is 6.6 × n. So:
A 10 character password gives you about 66-bit strength;
A 12 ...
In layman's terms, rotating an encryption key implies:
Generate new key(s)
Re-encrypt all data that was encrypted using the old key, using new key(s)
Delete old encrypted data and old encrypted key
Key rotation generally applies to data that is encrypted at rest, as opposed to something like TLS, because it reflects the need to deal with all the old stuff ...
A RSA key pair consist in the following:
The modulus n, a big integer which is equal to the product of two big prime integers, p and q.
The public exponent e.
The private exponent d. d is such that ed = 1 when taken modulo p-1, and also when taken modulo q-1.
The first factor p.
The second factor q.
The value dp = d mod p-1.
The value dq = d mod q-1.
With big numbers, Diffie-Hellman looks like this: we work modulo a big prime p, and we start with a conventional big integer g (in the 2..p-2 range). Each integer modulo p represents an achieved colour; g itself is the starting point, i.e. "yellow" in your picture.
Each paint is an integer; the range of possible paint tones is large (at least 2160). Mixing ...
What is the exact meaning of “Keying material”?
Keying material is a more general and fancy term for "secret keys of (unspecified) format, length and amount", where the "unspecified" part may be clarified depending on configuration or is just outsourced to other sections of the paper.
It is this general to include things like shared ...
Basically, you can't.
What you look for is DRM by any other name, and history has shown time and time again that DRM isn't effective. Any skilled attacker in possession of the binary is therefore also in possession of the key, regardless of how well you hide it.
Even if you were to store the key on your server and load it dynamically from the internet, the ...
No, do not roll your own, this does not work and is much more insecure than any established and reliable cryptographic system. This is not a one time pad, it is an incredibly weak randomly generated password being used for a key derived pad, which is not a one time pad at all and has no more randomness (and quite possibly less) than the original key that ...
There are two levels:
You need some hashing as a second line of defence, so that what you store on the server (I call "server" the system which does the authentication by verifying a given password) is not sufficient to actually impersonate users. This avoids escalation of a partial, read-only breach (e.g. stolen backup tape) into a more complete, read-...
There are several points to take into account:
"Key size" is not necessarily flexible. In symmetric encryption algorithms (e.g. AES), a key is "a bunch of bits" that must have a specific length. AES itself is not one algorithm but a family of three, who accept keys of, respectively, 128, 192 and 256 bits. No other key size will fit in.
Implementations can ...