Re: [Cryptography] FIPS, NIST and ITAR questions
Sent from my iPad On Sep 3, 2013, at 6:06 PM, Jerry Leichter leich...@lrw.com wrote: On Sep 3, 2013, at 3:16 PM, Faré fah...@gmail.com wrote: Can't you trivially transform a hash into a PRNG, a PRNG into a cypher, and vice versa? No. hash-PRNG: append blocks that are digest (seed ++ counter ++ seed) Let H(X) = SHA-512(X) || SHA-512(X) where '||' is concatenation. Assuming SHA-512 is a cryptographically secure hash H trivially is as well. (Nothing in the definition of a cryptographic hash function says anything about minimality.) But H(X) is clearly not useful for producing a PRNG. If you think this is obviously wrong, consider instead: H1(X) = SHA-512(X) || SHA-512(SHA-512(X)) Could you determine, just from black-box access to H1, that it's equally bad as a PRNG? (You could certainly do it with about 2^256 calls to H1 with distinct inputs - by then you have a .5 chance of a duplicated top half of the output, almost certainly with a distinct bottom half. But that's a pretty serious bit of testing) I don't actually know if there exists a construction of a PRNG from a cryptographically secure hash function. (You can build a MAC, but even that's not trivial; people tried all kinds of things that failed until the HMAC construction was proven correct.) -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] FIPS, NIST and ITAR questions
... Let H(X) = SHA-512(X) || SHA-512(X) where '||' is concatenation. Assuming SHA-512 is a cryptographically secure hash H trivially is as well. (Nothing in the definition of a cryptographic hash function says anything about minimality.) But H(X) is clearly not useful for producing a PRNG. You won't get a prf or stream cipher or prng or block cipher just out of collision resistance--you need some kind of pseudorandomness assumption. We expect general purpose hash functions like Keccak to provide that, but it doesn't follow from the collision resistance assumption, for exactly the reason you gave there--it's possible to design collision-resistant functions that leak input or are predictable in some bits. I don't actually know if there exists a construction of a PRNG from a cryptographically secure hash function. (You can build a MAC, but even that's not trivial; people tried all kinds of things that failed until the HMAC construction was proven correct.) The HMAC construction wouldn't give a PRF for your example of h(x) = sha512(x) || sha512(x) A single output would be trivial to distinguish from a 1024 bit random number. -- Jerry --John ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] FIPS, NIST and ITAR questions
On Tue, Sep 3, 2013 at 6:06 PM, Jerry Leichter leich...@lrw.com wrote: On Sep 3, 2013, at 3:16 PM, Faré fah...@gmail.com wrote: Can't you trivially transform a hash into a PRNG, a PRNG into a cypher, and vice versa? No. Let H(X) = SHA-512(X) || SHA-512(X) where '||' is concatenation. Assuming SHA-512 is a cryptographically secure hash H trivially is as well. (Nothing in the definition of a cryptographic hash function says anything about minimality.) But H(X) is clearly not useful for producing a PRNG. Just because it's trivial to produce bogus crypto doesn't mean it's non-trivial to produce good crypto, given a few universal recipes. IIUC, there are already good known ways to go from stream cipher to PRNG, or the other way around, and from a hash to a PRNG, and the other way around. e.g HMAC-DRBG goes hash to prng, the usual construct goes prng to stream cipher, and there's quite possibly a secure transform from cipher to hash, though I don't think the topic has been studied enough. All that to say, if digests are not subject to export, then it's easy to export crypto. Or conversely, if crypto is controlled, then it's easy for the thugs with badges to claim that digests are controlled, if they hate you. These techniques could also be used to produce cryptosystems that fit in very small source code and/or are the result of an automated search, so they may in practice defeat export restrictions and/or patent claims: just get the user to download it, libdvdcss style. That said, the missing piece currently seems to be good public key encryption. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org A child of five would understand this. Send someone to fetch a child of five. — Groucho Marx ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] FIPS, NIST and ITAR questions
On Wed, Sep 4, 2013 at 11:26 AM, Jerry Leichter leich...@lrw.com wrote: Just because it's trivial to produce bogus crypto doesn't mean it's non-trivial to produce good crypto, given a few universal recipes. Look, if you want to play around a produce things that look secure to you and a few of your buddies - feel free to go ahead. If your system is only used by you and a few friends, it's unlikely anyone with the appropriate skills will ever care enough to attack your system, and you'll be secure. As always, security is mainly an *economic* question, not a purely technical one. Jerry, if you have good reasons to believe that either HMAC-DRBG or the standard stream cipher construct are insecure, you should be publishing a paper, not flaming a nobody. That said, I readily admit that the cipher to hash transformation hasn't been widely studied enough, though there are real-world (enough) systems that use variants of such transformations, e.g. bcrypt. My main point was that for the sake of circumventing attempts to ban crypto, either through regulations or patents, you can bootstrap a pretty secure system out of a good hash function and simple transforms, that can probably all fit on a t-shirt together, either as APL or Perl gibberish or as a QR code. Good luck banning that. While this construct might not give you a best-of-breed system, especially with respect of performance or interoperability, it is good enough for Perry's purpose of bootstrapping a secure messaging system, and using such a system, can trivially bootstrap the best-of-breed system by downloading the missing bits. Now the thugs have to go sue millions of users. Sorry for repeating myself. I won't write on this topic anymore. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Anarchism is founded on the observation that since few men are wise enough to rule themselves, even fewer are wise enough to rule others. — Edward Abbey ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] FIPS, NIST and ITAR questions
On Sep 4, 2013, at 10:45 AM, Faré fah...@gmail.com wrote: Can't you trivially transform a hash into a PRNG, a PRNG into a cypher, and vice versa? No. Let H(X) = SHA-512(X) || SHA-512(X) where '||' is concatenation. Assuming SHA-512 is a cryptographically secure hash H trivially is as well. (Nothing in the definition of a cryptographic hash function says anything about minimality.) But H(X) is clearly not useful for producing a PRNG. Just because it's trivial to produce bogus crypto doesn't mean it's non-trivial to produce good crypto, given a few universal recipes. Look, if you want to play around a produce things that look secure to you and a few of your buddies - feel free to go ahead. If your system is only used by you and a few friends, it's unlikely anyone with the appropriate skills will ever care enough to attack your system, and you'll be secure. As always, security is mainly an *economic* question, not a purely technical one. But if you want to play in the crypto game as it's actually played today - if you want something that will survive even if you use it to protect information that has significant value to someone willing to make the investment to get it from you - well, you're going to have to up your game. You're playing at 1980's levels. The world has moved on - your opponents won't feel constrained to do the same. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] FIPS, NIST and ITAR questions
At 03:06 PM 9/3/2013, Jerry Leichter wrote: On Sep 3, 2013, at 3:16 PM, Faré fah...@gmail.com wrote: Can't you trivially transform a hash into a PRNG, a PRNG into a cypher, and vice versa? No. [...] I don't actually know if there exists a construction of a PRNG from a cryptographically secure hash function. (You can build a MAC, but even that's not trivial; people tried all kinds of things that failed until the HMAC construction was proven correct.) PRNG is not necessarily a cryptographically strong term. But isn't counter-mode hash likely to be ok? Counter = seed; while (counter++) Output(Hash(counter)); // or as somebody said Output(Hash(seed||counter||seed)); // and you probably need to pad it to be long enough for the hash to be happy. Obviously if somebody discovers the seed the whole thing is toast. And you can turn the PRNG into a stream cypher by doing plaintext[x] xor PRNG[x], with the usual limitations. None of that has any bearing on ITAR, of course. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] FIPS, NIST and ITAR questions
Ok, skip this one if you aren't an active crypto library maintainer. I'm updating a hash library from FIPS 180-2 to 180-4 compliance and this list is the place I know where somebody might know the answers to all the following questions without my spending days tracking down the answers. Please take out the cluebats if there is a centralized resource I've missed. 1) Is there a NIST announce type list so I don't miss an entire standards update cycle or two again? That doesn't cover all the nitty gritty goings on during the journey to publication for FIPS updates? 2) Is anyone aware of ITAR changes for SHA hashes in recent years that require more than the requisite notification email to NSA for download URL and authorship information? Figuring this one out last time around took ltttss of reading. Implementation updates look to be quick, its any paperwork changes that might be a pain. Thanks, David Mercer David Mercer Portland, OR ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] FIPS, NIST and ITAR questions
--Alexander Kilmov wrote: --David Mercer wrote: 2) Is anyone aware of ITAR changes for SHA hashes in recent years that require more than the requisite notification email to NSA for download URL and authorship information? Figuring this one out last time around took ltttss of reading. I used to believe that hashing (unlike encryption) was not considered arms. -- Regards, ASK Its a common misconception. ITAR doesn't require a license or permit for strong hash functions, but for US persons require(d?) notification of NSA of authorship, contact email and download URL(s), at least in 2006 it did. Often observed in the breach as it were, but some need care more about the letter of the law than others. I'm mostly curious if that requirement has gotten more or less stringent. Thanks, that NIST list looks like the one I need. -David Mercer David Mercer Portland, OR ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] FIPS, NIST and ITAR questions
On Tue, 3 Sep 2013, radi...@gmail.com wrote: 1) Is there a NIST announce type list so I don't miss an entire standards update cycle or two again? That doesn't cover all the nitty gritty goings on during the journey to publication for FIPS updates? http://csrc.nist.gov/news_events/index.html 2) Is anyone aware of ITAR changes for SHA hashes in recent years that require more than the requisite notification email to NSA for download URL and authorship information? Figuring this one out last time around took ltttss of reading. I used to believe that hashing (unlike encryption) was not considered arms. -- Regards, ASK ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] FIPS, NIST and ITAR questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 2) Is anyone aware of ITAR changes for SHA hashes in recent years that require more than the requisite notification email to NSA for download URL and authorship information? Figuring this one out last time around took ltttss of reading. ITAR? Cryptography hasn't been under ITAR since way back in the 1900s. Jon -BEGIN PGP SIGNATURE- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFSJi1GsTedWZOD3gYRApH4AKDBAgddU4Cdi7T+kzDVrJ7JXgmQXgCg4I4p /iPW/GvNa2SOfCzXbl8kpME= =1+0b -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] FIPS, NIST and ITAR questions
ITAR doesn't require a license or permit for strong hash functions, but for US persons require(d?) notification of NSA of authorship, contact email and download URL(s), at least in 2006 it did. That strikes me as an overly-conservative reading of the rules, but it's been some time since I was involved in this stuff. After all, there is no key in a hash function. Notification was required for open source, or a commodity classification for a product that had general encryption facilities. If the notification for hash is (still?) required, I believe you can do it now via a simple phone call. To anyone. #thanks_prism. /r$ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] FIPS, NIST and ITAR questions
Fare wrote: Or once again, maybe a general problem solver given the specification of some cryptographic function satisfying some properties could automatically find a robust enough algorithm, and then it's impossible to either restrict its export or patent. Now, if each time your solver is itself run with a different PRNG and seed, it needs to send a copy of its output to the NSA, things become interesting. My document archive digging turned up the notification threshold. It only required for initial publication on the 'Net for Open Source if the download URL(s) remain the same. Change 'em and your supposed to send an update. Use a symlink to the current version and its not needed. Sigh -David Mercer David Mercer Portland, OR ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] FIPS, NIST and ITAR questions
On Tue, Sep 3, 2013 at 2:49 PM, Richard Salz rich.s...@gmail.com wrote: ITAR doesn't require a license or permit for strong hash functions, but for US persons require(d?) notification of NSA of authorship, contact email and download URL(s), at least in 2006 it did. That strikes me as an overly-conservative reading of the rules, but it's been some time since I was involved in this stuff. After all, there is no key in a hash function. Notification was required for open source, or a commodity classification for a product that had general encryption facilities. If the notification for hash is (still?) required, I believe you can do it now via a simple phone call. To anyone. #thanks_prism. Can't you trivially transform a hash into a PRNG, a PRNG into a cypher, and vice versa? hash-PRNG: append blocks that are digest (seed ++ counter ++ seed) PRNG-cypher: XOR with data from PRNG cypher-hash: encrypt(data, constant_key) Of course, that might not be the best way to construct the most efficient and most robust versions of the respective functions, but that might do a decent enough job, and make export restrictions meaningless. Or once again, maybe a general problem solver given the specification of some cryptographic function satisfying some properties could automatically find a robust enough algorithm, and then it's impossible to either restrict its export or patent. Now, if each time your solver is itself run with a different PRNG and seed, it needs to send a copy of its output to the NSA, things become interesting. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org The ultimate result of shielding men from the effects of folly is to fill the world with fools. — Herbert Spencer ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] FIPS, NIST and ITAR questions
Ok, I dug around my email archives to see what the heck to google, and answered my own question regarding ITAR and NIST defined Suite B implementing software. Here it goes From http://www.nsa.gov/ia/programs/suiteb_cryptography/ ...Says, effectively, that products that 'are configure to USE Suite B or technical documentation concerning the configuration of such products' are not subject to ITAR. The bis.doc.gov site listing requirements under ITAR for US Persons is, inconveniently, down for maintenance. However, digging around in my document backup archives (insomnia provided the time for it...hours) and email un-earth the notification addresses required for ALL US based open-source Suite B implementations. Yes, this is silly. No, they don't NORMALLY go after anyone for breaking the law for a NIST defined hash/digest/crypto algorithm. But if the USG decides they don't like you (political views, activism, etc), that silly regulation can cost you years in prison. The legal term if art is 'selective prosecution'. The relevant email addresses are: cr...@nsa.gov e...@nsa.gov and web_s...@bis.doc.gov Required format and fields are: Subject: TSU NOTIFICATION - Encryption Message body: SUBMISSION TYPE: TSU SUBMITTED BY: author or corporate contacts full legal name SUBMITTED FOR: full legal names of all authors and corporate name if applicable POINT OF CONTACT: full legal name of POC for compliance purposes PHONE and/or FAX: 10 digit number for either PRODUCT NAME/MODEL #: product/program name and model/version ECCN: 5D002 for FIPS-180 hash functions, google cache for others, BIS site currently down, lovely blank line NOTIFICATION: download URL(s) for source file(s) There ya go. Hashes aren't ITAR covered is unfortunately 'Net Mythology. Silly as hell I admit. If the above helps any other US Persons put a fig leaf on themselves, that'd be great. Cheers, David Mercer David Mercer Portland, OR ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] FIPS, NIST and ITAR questions
Hashes aren't ITAR covered is a fact…. from Revised U.S. Encryption Export Control Regulations, January 2000 at http://epic.org/crypto/export_controls/regs_1_00.html 3. It was not the intent of the new Wassenaar language for ECCN 5A002 to be more restrictive concerning Message Authentication Codes (MAC). Data authentication equipment that calculates a Message Authentication Code (MAC) or similar result to ensure no alteration of text has taken place, or to authenticate users, but does not allow for encryption of data, text or other media other than that needed for the authentication continues to be excluded from control under 5A002. These commodities are controlled under ECCN 5A992. further, ECCN 5A992 is separated from the high-functioning encryption as follows. From http://www.governmentcontractslawblog.com/2008/11/articles/export-controls/encryption-export-restrictions-loosened-under-new-rules-that-reduce-prereview-and-reporting-requirements/ Under the EAR, encryption items, which includes software, technology, and hardware incorporating encryption technology, generally fall into two categories: Ø Export Commodity Classification Number (ECCN) 5A002/5D002, for certain enumerated, high-functioning encryption products and software; and Ø ECCN 5A992/5D992, for all other encryption items. Generally speaking, 5A992/5D992 products can be shipped without delay anywhere in the world (except for Cuba, Iran, North Korea, Sudan, and Syria) as No License Required (NLR). Clear (as mud)? On Sep 3, 2013, at 12:21 PM, radi...@gmail.com wrote: Ok, I dug around my email archives to see what the heck to google, and answered my own question regarding ITAR and NIST defined Suite B implementing software. Here it goes From http://www.nsa.gov/ia/programs/suiteb_cryptography/ ...Says, effectively, that products that 'are configure to USE Suite B or technical documentation concerning the configuration of such products' are not subject to ITAR. The bis.doc.gov site listing requirements under ITAR for US Persons is, inconveniently, down for maintenance. However, digging around in my document backup archives (insomnia provided the time for it...hours) and email un-earth the notification addresses required for ALL US based open-source Suite B implementations. Yes, this is silly. No, they don't NORMALLY go after anyone for breaking the law for a NIST defined hash/digest/crypto algorithm. But if the USG decides they don't like you (political views, activism, etc), that silly regulation can cost you years in prison. The legal term if art is 'selective prosecution'. The relevant email addresses are: cr...@nsa.gov e...@nsa.gov and web_s...@bis.doc.gov Required format and fields are: Subject: TSU NOTIFICATION - Encryption Message body: SUBMISSION TYPE: TSU SUBMITTED BY: author or corporate contacts full legal name SUBMITTED FOR: full legal names of all authors and corporate name if applicable POINT OF CONTACT: full legal name of POC for compliance purposes PHONE and/or FAX: 10 digit number for either PRODUCT NAME/MODEL #: product/program name and model/version ECCN: 5D002 for FIPS-180 hash functions, google cache for others, BIS site currently down, lovely blank line NOTIFICATION: download URL(s) for source file(s) There ya go. Hashes aren't ITAR covered is unfortunately 'Net Mythology. Silly as hell I admit. If the above helps any other US Persons put a fig leaf on themselves, that'd be great. Cheers, David Mercer David Mercer Portland, OR ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] FIPS, NIST and ITAR questions
I still think you are reading it too conservatively. The NSA page defers the actual rules to somewhere else: Certain commercial IA and IA-enabled IT products that contain cryptography and the technical data regarding them are subject to Federal Government export controls Suite B includes algorithms (encryption) that are definitely export-controlled. Most think it also contains algorithms that are NOT export-controlled (digest). A Suite B implementation, which would include encryption, is controlled. A partial implementation, such as only the digests.. not proven. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] FIPS, NIST and ITAR questions
On Sep 3, 2013, at 3:16 PM, Faré fah...@gmail.com wrote: Can't you trivially transform a hash into a PRNG, a PRNG into a cypher, and vice versa? No. hash-PRNG: append blocks that are digest (seed ++ counter ++ seed) Let H(X) = SHA-512(X) || SHA-512(X) where '||' is concatenation. Assuming SHA-512 is a cryptographically secure hash H trivially is as well. (Nothing in the definition of a cryptographic hash function says anything about minimality.) But H(X) is clearly not useful for producing a PRNG. If you think this is obviously wrong, consider instead: H1(X) = SHA-512(X) || SHA-512(SHA-512(X)) Could you determine, just from black-box access to H1, that it's equally bad as a PRNG? (You could certainly do it with about 2^256 calls to H1 with distinct inputs - by then you have a .5 chance of a duplicated top half of the output, almost certainly with a distinct bottom half. But that's a pretty serious bit of testing) I don't actually know if there exists a construction of a PRNG from a cryptographically secure hash function. (You can build a MAC, but even that's not trivial; people tried all kinds of things that failed until the HMAC construction was proven correct.) -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
