# Tag Info

0

That is probably the hexadecimal representation of a SHA-1 hash, rather than a type of encryption.

0

So you have a secret with low entropy which you want to verify in a secure way. This is a standard scenario in password-based cryptography (PINs are sort of a password). What you'll do in both scenarios described below: The user first enters his access-code (=PIN), which get buffered in the RAM. Now storage media (the device/a drive) will provide the ...

1

When NIST put together the table A.1, they accidentally used a 96 character alphabet for that last column, not a 94 character one. One way to see this is looking at the bottom most entry; they list that $log_2(b^{40}) \approx 263.4$, where $b$ is the alphabet size they used. If we solve for $b$, we get $b \approx 96.002...$.

0

It's the same situation as for RSA encryption. If you accidentally pick a bad $s$, i.e. one that's not coprime to $N$ then the protocol fails. How likely is this to happen? If you hit a bad $s$, then you can find the factors of $N$, hence you can break the protocol - put another way, finding a bad $s$, whether deliberately or by accident is no easier than ...

0

As Thor already notes, you code is already quite close to PBKDF2, and it would not be difficult to turn it into a proper PBKDF2 implementation. Specifically, here's some (vaguely C / C++ / C# / Java / JavaScript like) pseudocode to implement PBKDF2-HMAC-SHA512, given a function HMAC_SHA512(key, message): function PBKDF2_HMAC_SHA512 (password, salt) { ...

1

Using simply a hash function is not strong enough, even if the key is not stored. We the users tend to choose very crappy passwords, such as "1234" or "password". If you only use a hash function for generating the key, then there are a lot of chances that the generated keys are SHA256("1234") or SHA256("password"). That is, this method is very vulnerable to ...

3

If you just need random numbers, there's no point in generating random primes. Just make sure that you're using a cryptographically secure random number generator, properly seeded from a secure entropy source. Also, passwords made up of random letters and numbers are very hard to remember (and type). For a password meant to be memorized by a human, it's ...

3

The essence of port knocking - namely, the concealment of a service behind a lightweight authenticator - does not categorically suffer from security through obscurity. It really depends on what the characteristics of the authenticator are. At one end of the spectrum, there is "open port 22 if a SYN packet is sent first to port 12345" (obscurity - even nmap ...

3

No, it is still security by obscurity, specifically because it is sniffable. Anyone who is aware you are using this port knocking protocol will be able to listen in on which ports you hit and therefore retrieve the shared key, defeating this security layer entirely. Thus the security of your protocol depends completely on the algorithm and not solely ...

Top 50 recent answers are included