[cryptography] HKDF salt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I wonder if anyone on the list can help me to understand the purpose and correct use of HKDF's salt parameter. RFC 5869 has this to say: HKDF is defined to operate with and without random salt. This is done to accommodate applications where a salt value is not available. We stress, however, that the use of salt adds significantly to the strength of HKDF, ensuring independence between different uses of the hash function, supporting source-independent extraction, and strengthening the analytical results that back the HKDF design. Random salt differs fundamentally from the initial keying material in two ways: it is non-secret and can be re-used. As such, salt values are available to many applications. For example, a pseudorandom number generator (PRNG) that continuously produces outputs by applying HKDF to renewable pools of entropy (e.g., sampled system events) can fix a salt value and use it for multiple applications of HKDF without having to protect the secrecy of the salt. In a different application domain, a key agreement protocol deriving cryptographic keys from a Diffie-Hellman exchange can derive a salt value from public nonces exchanged and authenticated between communicating parties as part of the key agreement (this is the approach taken in [IKEv2]). My understanding of the above is that the salt doesn't increase the entropy of HKDF's output from the adversary's point of view, since the adversary knows the salt value. However, the salt prevents accidental collisions if identical initial keying material is used in multiple application domains. Is that right? Can anyone shed light on the meaning of source-independent extraction? The RFC continues: Ideally, the salt value is a random (or pseudorandom) string of the length HashLen. Yet, even a salt value of less quality (shorter in size or with limited entropy) may still make a significant contribution to the security of the output keying material; designers of applications are therefore encouraged to provide salt values to HKDF if such values can be obtained by the application. This doesn't sit well with my interpretation above, because it suggests that the salt contains entropy (from someone's point of view) that contributes to the security of HKDF's output. But how can the salt be said to contain entropy when its value is non-secret? It is worth noting that, while not the typical case, some applications may even have a secret salt value available for use; in such a case, HKDF provides an even stronger security guarantee. An example of such application is IKEv1 in its public-key encryption mode, where the salt to the extractor is computed from nonces that are secret; similarly, the pre-shared mode of IKEv1 uses a secret salt derived from the pre-shared key. This seems unsurprising - if the salt value is unknown to the adversary then clearly it can contribute entropy to HKDF's output. Going back to the issue of non-secret salt, here's a thought experiment: we generate a random salt value, publish it in the New York Times, and use it for all calls to HKDF in a certain application domain. Is this somehow more secure than using no salt? If so, can you help me to understand how? Less extremely: each time we use HKDF, we generate a fresh random salt value and publish it in the New York Times. Is this more secure than using no salt? How? Thanks, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJR+ieDAAoJEBEET9GfxSfMVsIH/3dsAhF4FukIcdVLa/Kw782A akbTjnYHAvwdvRi3fVBrXejM3csya9psSu2qVIgAUXWaMxRVcvPkUoTc7NF+MC65 xVS4j1YcmkEQL7L7LnUQVukISzBO3NgwmAKPrxdzeXLJlaiL9N51ecYmjC0jo9Ou dHs9108z2AQHYZ/n4PhRCVdSPjIA5/Z6kusu6cOQsZHTzeNbmoTuOafZTHFkESbX TmSVS4m54vgQWukTsjGsHDDoemvGzY4ahfZj8l+oOSr3OUP3MdYaxaQEXxq6ZQ3L fdNkdxnpOznz+e14RQzIOFjr8QbWBjwlGFp5CxaMPgKL9a5cKuU9JIxjLsUWyXs= =ZaC7 -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] HKDF salt
In general: the purpose of the salt technique is to stop dictionary attacks. Say you have a password 'fred' and the hash function is a variant of DES [0]. It is possible to calculate the DES hash of 'fred' and store that. Then, in every system, I can simply read the hashed passwords by cat /etc/passwd [0] and compare to known results in my dictionary. However, if the hash function combines 'fred' with salt 948375384 and then stores the two together in the file, the dictionary attack fails. In effect, the space is expanded so dramatically that I can no longer calculate 'fred' with every possible salt and store it, economically. [0] these things were true a long time ago... in more particular: On 1/08/13 12:16 PM, Michael Rogers wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I wonder if anyone on the list can help me to understand the purpose and correct use of HKDF's salt parameter. RFC 5869 has this to say: HKDF is defined to operate with and without random salt. This is done to accommodate applications where a salt value is not available. As a quibble, this is a bad idea. It should be designed this way: HKDF is defined to operate with a salt, always. Where applications cannot provide a salt, a zero-filled salt should be supplied. This is a question of software engineering, and robustness. We stress, however, that the use of salt adds significantly to the strength of HKDF, ensuring independence between different uses of the hash function, supporting source-independent extraction, and strengthening the analytical results that back the HKDF design. Random salt differs fundamentally from the initial keying material in two ways: it is non-secret and can be re-used. As such, salt values are available to many applications. For example, a pseudorandom number generator (PRNG) that continuously produces outputs by applying HKDF to renewable pools of entropy (e.g., sampled system events) can fix a salt value and use it for multiple applications of HKDF without having to protect the secrecy of the salt. In a different application domain, a key agreement protocol deriving cryptographic keys from a Diffie-Hellman exchange can derive a salt value from public nonces exchanged and authenticated between communicating parties as part of the key agreement (this is the approach taken in [IKEv2]). My understanding of the above is that the salt doesn't increase the entropy of HKDF's output from the adversary's point of view, since the adversary knows the salt value. Yes. However, the salt prevents accidental collisions if identical initial keying material is used in multiple application domains. Not accidental, but calculated in advance. Is that right? Can anyone shed light on the meaning of source-independent extraction? hmmm... The RFC continues: Ideally, the salt value is a random (or pseudorandom) string of the length HashLen. Yet, even a salt value of less quality (shorter in size or with limited entropy) may still make a significant contribution to the security of the output keying material; designers of applications are therefore encouraged to provide salt values to HKDF if such values can be obtained by the application. This doesn't sit well with my interpretation above, because it suggests that the salt contains entropy (from someone's point of view) that contributes to the security of HKDF's output. But how can the salt be said to contain entropy when its value is non-secret? The entropy is provided to ensure lack of collisions in selection. If everyone selects from a good random source, then there is a good spread across the space, enlarging the task of dictionary attacks. It is worth noting that, while not the typical case, some applications may even have a secret salt value available for use; in such a case, HKDF provides an even stronger security guarantee. An example of such application is IKEv1 in its public-key encryption mode, where the salt to the extractor is computed from nonces that are secret; similarly, the pre-shared mode of IKEv1 uses a secret salt derived from the pre-shared key. This seems unsurprising - if the salt value is unknown to the adversary then clearly it can contribute entropy to HKDF's output. Going back to the issue of non-secret salt, here's a thought experiment: we generate a random salt value, publish it in the New York Times, and use it for all calls to HKDF in a certain application domain. Is this somehow more secure than using no salt? If so, can you help me to understand how? No, because it is the same value for every different call to HKDF, so in effect it is not a salt at all. In more conceptual terms you are simple changing the algorithm of the hash function, and not in any significant way. Less extremely: each time we use HKDF, we generate a fresh
Re: [cryptography] HKDF salt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks Ian! I hadn't considered dictionary attacks because I was assuming the initial keying material had enough entropy to make them impractical. But now I can see that was my assumption, not the HKDF designers'. Cheers, Michael On 01/08/13 10:41, ianG wrote: In general: the purpose of the salt technique is to stop dictionary attacks. Say you have a password 'fred' and the hash function is a variant of DES [0]. It is possible to calculate the DES hash of 'fred' and store that. Then, in every system, I can simply read the hashed passwords by cat /etc/passwd [0] and compare to known results in my dictionary. However, if the hash function combines 'fred' with salt 948375384 and then stores the two together in the file, the dictionary attack fails. In effect, the space is expanded so dramatically that I can no longer calculate 'fred' with every possible salt and store it, economically. [0] these things were true a long time ago... in more particular: On 1/08/13 12:16 PM, Michael Rogers wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I wonder if anyone on the list can help me to understand the purpose and correct use of HKDF's salt parameter. RFC 5869 has this to say: HKDF is defined to operate with and without random salt. This is done to accommodate applications where a salt value is not available. As a quibble, this is a bad idea. It should be designed this way: HKDF is defined to operate with a salt, always. Where applications cannot provide a salt, a zero-filled salt should be supplied. This is a question of software engineering, and robustness. We stress, however, that the use of salt adds significantly to the strength of HKDF, ensuring independence between different uses of the hash function, supporting source-independent extraction, and strengthening the analytical results that back the HKDF design. Random salt differs fundamentally from the initial keying material in two ways: it is non-secret and can be re-used. As such, salt values are available to many applications. For example, a pseudorandom number generator (PRNG) that continuously produces outputs by applying HKDF to renewable pools of entropy (e.g., sampled system events) can fix a salt value and use it for multiple applications of HKDF without having to protect the secrecy of the salt. In a different application domain, a key agreement protocol deriving cryptographic keys from a Diffie-Hellman exchange can derive a salt value from public nonces exchanged and authenticated between communicating parties as part of the key agreement (this is the approach taken in [IKEv2]). My understanding of the above is that the salt doesn't increase the entropy of HKDF's output from the adversary's point of view, since the adversary knows the salt value. Yes. However, the salt prevents accidental collisions if identical initial keying material is used in multiple application domains. Not accidental, but calculated in advance. Is that right? Can anyone shed light on the meaning of source-independent extraction? hmmm... The RFC continues: Ideally, the salt value is a random (or pseudorandom) string of the length HashLen. Yet, even a salt value of less quality (shorter in size or with limited entropy) may still make a significant contribution to the security of the output keying material; designers of applications are therefore encouraged to provide salt values to HKDF if such values can be obtained by the application. This doesn't sit well with my interpretation above, because it suggests that the salt contains entropy (from someone's point of view) that contributes to the security of HKDF's output. But how can the salt be said to contain entropy when its value is non-secret? The entropy is provided to ensure lack of collisions in selection. If everyone selects from a good random source, then there is a good spread across the space, enlarging the task of dictionary attacks. It is worth noting that, while not the typical case, some applications may even have a secret salt value available for use; in such a case, HKDF provides an even stronger security guarantee. An example of such application is IKEv1 in its public-key encryption mode, where the salt to the extractor is computed from nonces that are secret; similarly, the pre-shared mode of IKEv1 uses a secret salt derived from the pre-shared key. This seems unsurprising - if the salt value is unknown to the adversary then clearly it can contribute entropy to HKDF's output. Going back to the issue of non-secret salt, here's a thought experiment: we generate a random salt value, publish it in the New York Times, and use it for all calls to HKDF in a certain application domain. Is this somehow more secure than using no salt? If so, can you help me to understand how? No, because it
[cryptography] Updated Certificate Transparency site
Since there was some puzzlement over CT, I thought it might be of interest that we have revamped the site: http://www.certificate-transparency.org/. Comments and questions welcome. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] HKDF salt
On Thu, Aug 01, 2013 at 10:16:51AM +0100, Michael Rogers wrote: My understanding of the above is that the salt doesn't increase the entropy of HKDF's output from the adversary's point of view, since the adversary knows the salt value. However, the salt prevents accidental collisions if identical initial keying material is used in multiple application domains. Is that right? Can anyone shed light on the meaning of source-independent extraction? The reasoning for this is in the paper On Extract-then-Expand Key Derivation Functions and an HMAC-based KDF, where HKDF was originally defined. http://webee.technion.ac.il/~hugo/kdf/kdf.pdf The basic motivation is that having this random salt allows one to show (given various assumptions) that HKDF will produce a uniform random string given an input string with sufficient min-entropy, regardless of the source distribution. Jack ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Updated Certificate Transparency site
in CT, how do you tell if a newly-generated cert is legitimate or not? Say, I am a state-sponsored attacker and can get a cert signed by my national CA for barclays. How do you tell this cert is not legitimate? It could have been barclays' IT admin who asked for a new cert. Do companies need to liaise with CT to tell them which certs are valid? Do they need to tell CT each time they change or get new certs? Sorry if this is basic CT knowledge... Thanks On Thu, Aug 1, 2013 at 12:06 PM, Ben Laurie b...@links.org wrote: Since there was some puzzlement over CT, I thought it might be of interest that we have revamped the site: http://www.certificate-transparency.org/. Comments and questions welcome. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] http://goldbug.sourceforge.net/ - Secure Instant Messenger
Randolph D. rdohm...@gmail.com wrote: Did any one looked into this http://goldbug.sourceforge.net/ Secure Instant Messenger Other alternatives include: http://www.cypherpunks.ca/otr/ https://silentcircle.com/ ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] http://goldbug.sourceforge.net/ - Secure Instant Messenger
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/01/2013 02:11 PM, Sandy Harris wrote: Did any one looked into this http://goldbug.sourceforge.net/ Secure Instant Messenger Very similar codebases for very similar applications with very similar feature sets and some questionable public references (at best) are being posted to multiple forums (among them one of the cypherpunks mailing lists and liberation-tech). Caveat user. https://cpunks.org//pipermail/cypherpunks/2013-July/000144.html - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ Phenomenal cosmic powers be damned - I have a lease. --Harry Dresden -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlH6rIUACgkQO9j/K4B7F8FKnACfXFTH3rAMOclfHBYmzKniUwRZ 2xMAnjsyJSyt7hx1IhmP5A1UiZZUlxDr =xqSr -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] http://goldbug.sourceforge.net/ - Secure Instant Messenger
that is something with substance and helpful! those who overlook the context have already created a coordinate system. Thanks. 2013/8/1 Sandy Harris sandyinch...@gmail.com Did any one looked into this http://goldbug.sourceforge.net/ Secure Instant Messenger Other alternatives include: http://www.cypherpunks.ca/otr/ https://silentcircle.com/ ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Updated Certificate Transparency site
On Thu, Aug 1, 2013 at 12:57 PM, wasa bee wasabe...@gmail.com wrote: in CT, how do you tell if a newly-generated cert is legitimate or not? Say, I am a state-sponsored attacker and can get a cert signed by my national CA for barclays. How do you tell this cert is not legitimate? It could have been barclays' IT admin who asked for a new cert. Do companies need to liaise with CT to tell them which certs are valid? Do they need to tell CT each time they change or get new certs? CT allows the relying parties (e.g., TLS clients) only to verify that the CA issued the cert in an auditable way. Only the owners of resources named by certs (or their agents) can meaningfully audit certificate issuance. If everyone does their part CT causes the risk of dishonest CA behavior discovery to become to great for CAs to engage in such behavior. If you're in a position to know what CAs are allowed to issue certs for a given name, then you can check for (audit) a) issuance of certs for that name by unauthorized CAs, b) issuance of new certs by authorized CAs but for unauthorized public keys. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] HKDF salt
Two words: rainbow tables. Salting makes it impossible to pre-compute rainbow tables for common inputs (e.g., passwords). Now, this HKDF is not intended for use as a PBKDF, so the salt effectively adds no real value when the input key material is truly random/unpredictable by attackers, which it damned well ought to be. OTOH, if the IKM is weak, or if you don't know if it could be, then salting defeats rainbow tables. In other words: salting doesn't hurt, and might really help. Salting is good. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Updated Certificate Transparency site
On Thu, Aug 1, 2013 at 5:04 PM, Nico Williams n...@cryptonector.com wrote: On Thu, Aug 1, 2013 at 12:57 PM, wasa bee wasabe...@gmail.com wrote: ... If everyone does their part CT causes the risk of dishonest CA behavior discovery to become to great for CAs to engage in such behavior. Sorry to drift a bit, but how so? The best I can tell, there is little to no risk because browsers (and others in similar positions) often refuse to take action. As Trustwave and Mozilla, Microsoft, et al recently demonstrated, its just a dog and pony show. Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Radiation Emission Controls
On Wed, Jul 31, 2013 at 04:23:15PM +0200, Eugen Leitl wrote: On Tue, Jul 30, 2013 at 03:18:51PM -0400, Riad S. Wahby wrote: Is there any RF sigint at all done at the Utah site? It could all well be just a big crunch and storage facility. It would help if we had a good fiber map of the general area. Guys, there isn't much of interest to listen to in Utah... even for NSA. Ground based RF sigint is either very local - directed at things like foreign cellphone networks or other short range VHF/UHF/Microwave comms systems that are only receivable a perhaps a few thousand feet to a small number of miles away or aimed at satellites or LF/MF/HF radio transmissions. There are only so many satellites and we have most of those of interest covered by dishes somewhere else already... and HF radio carries very little these days and optimum sites for receiving those signals are also already in place. If there is much of any RF at the facility it will likely be satellite links bringing in material of interest and maybe communicating with remote surveillance vehicles to receive their take and control their operation ... but many of the relevant satellites are not visible from Utah. And ground operations centers for those vehicles are mostly elsewhere too... By a great many many orders of magnitude the NSA take from tapping fiber world wide dwarfs almost all traditional radio reception except maybe collection of cellphone signals from platforms that perforce have to be more or less line of sight from the cellphone of interest (and therefore not in Utah). Most radio propagation is line of sight. Quite hard for a ground based facility to receive much from other ground based transmitters for more than a relatively few miles (easily less than around 100). I suspect that the NSA is doing a lot of decentral signal prefiltering and processing at the network edge, and only uses large central facilities if they're unavoidable. They HAVE to limit the edge take and filter, too much to deal with otherwise. -- Dave Emery N1PRE/AE, d...@dieconsulting.com DIE Consulting, Weston, Mass 02493 An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
