Tag Info

New answers tagged

0

Let us ignore all kinds of encoding or protocol details. We are looking for some string such that $yourprogram(string)=h$, where $h$ is a specific hash value. You will try to crack that password, rather than SHA-256. Let us assume that all the possible messages you have are the 26 lowercase letters of English alphabet. That means that, for every letter in ...


3

The "interesting" part of your encryption is here: Therefore, I prepend a block at the beginning of my packet. Its content goes as follows: First four bytes: current timestamp in seconds Next 12 bytes: zeros I compute the sha256 hash of the message (32 bytes) I xor the timestamp + zeros block with the first half of the hash I xor the ...


5

At a high level, the major flaw is that you are rolling your own crypto protocol. You should strongly consider using a standardized protocol like DTLS. Some specific problems: Symmetric key distribution is left unspecified. Keys must be changed occasionally to thwart distinguishers. No way to recover from symmetric key compromise. Your message ...


5

As Gerald Davis explained in the other answer, there are about 6 million possible passwords, which is way too few. However, there's an additional weakness: since the password and salt are combined with XOR rather than concatenation, it is sufficient to generate a table for all hash values. If you know the $x$ for which $H(x) = h$, you know that the password ...


6

Possible password search space = $36^5$ = 6.05 million possible combinations or ~$2^{26}$. If the passwords were randomly generated it would be 26 bits of entropy which isn't just weak it is pointless. To put that into perspective the throughput on modern GPUs is on the order 1 billion SHA-256 hashes per second. So the exhaustive search time to break an ...



Top 50 recent answers are included