This is almost always true!
Users are very bad at creating passwords with good entropy. Myself I
use passphrases that tend to have decent, but not great entropy.
And yes, there is general disdain, in my "world", for the preponderance
of password-based KDFs. They take what is weak and tend to make
something weaker.
Part of the attraction of security "wallets" where the weak human
password hopefully never leaves the system with the wallet. And where
the wallet makes the strong login passwords.
But then how much of Internet access is controlled by RADIUS servers
still using MD5? The long-time head of FreeRADIUS, Alan DeKok, and I
recently discussed this and that the lift to update these servers just
won't happen.
Oh, and that phrase addresses taking all the entropy in a long
passphrase and getting it into some smallish password without loosing
what entropy is present. Like taking a 100-byte phrase and capturing
all the entropy in a 16-byte key.
On 1/12/25 12:02, Sriram R wrote:
Robert,
Appreciate the links to the articles, read them and they are very
informative.
RFC 5869 does have this phrase:
One significant example is the derivation of cryptographic
keys from a source of low entropy, such as a user's password. The
extract step in HKDF can concentrate existing entropy but cannot
amplify entropy.
This statement sounds like keys derived from a user's password might
be weaker than keys derived from random input keying material. Is that
not how one should interpret this statement in the RFC?
Based on the popularity of password-based KDF, I'm guessing this is
not a concern?
To the pyca/cryptography team:
Is the development of a KMAC module on the roadmap? And if so, kindly
requesting to share the timeline for planning purposes. My team has a
requirement to implement
quantum-resistant algorithms when and where possible and since KMAC is
quantum-resistant we're very much interested in adopting it.
Best,
PE
On Sat, Jan 11, 2025 at 4:57 PM Robert Moskowitz <r...@htt-consult.com>
wrote:
read
RFC 5869 HMAC-based Extract-and-Expand Key Derivation Function
(HKDF). H.
Krawczyk, P. Eronen. May 2010. (Format: TXT, HTML) (Status:
INFORMATIONAL) (DOI: 10.17487/RFC5869)
On the proper way to use a keyed SHA2 hash as a KDF.
Hash chains build off a secret key are considered not safe.
For SHA3, KMAC (NIST SP800-185) is a proven KDF.
See:
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-108r1-upd1.pdf
Sec 4.4.
I have had the privilege of direct conversations with Dr. Krawczyk
even prior to his presentation on keyed hash attacks in 1995 and
the reason for the HMAC (RFC2104) construct.
And I have had the privilege of following along with Team Keccak
on the development of what is now SHA3 and its derivatives. We
are finally seeing an uptick in replacing HMAC/HKDF with KMAC.
On 1/10/25 17:00, Sriram R via Cryptography-dev wrote:
Hello,
I'm generating a key using Scrypt from a password supplied by the
user. I then use this key as follows. This works but my question
to the experts: is this an acceptable way to use the AESGCMSIV
cipher? Am I doing something that's fundamentally against best
practices? In the examples on the Cryptography site, the sample
code snippet uses AESGCMSIV.generate_key() method to generate the
key instead. The requirement I have is to generate the key that's
based on a password.
def gen_salt(size=32):
return secrets.token_bytes(size)
def der_key(salt, password):
kdf = Scrypt(salt=salt, length=32, n=2**20, r=8, p=1)
return kdf.derive(password.encode())
def gen_symmkey(salt, password):
symmkey = der_key(salt, password)
return symmkey
key = gen_symmkey(salt, password)
aesgcmsiv = AESGCMSIV(key)
ct = aesgcmsiv.encrypt(nonce, file_data, aad)
with open(fname, "wb") as outfile:
outfile.write(ct)
Best,
PE
_______________________________________________
Cryptography-dev mailing list
Cryptography-dev@python.org
https://mail.python.org/mailman/listinfo/cryptography-dev
_______________________________________________
Cryptography-dev mailing list
Cryptography-dev@python.org
https://mail.python.org/mailman/listinfo/cryptography-dev
