Tag Info

New answers tagged

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 ...


4

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 ...


4

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 ...


1

First of all: accelerating PBKDF by using a faster hash doesn't make sense; an attacker is likely to receive the same speedup. On 64 bit machines SHA-512 or one of the 384, 256 or 224 derivatives is likely to be faster than SHA-256. So you might be able to increase security and have a faster hash algorithm. MD4 should probably not be used for anything ...


16

SHA-512 has 25% more rounds than SHA-256. On a 64-bit processor each round takes the same amount of operations, yet can process double the data per round, because the instructions process 64-bit words instead of 32-bit words. Therefore, 2 / 1.25 = 1.6, which is how much faster SHA-512 can be under optimal conditions. Of course there is memory overhead, ...


20

This isn't necessarily unexpected. 32-bit platforms vs 64-bit platforms can make a significant difference, as well as the amount of data you're hashing. $ uname -m x86_64 $ openssl speed sha256 sha512 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes sha256 ...


7

SHA-512 (and SHA-384) is usually faster on 64-bit platforms, and SHA-256 is usually faster on 32-bit platforms.


0

Sure, that should be fine. It's probably more secure than KDF1 & 2 that use a normal hash method and a 4 byte counter. HKDF however can certainly be used for this, but it seems you only need to differentiate, rather than extract and expand.



Top 50 recent answers are included