Re: [Cryptography] AES-256- More NIST-y? paranoia
On Sun, Oct 6, 2013 at 9:10 PM, Phillip Hallam-Baker hal...@gmail.com wrote: I am even starting to think that maybe we should start using the NSA checksum approach. Incidentally, that checksum could be explained simply by padding prepping an EC encrypted session key. PKCS#1 has similar stuff to ensure that there is no known plaintext in there. Using the encryption algorithm instead of the OAEP hash function makes much better sense. Wait, am I misunderstanding, or is the NSA recommending that people checksum by leaving behind the key encrypted with a backdoor the NSA and the NSA only can read? Wow. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Few facts are more revealing than the direction people travel when they vote with their feet. — Don Boudreaux http://bit.ly/afZgx2 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Some protection against replay attacks
Reading about several attacks based on partial message replay, I was wondering if the following idea had any worth, or maybe was already widely used (sorry, I'm way behind in the literature): the actual symmetric key to be used to encrypt the payload is the hash of the shared secret, the time, and other public data. Optionally, other public data can include information identifying the two parties, to make active attacks harder, as well as nonces sent by either or both parties, and sequential numbers preventing reuse within the window, etc. This means that protocol attacks are now restricted to a smaller window (say, TCP timeout of 5 minute), in either the time range that active attacks can be conducted, or that the passive data can be decrypted. i.e. that's automated rekeying, in a way that almost guarantees the same key is never used twice. Depending on the protocol, the server can be trusted to broadcast and communicate its time with some coarse grain, and the client just uses its NTP time as a guess. The server can accept the proposed client's time if within an acceptable window, or override it with its time, that the client can deny if in paranoid mode — in which case there is a DoS attack possible if NTP is subverted. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Reason isn't about not having prejudices, it's about having (appropriate) postjudices. — Faré ___ 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
[Cryptography] A strategy to circumvent patents?
Don't write the code. Write a reasonably general software solver that finds a program that fulfill given specifications, given a minimum number of hints. Then write a specification for the problem (e.g. finding a nice elliptic curve with interesting properties) and let the solver find them. You didn't explicitly write the solution. Now, the patent troll has to argue that the problem itself, not the solution, is covered by the patent — which I believe is not supported by patent law. Or he has to argue that the solution isn't obvious to someone versed in the arts, which it is, since a trivial automated program could find the solution. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org *EULA: By reading or responding to this message you agree that all my stated or unstated opinions are correct.* EULA — patent pending. ___ 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] Thoughts about keys
So, how do I translate al...@example.org into a key? Once again, what do you think of namecoin? A bitcoin-like consensual database based on proof of work. If you also require proof-of-key via signature from the recipient, majority attacks make DoS easy, but identity stealing is still dependent on highly visible unsigned revocation certificates. At intervals, the trustworthy organization (and others like it) can send out email messages to Alice, encrypted in said key, saying Hi there! Please reply with a message containing this magic cookie, encrypted in our key, signed in yours. The cookie better not be a a value that the organization can skew with its own random source, but be based on a digest of consensual data, such as the date (with sufficiently coarse resolution), the top of the consensual database (if any), public weather measurements from previous day, etc. Then, each user can just broadcast his signature of the previously unpredictable consensual data, and various timestamping organizations can sign messages that say yes, I saw that at this time, maybe charging some tiny usage fee in the process. If a handshake is required (and in this case, it looks like it is), at least, prevent the organization from personalizing the cookie too much, by requiring it to have personal cookies be based on a digest of a common salt for all addresses, and data consensually associatable to the destination address. After a deadline, the organization publishes the definitive merkle tree digest of who was seen on time, together with the common salt. Third, presumably one wants a means to query such databases that doesn't allow traffic analysis. Mix networks including Tor are probably the answer on that. Without such a mechanism, listening in on the query traffic becomes a very good way to trace out social networks. Assuming a namecoin like system where every server has ALL the keys, your query could be of the form: give me all keys k such that digest(kmask)==digest(k0mask) with mask wide enough that you get say ~1000 keys, and computed in a deterministic/non-deterministic enough way that you don't leak too much information. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Reevaluate your ends periodically — if some of them or in contradiction with reality or with each other, abandon or amend them without mercy — and those you keep, pursue without any apology. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts about keys
On Mon, Sep 2, 2013 at 7:19 PM, Perry E. Metzger pe...@piermont.com wrote: On Mon, 2 Sep 2013 03:00:42 +0200 Faré fah...@gmail.com wrote: At intervals, the trustworthy organization (and others like it) can send out email messages to Alice, encrypted in said key, saying Hi there! Please reply with a message containing this magic cookie, encrypted in our key, signed in yours. The cookie better not be a a value that the organization can skew with its own random source, but be based on a digest of consensual data, such as the date (with sufficiently coarse resolution), the top of the consensual database (if any), public weather measurements from previous day, etc. I don't understand why. The security requirement is that third parties must *not* be able to predict the token, because then they could sign the token without controlling the email address. The only organization that can know the cookie is actually the organization sending the cookie out. You appear to have inverted the security requirement... In my scheme, no one can predict it, everyone can postdict it, *after* the trusted organization published its salt, at which point it's too late to send it signed confirmations. Therefore, neither side can cheat. In particular, the trusted organization has precious little power to extract information by handing users carefully crafted cookies. For even less power, the organization can publish digests of its salts years in advance. Then, each user can just broadcast his signature of the previously unpredictable consensual data, and various timestamping organizations can sign messages that say yes, I saw that at this time, maybe charging some tiny usage fee in the process. But then *anyone* could broadcast the token because anyone could have predicted it. You can't broadcast the signed token unless you have the user's key. And sure, you can claim that you saw the signed token before the deadline, but unless you got a tree the hash of which was published as an ad in a reputable print institution, what value has your word? It is difficult to make the interchange of the token and the reply itself widely witnessed -- the way around that is to have many So, to cheat, you need both the user's key and the trusted organization's complicity. Or to have broken the digest, of course. organizations doing the interchanges so that one would have to suborn all of them. Interchange is expensive. Hopefully, you only need to reply to a handful of them every so many months. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org The most exciting phrase to hear in science, the one that heralds new discoveries, is not Eureka! (I found it!) but That's funny ... — Isaac Asimov ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why human-readable IDs (was Re: Email and IM are ideal candidates for mix networks)
There is still a need for a distributed database to handle the lookup load, though, and one that is not the DNS. What do you think of namecoin? —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Truth comes as conqueror only to those who have lost the art of receiving it as friend. — Tagore ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Separating concerns
On Wed, Aug 28, 2013 at 4:15 PM, Phill hal...@gmail.com wrote: My target audience, like Perry's is people who simply can't cope with anything more complex than an email address. For me secure mail has to look feel and smell exactly the same as current mail. The only difference being that sometime the secure mailer will say 'I can't contact that person securely right now because…' I agree with Perry and Phill that email experience should be essentially undisturbed in the normal case, though it's OK to add an additional authorization step. One thing that irks me, though, is the problem of the robust, secure terminal: if everything is encrypted, how does one survive the loss/theft/destruction of a computer or harddrive? I'm no ignoramus, yet I have, several times, lost data I cared about due to hardware failure or theft combined with improper backup. How is a total newbie to do? Most newbies rely on things surviving despite their lack of explicit caution. Currently, they do it by basically trusting Google or some other company with their mail. Whichever way you do things to make them responsible for keys will lead to either (1) failure because it's technically too hard, and/or (2) automated attacks on the weak point that handles things for them. For instance, you have a program that automatically recovers keys from the escrow modulo a few questions. Then, either few questions are too hard and he actually looses the keys, or they are easy enough that the attacker can find answers and recover the key. Or, you have standardized key management and backup policies. Then the attacker can look at the standardized location for the precious keys, and modulo extraction of some master key, can automatically steal everyone's wallet. And then, to prevent automatic extraction of security data, you find that you need not just an appropriate distributed infrastructure (which is more painful to fund if you can't sell the data and require an explicit transaction from the user), but also secure terminals — which implies a secure OS, and hardware that you actually control, rather than big corporations that bend over for big governments. That's a lot of yak to shave to provide end-users (or even average geeks) with seemless secure email. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Being generous is inborn; being altruistic is a learned perversity. No resemblance — — Robert Heinlein, Time Enough For Love ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
