Tag Info

Hot answers tagged

17

Examining his claims about "Thundercloud": You can use it with "any existing software, operating system, or device" (a massive amount of effort---by whom?) Has its "own cryptographic language that is completely independent of any existing security technology" (this is a negative thing: abandoning the entire knowledge base of cryptography is incredibly ...


11

An encryption algorithm does not need a keyspace. By definition, however, it has one. It sound to me like your confusion is mainly terminological. In cryptography, the "keyspace" of an encryption system is defined simply as the set of all possible (distinct) keys that the algorithm can accept. For example, let's say that we're back in the days of the ...


8

Definitions In RSA, an encryption key is a pair of integers $(N,e)$ with $N$ the product of $m\ge2$ distinct odds secret primes $r_i$ (with $0<i\le m$), and $e$ is such that $\gcd(e,\lambda(N))=1$ where $\lambda(N)=\operatorname{lcm}(r_1-1,\dots,r_m-1)$ is the Charmichael function. It follows that $e$ is odd. Typically, other conditions are added, like ...


8

...wouldn't key still get repeated every few hours or so - i.e. you come to the end of the PRG(K)... This is where you are mistaken. Modern cryptographic PRGs simply do no repeat within any conceivable time frame. That is, starting from a seed, a well-constructed PRG (and this is true even when they are not so well constructed, like RC4) will simply ...


5

Key length is the length of the key. It's a term whose meaning has evolved over time; these days, it typically means length in bits. With digital symmetric ciphers, it's fairly simple, because those tend to have a key that's just a string of some number of bits, and any string of that length is a valid key. With RSA, it's more complicated - the key has a ...


5

Sorry for the late answer, I got busy... So, you know that $\mathsf{Gen}$ is a probabilistic algorithm. What's a probabilistic algorithm? It's an algorithm which, during its execution, can make some random choices, which can be modeled as coin tosses. In programming terms, the algorithm can use a special coin-tossing function, which returns $0$ or $1$ each ...


5

There are two things here: Encryption uses mode of operation, and not "AES alone". Some of them are randomized by an initialization vector - that means the encryption of the same text under the same algorithm is still randomized and not deterministic. The encryption methods take care of that. You only need the correct key to decrypt. Passwords are not ...


5

If we take some randomly generated key of AES-128 and we change any random 1 byte of that 16 byte key, will this make huge difference in the AES cipher text generated over same input string? Yes. The outputs with different keys differ greatly. If you pick two random keys the outputs must look completely uncorrelated, or an attacker could gain an ...


4

Am I going to regret posting this? There seems to be enough non-classified information available about GPS to answer this question. I see 3 reasons why P(Y) encryption is different and less likely to be hacked than game console encryption: Hardware containing the GPS decryption key is more difficult to obtain than hardware containing the game console ...


4

Yes, he is full of crap. If you go to KeyLength, you can compare key lengths for different cryptosystems and see how long they're expected to be secure for. It's just a performance vs security tradeoff that implementers make. Most people don't see the point in schlepping around megabytes of key material for cryptosystems that are expected to be secure ...


3

A keyspace is the set of all possible keys; it's a set. The cardinality of the keyspace is an integer, and is the number of elements in the keyspace. There is no possibility of confusion, because one is a set and the other is an integer.


3

Simply put: No. First recall that this is a mis-use of the term "One Time Pad" So lets call it a Vigenère cipher instead. You can determine this is insecure with a simple algebraic combination: $ \text{attack} = cipher_1 + cipher_2 + cipher_3 + cipher_4 \\ \text{Simplify: } \\ \text{attack} = character_1 + key_1 + IV_1 + character_2 + key_2 + IV_1 + ...


3

In the context of encryption schemes, the key is whatever piece of information the legitimate recipient of an encrypted message possesses, which allows him to decrypt the ciphertext efficiently. Hence, the key must be kept hidden from an attacker, since otherwise the attacker could decrypt efficiently just as the legitimate recipent does.


3

This is only a problem if there is very little knowledge about the plaintext. If the plaintext is fully random, you have no distinguisher and you can therefore not detect if you hit the jackpot. If you do have information about the plaintext then it doesn't take a lot of information to see if you have the correct key. And usually there is a lot of ...


3

I know that all the subkeys $k_i$ are derived from the main key $K$, but how? However the cipher designer feel like. The Feistel design gives guidance as to how the block is processed (and in a way to make inverting the cipher easy), however it gives no guidance as to actually generate the subkeys. The designers can do anything they like, and still ...


3

You're right in that there's little chance you can break the logarithm in a well-chosen 512 bit group (using a home computer, in reasonable time — as pointed out by SEJPM, it is possible investing some time and a good amount of money). However, in your case, the parameters are bad: The order of $(\mathbb Z/p\mathbb Z)^\ast$, that is $p-1$, is a smooth ...


3

Instead of generating the random key for the one time pad cipher over and over again, is there a mathematical formula that allows you to switch the key to a new key? No. (Please keep reading…) A single mathematical formula won’t cut it. That’s where cryptographic algorithms come in. There are more than a handfull of cryptographically secure ...


3

From the linked page, a minikey is a 30-character string over the base58 alphabet with the first byte fixed to 'S', so effectively 29 characters. This gives a space of $log_2(58^{29}) \approx 169.88$ bits. Assuming that SHA is a random function, the probability of the hash starting with an 0-byte after appending a ? is 1/256, so this check loses 8 bits of ...


2

There are two inputs to PBKDF2, and key derivation functions in general: the password and a salt. Assuming the attacker knows the salt, all the password hash can do is slow down a brute force or dictionary search (i.e. 1000x the complexity of HMAC with PBKDF2 default iterations), as well as force the attacker to search for each user's password individually. ...


2

In your question, you already pointed out, that the necessary condition is More generally largest prime minus one does not consists of smallest prime as a prime factor therefore, it is sufficient to just check if $p$ divides $q-1$ by computing division. You can just verify this condition during the key generation. I don't know of a more efficient ...


2

There are many possibilities here, depending on the particulars of where exactly you will use it. Your use case may require a random looking derived key, where the 1024 bytes of entropy have been distributed evenly over all the bytes of the final key. In that case there's no avoiding a key derivation function. You will have to use either a block cipher, a ...


2

CryptGenRandom is supposed to produce cryptographically strong random numbers, so you shouldn't need to process it before using as a key. However, if you want to treat it as of suspect quality, I would go with SP 800-90B recommendations: assume it has entropy at least half the bits, so request double what you need. Then run it through HMAC with a suitable ...


2

Not always, it depends on the particular encryption scheme. Strictly speaking, the proofs only say that breaking indistinguishability is equivalent to breaking the hardness assumption they are based on. There are some cryptosystems, like Rabin's, where the security of the key is equivalent to the security of the ciphertexts, i.e. factoring <=> key ...


2

I understand that if a block cipher has $k$-bit keys and $n$-bit input/output blocks, then if $k>n$, we can expect one message-ciphertext pair to narrow us down (I think?) to $2^{k−n}$ possible keys, right? That is approximately correct (if the block cipher with the wrong key acts like a random permutation; this is generally a safe assumption); if ...


2

There are many types of weak keys, some of them make it vulnerable to chosen plaintext attack, some of them may leak some statistical properties through the plaintext, some keys generate same subkeys for multiple rounds of an algorithm etc. See https://en.wikipedia.org/wiki/Weak_key . Keys are usualy generated randomly. The randomness is tightly connected ...


2

What you're looking for is called a key derivation function, and more specifically a key stretching function. A key derivation function takes some variable-size material and turns it into a fixed-size key in a deterministic way, such that calling the same function on the same input yields the same key, and the original material cannot be reconstructed from ...


2

It looks fine; whether you use the secret $S_0, S_1$ as the HMAC key, or whether you use the random value $r$ as the HMAC key; if $t' = t$, it implies that either $S_0 = S_1$, or we found a collision in the underlying hash function. I would personally suggest you use $S_0, S_1$ as the key. With HMAC, it doesn't really matter; however if we extend this to ...


2

Key generation and key scheduling are different things. The key scheduling is part of the cipher, the key generation generally isn't. Symmetric keys should be indistinguishable from random, so often they are the product of a secure random number generator. There are other ways as well, such as derivation from a password using a Password Based Key Derivation ...


2

PBKDF2 is an acronym for Password Based Key Derivation Function, #2. As you already have a key you need a Key Based Key Derivation Function or KBKDF instead. Currently the most up to date one is probably HKDF, which was - very quickly - also recognized by NIST. There are other KDF's such as KDF1 and KDF2 which are easier to construct (not many libraries ...


2

Well PBKDF is for deriving keys from passwords, you don't need it if your master keys are already safe, just use something like HKDF. (faster) ECDH and DH are certainly the most secure options you have for negotiating session keys. Of course, as you do have a pre-shared master secret you have some interesting new options. Your usage of the HMAC sounds ...



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