51–60 of 60 posts
Earlier quoted context omitted.
The fact that he knew about that function and you (standing in as "representative Python developer") did not seems to justify the library pretty nicely from what I can tell. But, obviously, this code does more than Python's hmac library does, beyond just knowing how to properly verify the MAC itself.
I wasn't criticising the security of this library, I was criticising it's reason to exist in the form that it does.
This facility is "built in" to Rails, with MessageEncryptor and MessageVerifier. Before you consider writing your own "apply an HMAC-SHA1 hash to a string" library in Ruby, just take those classes from ActiveSupport instead. They've been reasonably well tested.
This facility is "built in" to Rails, with MessageEncryptor and MessageVerifier. Before you consider writing your own "apply an HMAC-SHA1 hash to a string" library in Ruby, just take those classes from ActiveSupport instead. They've been reasonably well tested.
Alternatively, if you are not using Rails but are still using Ruby, then you can use OpenSSL::HMAC.
Earlier quoted context omitted.
Alternatively, if you are not using Rails but are still using Ruby, then you can use OpenSSL::HMAC.
This is a MUCH WORSE IDEA. Don't do this. Even this Python wrapper library does a better job providing HMAC services to users than OpenSSL's HMAC primitive does. Leave OpenSSL:* to the suckers^H^H^H^H^H^H crypto library implementors.
If people are having trouble they can refer to the Rails ActiveSupport source code for help.
Earlier quoted context omitted.
> but it's a per-app password, so you can just do run bcrypt once, at startup. itsdangerous has nothing to do with passwords. It's about signing small messages and these messages are obviously created at runtime. > nonsense and just use a really strong secret key That's how you should use itsdangerous: use a strong secret key.
One way to get a good strong secret key for this purpose: $ python >>> import os >>> os.urandom(64)
dd if=/dev/random bs=64 count=1 2>/dev/null | hexdump
Earlier quoted context omitted.
> I repeat: do not use SHA-1 in new applications. Probably, but not necessarily. It's not like the other sha versions are fixing the overall problem however. > Do not use this module. Even before the 0.13 release I just pushed out where you can override the module easier you could still easily change the hash method with a two line change. Also it's not like maintainers can't change things easily if modules are well…
SHA-1 and SHA-2 (SHA256, SHA512) are not the same algorithm. The problem with SHA-2 isn't that it's insecure; it's that it's slow for its current predicted level of security, and that it's MD-strengthened and so requires an HMAC construction to use in applications like MACs. The sentence "It's not like the other sha versions are fixing the overall problem" is wrong. You would indeed be better off using SHA256. But no…
As it is, the size of that digest is also 14 bytes more and I don't feel happy truncating the hash. The bigger SHA2 versions are even longer. Considering that thing should go into cookies and URLs I did not feel very happy with that.
> You would indeed be better off using SHA256.
Probably. I was indeed under the impression that SHA2 is based on the same building blocks as SHA1 but I assume that is not the case. That being said: upgrading is not hard if it even comes to the point where it would be necessary.
Earlier quoted context omitted.
> but it's a per-app password, so you can just do run bcrypt once, at startup. itsdangerous has nothing to do with passwords. It's about signing small messages and these messages are obviously created at runtime. > nonsense and just use a really strong secret key That's how you should use itsdangerous: use a strong secret key.
One way to get a good strong secret key for this purpose: $ python >>> import os >>> os.urandom(64)
Earlier quoted context omitted.
SHA-1 and SHA-2 (SHA256, SHA512) are not the same algorithm. The problem with SHA-2 isn't that it's insecure; it's that it's slow for its current predicted level of security, and that it's MD-strengthened and so requires an HMAC construction to use in applications like MACs. The sentence "It's not like the other sha versions are fixing the overall problem" is wrong. You would indeed be better off using SHA256. But no…
> SHA256 As it is, the size of that digest is also 14 bytes more and I don't feel happy truncating the hash. The bigger SHA2 versions are even longer. Considering that thing should go into cookies and URLs I did not feel very happy with that. > You would indeed be better off using SHA256. Probably. I was indeed under the impression that SHA2 is based on the same building blocks as SHA1 but I assume that is not the ca…
Earlier quoted context omitted.
SHA-1 and SHA-2 (SHA256, SHA512) are not the same algorithm. The problem with SHA-2 isn't that it's insecure; it's that it's slow for its current predicted level of security, and that it's MD-strengthened and so requires an HMAC construction to use in applications like MACs. The sentence "It's not like the other sha versions are fixing the overall problem" is wrong. You would indeed be better off using SHA256. But no…
> SHA256 As it is, the size of that digest is also 14 bytes more and I don't feel happy truncating the hash. The bigger SHA2 versions are even longer. Considering that thing should go into cookies and URLs I did not feel very happy with that. > You would indeed be better off using SHA256. Probably. I was indeed under the impression that SHA2 is based on the same building blocks as SHA1 but I assume that is not the ca…
Earlier quoted context omitted.
> SHA256 As it is, the size of that digest is also 14 bytes more and I don't feel happy truncating the hash. The bigger SHA2 versions are even longer. Considering that thing should go into cookies and URLs I did not feel very happy with that. > You would indeed be better off using SHA256. Probably. I was indeed under the impression that SHA2 is based on the same building blocks as SHA1 but I assume that is not the ca…
Neils Ferguson, et. al of Cryptography Engineering (p. 95) suggest that truncating a HMAC-SHA-256 to 128 bits should be safe, given current knowledge in the field.