Re: [Cryptography] Sha3
Jerry Leichter wrote: Currently we have SHA-128 and SHA-256, but exactly why one should choose one or the other has never been clear - SHA-256 is somewhat more expensive, but I can't think of any examples where SHA-128 would be practical but SHA-256 would not. In practice, when CPU is thought to be an issue (rightly or wrongly), people have gone with RC4 - standards be damned. SHA-224/256 (there is no SHA-128) use 32-bit words, SHA-384/512 uses 64-bit words. That difference is indeed a very big deal in embedded device applications. SHA-3 uses only 64-bit words, which will likely preclude it being used in most embedded devices for the foreseeable future. -David Mercer David Mercer Portland, OR ___ 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
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
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] Three kinds of hash: Two are still under ITAR.
Pardon the top-post, I'm on a retarded mobile client at the moment... I wish the following were true. However a current nsa.gov url with a recent timestamp explicitly lists FIPS 180-4 hashes (SHA-n) as covered by the notification requirement. I phrased my initial query to the list explicitly in the form of what is the FIPS 180 notification requirement, not is there one, on purpose. See the ridiculous requirements I (tangentially) cited. All cryptography has been treated as politically sensitive by the USG, even when it no longer makes sense for a given algorithm, for decades. In the current political climate in the US, does anyone want to be a test case for admittedly outdated regulatory compliance because of unrelated personal views or actions? I sure don't. After last nights research session, I'm going to stick with sending in email notification for open source FIPS 180 code. This isn't the country it described in social studies and civics class anymore, at all, however once it may have lived up to that mythology. Cheers, David Mercer David Mercer Portland, OR -Original Message- From: Ray Dillinger b...@sonic.net Sender: cryptography-bounces+radix42=gmail@metzdowd.com Date: Tue, 03 Sep 2013 12:29:38 To: cryptography@metzdowd.com Subject: [Cryptography] Three kinds of hash: Two are still under ITAR. On 09/03/2013 09:54 AM, radi...@gmail.com wrote: --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. If I recall the most recent revision, the above requirement is true for keyed hashes whether they are signatures with public-key crypto or secret hashes with private-key crypto) but not for fingerprint or unkeyed hashes like FIPS or SHA-XXX. The distinction among the three types: Signature hashes: Alice produces a signature hash using her private key. Because her public key is common knowledge, everybody can tell that Alice (or at least someone with her private key) really did sign it. Secret hashes: MIB or some similar group share knowledge of a secret key. A, a member of the group, produces a secret hash using that key, and when they check, every member from Bea to Zed knows know that some member of the organization (or at least someone who has the secret key) did sign it. But even if the message and hash are public or in an insecure channel like email, nobody who doesn't have the key can prove a thing about the signer. Or at least, not from the signature itself. Server logs and security video surveillence of public terminals etc, are an entirely different thing. A would be worried about those if she had an official identity for someone to find. Fingerprint hashes: Anybody can apply a fingerprint hash to something, and it proves nothing about who signed it because the hash is completely public knowledge and has no particular key. Anyone who applies a fingerprint hash to something will get exactly the same hash code for the same thing. The point of a fingerprint hash is that it is a fixed-length probably-unique identifier that can be checked in constant time. If the fingerprint of two documents are not equal, the documents are guaranteed to be dissimilar. If the documents are dissimilar, the signatures are *almost* guaranteed to be dissimilar. This is very useful for looking up documents in a hash table or tree, for example, using the fingerprint hash as a key. Usually when cryptographers use the word hash they are talking about a fingerprint hash. Bear ___ 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] Email and IM are ideal candidates for mix networks
Iang wrote: Why do we need the 1980s assumption of being able to send freely to everyone, anyway? tech.supp...@i.bought.your.busted.thing.com is one that comes to mind. i...@sale.me.your.thing.com is another. I think the types of prior whitelist only secure systems being discussed on-list here lately will in the long run win out with the lions share of messages, but that bog standard 'dirty' email will persist for commercial interactions of the type I list above. -David Mercer David Mercer Portland, OR ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Email and IM are ideal candidates for mix networks
Phillip Hallam-Baker wrote: One hypothesis that I would like to throw out is that there is no point in accepting encrypted email from someone who does not have a key to encrypt the response. I'd agree, as I was in just this position in the last week or so: I got a gpg encryped email from someone I had no key for, and I haven't cut or circulated one in a very long while (my bad, as it were, on the latter point). So what's the point in even getting a key from them at that point, after the fact? They ARE not many 'hops' away from me in a web of trust sense so far as knowing people in person, but without having keys exchanged ahead of time, its all moot. As I'm sure this list already knows. Just re-iterating the point made here in various ways that key exchange is THE big problem in all of this. If we can usably crack that nut with 'house servers' on a dongle, we're most of the way there wrt secure email, IMNSHO. Zooko's triangle, pet names...we have cracked the THEORY of secure naming, just not the big obstacle of key exchange. And I don't think the wider public was concerned/scared enough to care before Snowden. Let's hope they care long enough to adopt any viable solutions to the problem that might pop up in the wake of all this. The traffic on this list the past week is a very welcome thing. -David Mercer David Mercer Portland, OR ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
