[Cryptography] ADMIN: Re: Iran and murder
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think this thread has run its course and is sufficiently off topic for this list, so I am declaring it closed. Thank you Tamzen -BEGIN PGP SIGNATURE- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFSWDC65/HCKu9Iqw4RAk3YAKCxoX20Ofj4FFGUDxD8x3GVgpSd2gCg38TQ iCjYvp3O1v7rnjUFil6bDrM= =WWIe -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?
On Oct 11, 2013, at 1:48 AM, ianG i...@iang.org wrote: ... What's your goal? I would say you could do this if the goal was ultimate security. But for most purposes this is overkill (and I'd include online banking, etc, in that). We were talking about how hard it is to solve crypto protocol problems by getting the protocol right the first time, so we don't end up with fielded stuff that's weak but can't practically be fixed. One approach I can see to this is to have multiple layers of crypto protocols that are as independent as possible in security terms. The hope is that flaws in one protocol will usually not get through the other layer, and so they won't lead to practical security flaws. Actually getting the outer protocol right the first time would be better, but we haven't had great success with that so far. Right now we've got a TCP startup, and a TLS startup. It's pretty messy. Adding another startup inside isn't likely to gain popularity. Maybe not, though I think a very lightweight version of the inner protocol adds only a few bits to the traffic used and a few AES encryptions to the workload. I suspect most applications would never notice the difference. (Even the version with the ECDH key agreement step would probably not add noticable overhead for most applications.) On the other hand, I have no idea if anyone would use this. I'm still at the level of thinking what could be done to address this problem, not how would you sell this? iang --John ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] prism-proof email in the degenerate case
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/10/2013 6:40 PM, grarpamp wrote: On Thu, Oct 10, 2013 at 11:58 AM, R. Hirschfeld r...@unipay.nl wrote: To send a prism-proof email, encrypt it for your recipient and send it to irrefrangi...@mail.unipay.nl. Don't include any information about To receive prism-proof email, subscribe to the irrefrangible mailing list at http://mail.unipay.nl/mailman/listinfo/irrefrangible/. Use a This is the same as NNTP, but worse in that it's not distributed. Is this not essentially alt.anonymous.messages, etc? http://ritter.vg/blog-deanonymizing_amm.html http://ritter.vg/blog-deanonymizing_amm_followup1.html ? - -- -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJSV6VAAAoJEDMbeBxcUNAekEcIAIYsHOI384C4RJfNdBcpD6NR a40C4LTQOwPJV335zUWWHjc6+6ZlUwwHimk2IQebNcEflNJn55O7k3N4CS7i4qtp A9dxDxilCrSpwwwPnsso5bfrA2/PEVfux1yzCZ4lmf39xwl/y/0PyBO7DB8CMQcA YatmYtzFAWktLYZSDuMIJPnzSKuaOnEQSiOXwCCTwgSIo3QRoNP+01JprroT168e mylxsVP2R46YIIWx6uWl+oU2oflaa3/r/nLdS2OCV99uZXmu8UlJAVNq222YwELn yhvkasfkRHtE6AhK1t5y9c4dB9cz5v2hTKNFlaRVf0PyA59ZRu8EAoZnWcJCDrM= =gsqL -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] prism-proof email in the degenerate case
On Thu, Oct 10, 2013 at 03:54:26PM -0400, John Kelsey wrote: Having a public bulletin board of posted emails, plus a protocol for anonymously finding the ones your key can decrypt, seems like a pretty decent architecture for prism-proof email. The tricky bit of crypto is in making access to the bulletin board both efficient and private. This is what Bitmessage attempts to achieve, but it has issues. Assuming these can be solved (a rather large if), and glue like https://bitmessage.ch/ is available to be run by end users it could be quite useful. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PGP Key Signing parties
On Thu, Oct 10, 2013 at 04:24:19PM -0700, Glenn Willen wrote: I am going to be interested to hear what the rest of the list says about this, because this definitely contradicts what has been presented to me as 'standard practice' for PGP use -- verifying identity using government issued ID, and completely ignoring personal knowledge. This obviously ignores the threat model of official fake IDs. This is not just academic for some users. Plus, if you're e.g. linking up with known friends in RetroShare (which implements identities via PGP keys, and degrees of trust (none/marginal/full) by signatures, and allows you to tune your co-operative variables (Anonymous routing/discovery/ forums/channels/use a direct source, if available) depending on the degree of trust. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?
On 10/10/13 19:06 PM, John Kelsey wrote: Just thinking out loud The administrative complexity of a cryptosystem is overwhelmingly in key management and identity management and all the rest of that stuff. So imagine that we have a widely-used inner-level protocol that can use strong crypto, but also requires no external key management. The purpose of the inner protocol is to provide a fallback layer of security, so that even an attack on the outer protocol (which is allowed to use more complicated key management) is unlikely to be able to cause an actual security problem. On the other hand, in case of a problem with the inner protocol, the outer protocol should also provide protection against everything. Without doing any key management or requiring some kind of reliable identity or memory of previous sessions, the best we can do in the inner protocol is an ephemeral Diffie-Hellman, so suppose we do this: a. Generate random a and send aG on curve P256 b. Generate random b and send bG on curve P256 c. Both sides derive the shared key abG, and then use SHAKE512(abG) to generate an AES key for messages in each direction. d. Each side keeps a sequence number to use as a nonce. Both sides use AES-CCM with their sequence number and their sending key, and keep track of the sequence number of the most recent message received from the other side. The point is, this is a protocol that happens *inside* the main security protocol. This happens inside TLS or whatever. An attack on TLS then leads to an attack on the whole application only if the TLS attack also lets you do man-in-the-middle attacks on the inner protocol, or if it exploits something about certificate/identity management done in the higher-level protocol. (Ideally, within the inner protcol, you do some checking of the identity using a password or shared secret or something, but that's application-level stuff the inner and outer protocols don't know about. Thoughts? What's your goal? I would say you could do this if the goal was ultimate security. But for most purposes this is overkill (and I'd include online banking, etc, in that). Right now we've got a TCP startup, and a TLS startup. It's pretty messy. Adding another startup inside isn't likely to gain popularity. (Which was one thing that suggests a redesign of TLS -- to integrate back into IP layer and replace/augment TCP directly. Back in those days we -- they -- didn't know enough to do an integrated security protocol. But these days we do, I'd suggest, or we know enough to give it a try.) iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PGP Key Signing parties
Reply to various, Yes, the value in a given key signing is weak, in fact every link in the web of trust is terribly weak. However, if you notarize and publish the links in CT fashion then I can show that they actually become very strong. I might not have good evidence of John Gilmore's key at RSA 2001, but I could get very strong evidence that someone signed a JG key at RSA 2001. Which is actually quite a high bar since the attacker would haver to buy a badge which is $2,000. Even if they were going to go anyway and it is a sunk cost, they are rate limited. The other attacks John raised are valid but I think they can be dealt with by adequate design of the ceremony to ensure that it is transparent. Now stack that information alongside other endorsements and we can arrive at a pretty strong authentication mechanism. The various mechanisms used to evaluate the trust can also be expressed in the endorsement links. What I am trying to solve here is the distance problem in Web o' trust. At the moment it is pretty well impossible for me to have confidence in keys for people who are ten degrees out. Yet I am pretty confident of the accuracy of histories of what happened 300 years ago (within certain limits). It is pretty easy to fake a web of trust, I can do it on one computer, no trouble. But if the web is grounded at just a few points to actual events then it becomes very difficult to spoof. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Key stretching
All, Quick question, anyone got a good scheme for key stretching? I have this scheme for managing private keys that involves storing them as encrypted PKCS#8 blobs in the cloud. AES128 seems a little on the weak side for this but there are (rare) circumstances where a user is going to need to type in the key for recovery purposes so I don't want more than 128 bits of key to type in (I am betting that 128 bits is going to be sufficient to the end of Moore's law). So the answer is to use AES 256 and stretch the key, but how? I could just repeat the key: K = k + k Related key attacks make me a little nervous though. Maybe: K = (k + 01234567) XOR SHA512 (k) -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PGP Key Signing parties
On 2013-10-10 (283), at 19:24:19, Glenn Willen gwil...@nerdnet.org wrote: John, On Oct 10, 2013, at 2:31 PM, John Gilmore wrote: An important user experience point is that we should be teaching GPG users to only sign the keys of people who they personally know. [] would be false and would undermine the strength of the web of trust. I am going to be interested to hear what the rest of the list says about this, because this definitely contradicts what has been presented to me as 'standard practice' for PGP use -- verifying identity using government issued ID, and completely ignoring personal knowledge. Do you have any insight into what proportion of PGP/GPG users mean their signatures as personal knowledge (my preference and evidently yours), versus government ID (my perception of the community standard best practice), versus no verification in particular (my perception of the actual common practice in many cases)? (In my ideal world, we'd have a machine readable way of indication what sort of verification was performed. Signing policies, not being machine readable or widely used, don't cover this well. There is space for key-value annotations in signature packets, which could help with this if we standardized on some.) Glenn Willen __ Surely to make it two factor it needs to be someone you know _and_ something they have? :-) __outer ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] prism-proof email in the degenerate case
grarpamp wrote: On Thu, Oct 10, 2013 at 11:58 AM, R. Hirschfeld r...@unipay.nl wrote: To send a prism-proof email, encrypt it for your recipient and send it to irrefrangi...@mail.unipay.nl. Don't include any information about To receive prism-proof email, subscribe to the irrefrangible mailing list at http://mail.unipay.nl/mailman/listinfo/irrefrangible/. Use a This is the same as NNTP, but worse in that it's not distributed. This scheme already exists on Usenet/NNTP as alt.anonymous.messages. See the Google groups view here: https://groups.google.com/forum/#!forum/alt.anonymous.messages Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?
On 10/10/13 08:41 AM, Bill Frantz wrote: We should try to characterize what a very long time is in years. :-) Look at the produce life cycle for known crypto products. We have some experience of this now. Skype, SSL v2/3 - TLS 0/1/2, SSH 1 - 2, PGP 2 - 5+. As a starting point, I would suggest 10 years. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?
On 10/10/13 17:58 PM, Salz, Rich wrote: TLS was designed to support multiple ciphersuites. Unfortunately this opened the door to downgrade attacks, and transitioning to protocol versions that wouldn't do this was nontrivial. The ciphersuites included all shared certain misfeatures, leading to the current situation. On the other hand, negotiation let us deploy it in places where full-strength cryptography is/was regulated. That same regulator that asked for that capability is somewhat prominent in the current debacle. Feature or bug? Sometimes half a loaf is better than nothing. A shortage of bread has been the inspiration for a few revolutions :) iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] prism-proof email in the degenerate case
On Thu, Oct 10, 2013 at 04:22:50PM -0400, Jerry Leichter wrote:
On Oct 10, 2013, at 11:58 AM, R. Hirschfeld r...@unipay.nl wrote:
Very silly but trivial to implement so I went ahead and did so:
To send a prism-proof email, encrypt it for your recipient and send it
to irrefrangi...@mail.unipay.nl
Nice! I like it.
Me too. I've been telling people that all PRISM will accomplish
regarding the bad guys is to get them to use dead drops, such as comment
posting on any of millions of blogs -- low bandwidth, undetectable. The
technique in this thread makes the use of a dead drop obvious, and adds
significantly to the recipient's work load, but in exchange brings the
bandwidth up to more usable levels.
Either way the communicating peers must pre-agree a number of things --
a traffic analysis achilles point, but it's one-time vulnerability, and
chances are people who would communicate this way already have such
meetings.
A couple of comments:
1. Obviously, this has scaling problems. The interesting question is
how to extend it while retaining the good properties. If participants
are willing to be identified to within 1/k of all the users of the
system (a set which will itself remain hidden by the system), choosing
one of k servers based on a hash of the recipient would work. (A
concerned recipient could, of course, check servers that he knows
can't possibly have his mail.) Can one do better?
Each server/list is a channel. Pre-agree on channels or use hashes. If
the latter then the hashes have to be of {sender, recipient}, else one
party has a lot of work to do, but then again, using just the sender or
just the recipient helps protect the other party against traffic
analysis. Assuming there are millions of channels then maybe
something like
H({sender, truncate(H(recipient), log2(number-of-channels-to check))})
will do just fine. And truncate(H(recipient, log2(num-channels))) can
be used for introduction purposes.
The number of servers/lists divides the total work to do to receive a
message.
2. The system provides complete security for recipients (all you can
tell about a recipient is that he can potentially receive messages -
though the design has to be careful so that a recipient doesn't, for
example, release timing information depending on whether his
decryption succeeded or not). However, the protection is more limited
for senders. A sender can hide its activity by simply sending random
messages, which of course no one will ever be able to decrypt. Of
course, that adds yet more load to the entire system.
But then the sender can't quite prove that they didn't send anything.
In a rubber hose attack this could be a problem. This also applies to
recipients: they can be observed fetching messages, and they can be
observed expending power trying to find ones addressed to them.
Also, there's no DoS protection: flooding the lists with bogus messages
is a DoS on recipients.
Nico
--
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?
I like the ideas, John. The idea, and the protocol you sketched out, are a little reminiscent of ZRTP ¹ and of tcpcrypt ². I think you can go one step further, however, and make it *really* strong, which is to offer the higher or outer layer a way to hook into the crypto from your inner layer. This could be by the inner layer exporting a crypto value which the outer layer enforces an authorization or authenticity requirement on, as is done in ZRTP if the a=zrtp-hash is delivered through an integrity-protected outer layer, or in tcpcrypt if the Session ID is verified by the outer layer. I think this is a case where a separation of concerns between layers with a simple interface between them can have great payoff. The lower/inner layer enforces confidentiality (encryption), integrity, hopefully forward-secrecy, etc., and the outer layer decides on policy: authorization, naming (which is often but not necessarily used for authorization), etc. The interface between them can be a simple cryptographic interface, for example the way it is done in the two examples above. I think the way that SSL combined transport layer security, authorization, and identification was a terrible idea. I (and others) have been saying all along that it was a bad idea, and I hope that the related security disasters during the last two years have started persuading more people to rethink it, too. I guess the designers of SSL were simply following the lead of the original inventors of public key cryptography, who delegated certain critical unsolved problems to an underspecified Trusted Third Party. What a colossal, historic mistake. The foolscap project ³ by Brian Warner demonstrates that it is possible to retrofit a nice abstraction layer onto SSL. The way that it does this is that each server automatically creates a self-signed certificate, the secure hash of that certificate is embedded into the identifier pointing at that server, and the client requires the server's public key match the certificate matching that hash. The fact that this is a useful thing to do, and inconvenient and rare thing to do with SSL, should give security architects food for thought. So I have a few suggestions for you: 1. Go, go, go! The path your thoughts are taking seems fruitful. Just design a really good inner layer of crypto, without worrying (for now) about the vexing and subtle problems of authorization, authentication, naming, Man-In-The-Middle-Attack and so on. For now. 2. Okay, but leave yourself an out, by defining a nice simple cryptographic hook by which someone else who *has* solved those vexing problems could extend the protection that they've gained to users of your protocol. 3. Maybe study ZRTP and tcpcrypt for comparison. Don't try to study foolscap, even though it is a very interesting practical approach, because there doesn't exist documentation of the protocol at the right level for you to learn from. Regards, Zooko https://LeastAuthority.com ← verifiably end-to-end-encrypted storage P.S. Another example that you and I should probably study is cjdns ⁴. Despite its name, it is *not* a DNS-like thing. It is a transport-layer thing. I know less about cjdns so I didn't cite it as a good example above. ¹ https://en.wikipedia.org/wiki/ZRTP ² http://tcpcrypt.org/ ³ http://foolscap.lothar.com/docs/using-foolscap.html ⁴ http://cjdns.info/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PGP Key Signing parties
On 10 October 2013 22:31, John Gilmore g...@toad.com wrote: Does PGP have any particular support for key signing parties built in or is this just something that has grown up as a practice of use? It's just a practice. I agree that building a small amount of automation for key signing parties would improve the web of trust. Do key signing parties even happen much anymore? The last time I saw one advertised was around PGP 2.6! I am specifically thinking of ways that key signing parties might be made scalable so that it was possible for hundreds of thousands of people... An important user experience point is that we should be teaching GPG users to only sign the keys of people who they personally know. Having a signature that says, This person attended the RSA conference in October 2013 is not particularly useful. (Such a signature could be generated by the conference organizers themselves, if they wanted to.) Since the conference organizers -- and most other attendees -- don't know what an attendee's real identity is, their signature on that identity is worthless anyway. I can sign the public keys of people I personally know without a key signing party. :-) For many purposes I don't care about a person's official, legal identity, but I do want to communicate with a particular persona. For instance at DefCon or CCC I neither know or care whether someone identifies themselves to me by their legal name or hacker handle, but it is very useful to know authenticate that they are in control of a private PGP/GPG key in that name on a particular date. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Broken RNG renders gov't-issued smartcards easily hackable.
Saw this on Arstechnica today and thought I'd pass along the link. http://arstechnica.com/security/2013/09/fatal-crypto-flaw-in-some-government-certified-smartcards-makes-forgery-a-snap/2/ More detailed version of the story available at: https://factorable.net/paper.html Short version: Taiwanese Government issued smartcards to citizens. Each has a 1024 bit RSA key. The keys were created using a borked RNG. It turns out many of the keys are broken, easily factored, or have factors in common, and up to 0.4% of these cards in fact provide no encryption whatsoever (RSA keys are flat out invalid, and there is a fallback to unencrypted operation). This is despite meeting (for some inscrutable definition of meeting) FIPS 140-2 Level 2 and Common Criteria standards. These standards require steps that were clearly not done here. Yet, validation certificates were issued. Taiwan is now in the process of issuing a new generation of smartcards; I hope they send the clowns who were supposed to test the first generation a bill for that. Bear ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Key stretching
This is a job for a key derivation function or a cryptographic prng. I would use CTR-DRBG from 800-90 with AES256. Or the extract-then-expand KDF based on HMAC-SHA512. --John ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?
On 10/11/13 at 10:32 AM, zoo...@gmail.com (Zooko O'Whielacronx) wrote: Don't try to study foolscap, even though it is a very interesting practical approach, because there doesn't exist documentation of the protocol at the right level for you to learn from. Look at the E language sturdy refs, which are a lot like the Foolscap references. They are documented at www.erights.org. Cheers - Bill --- Bill Frantz| Truth and love must prevail | Periwinkle (408)356-8506 | over lies and hate. | 16345 Englewood Ave www.pwpconsult.com | - Vaclav Havel | Los Gatos, CA 95032 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PGP Key Signing parties
On 2013-10-11, at 07:03, Tony Naggs tonyna...@gmail.com wrote: On 10 October 2013 22:31, John Gilmore g...@toad.com wrote: Does PGP have any particular support for key signing parties built in or is this just something that has grown up as a practice of use? It's just a practice. I agree that building a small amount of automation for key signing parties would improve the web of trust. Do key signing parties even happen much anymore? The last time I saw one advertised was around PGP 2.6! The most recent key signing party I attended was five days ago (DNS-OARC meeting in Phoenix, AZ). I commonly have half a dozen opportunities to participate in key signing parties during a typical year's travel schedule to workshops, conferences and other meetings. This is not uncommon in the circles I work in (netops, dnsops). My habit before signing anything is generally at least to have had a conversation with someone, observed their interactions with people I do know (I generally have worked with other people at the party). I'll check government-issued IDs, but I'm aware that I am not an expert in counterfeit passports and I never feel like that I am able to do a good job at it. (I showed up to a key signing party at the IETF once with a New Zealand passport, a Canadian passport, a British passport, an expired Canadian permanent-resident card, three driving licences and a Canadian health card, and offered the bundle to anybody who cared to review them to make this easier for others. But that was mainly showing off.) I have used key ceremonies to poison edges and nodes in the graph of trust following observations that particular individuals don't do a good enough job of this, or that (in some cases) they appear to have made signatures at an event where I was present and I know they were not. That's a useful adjunct to a key ceremony (I think) that many people ignore. The web of trust can also be a useful web of distrust. Joe ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Key stretching
On Oct 11, 2013, at 11:26 AM, Phillip Hallam-Baker hal...@gmail.com wrote: Quick question, anyone got a good scheme for key stretching? I have this scheme for managing private keys that involves storing them as encrypted PKCS#8 blobs in the cloud. AES128 seems a little on the weak side for this but there are (rare) circumstances where a user is going to need to type in the key for recovery purposes so I don't want more than 128 bits of key to type in (I am betting that 128 bits is going to be sufficient to the end of Moore's law). So the answer is to use AES 256 and stretch the key, but how? I could just repeat the key: K = k + k Related key attacks make me a little nervous though. Maybe: The related key attacks out there require keys that differ in a couple of bits. If k and k' aren't related, k+k and k'+k' won't be either. K = (k + 01234567) XOR SHA512 (k) Let's step back a moment and think about attacks: 1. Brute force. No public key-stretching algorithm can help, since the attacker will brute-force the k's, computing the corresponding K's as he goes. 2. Analytic attack against AES128 that doesn't extend, in general, to AES256. Without knowing the nature of the attack, it's impossible to estimate whether knowing that the key has some particular form would allow the attack to extend. If so ... what forms? 3. Analytic attack against AES256. A recognizable form for keys - e.g., k+k - might conceivably help, but it seems like a minor thing. Realistically, k+k, or k padded with 0's, or SHA256(k), are probably equally strong except under any attacks specifically concocted to target them (e.g., suppose it turns out that there just happens to be an analytic attack against AES256 for keys with more than 3/4's of the bits equal to 0). Since you're describing a situation in which performance is not an issue, you might as well use SHA256(k) - whitening the key can't hurt. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Broken RNG renders gov't-issued smartcards easily hackable.
Dear Ray, On 2013-10-11, at 19:38 , Ray Dillinger b...@sonic.net wrote: This is despite meeting (for some inscrutable definition of meeting) FIPS 140-2 Level 2 and Common Criteria standards. These standards require steps that were clearly not done here. Yet, validation certificates were issued. This is a misunderstanding of the CC certification and FIPS validation processes: the certificates were issued *under the condition* that the software/system built on it uses/implements the RNG tests mandated. The software didn't, invalidating the results of the certifications. At best the mandatory guidance is there because it was too difficult to prove that the smart card meets the criteria without it (typical example in the OS world: the administrator is assumed to be trusted, the typical example in smart card hardware: do the RNG tests!). At worst the mandatory guidance is there because without it, the smart card would not have met the criteria (i.e. without following the guidance there is a vulnerability) This is an example of the latter case. Most likely the software also hasn't implement the other requirements, leaving it somewhat to very vulnerable to the standard smart card attack such as side channel analysis and perturbation. If the total (the smart card + software) would have been CC certified, this would have been checked as part of the composite certification. (I've been in the smart card CC world for more than a decade. This kind of misunderstanding/misapplication is rare for the financial world thanks to EMVco, i.e. the credit card companies. It is also rare for European government organisations, as they know to contact the Dutch/French/German/UK agencies involved in these things. European ePassports for example are generally certified for the whole thing and a mistake in those of this order would be ... surprising and cause for some intense discussion in the smart card certification community. Newer parties into the smart card world tend to have to relearn the lessons again and again it seems.) With kind regards, Wouter Slegers ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PGP Key Signing parties
On 2013-10-11 12:03:44 +0100 (+0100), Tony Naggs wrote:
Do key signing parties even happen much anymore? The last time I saw
one advertised was around PGP 2.6!
[...]
Within more active pockets of the global free software community
(where OpenPGP signatures are used to authenticate release
artifacts, security advisories, election ballots, access controls
and so on) key signing parties are an extremely common occurrence...
I'd say much more so now than a decade ago, as the community has
grown continually and developed an increasing need to be able to
recognize one another's output in a verifiable manner,
asynchronously, distributed over great distances and across
loosely-related subcommunities/projects.
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?
On Fri, Oct 11, 2013 at 10:32 AM, Zooko O'Whielacronx zoo...@gmail.com wrote: I like the ideas, John. The idea, and the protocol you sketched out, are a little reminiscent of ZRTP ¹ and of tcpcrypt ². I think you can go one step further, however, and make it *really* strong, which is to offer the higher or outer layer a way to hook into the crypto from your inner layer. This could be by the inner layer exporting a crypto value which the outer layer enforces an authorization or authenticity requirement on, as is done in ZRTP if the a=zrtp-hash is delivered through an integrity-protected outer layer, or in tcpcrypt if the Session ID is verified by the outer layer. Hi Zooko, Are you and John talking about the same thing? John's talking about tunnelling a redundant inner record layer of encryption inside an outer record layer (using TLS terminology). I think you're talking about a couple different-but-related things: * channel binding, where an unauthenticated-but-encrypted channel can be authenticated by performing an inside-the-channel authentication which commits to values uniquely identifying the outer channel (note that the inner vs outer distinction has flipped around here!) * out-of-band verification, where a channel is authenticated by communicating values identifying the channel (fingerprint, SAS, sessionIDs) over some other, authenticated channel (e.g. ZRTP's use of the signalling channel to protect the media channel). So I think you're focusing on *modularity* between authentication methods and the record layer, whereas I think John's getting at *redundancy*. I think the way that SSL combined transport layer security, authorization, and identification was a terrible idea. I (and others) have been saying all along that it was a bad idea, and I hope that the related security disasters during the last two years have started persuading more people to rethink it, too. This seems like a different thing again. I agree that TLS could have been more modular wrt key agreement and public-key authentication. It would be nice if the keys necessary to compute a TLS handshake were part of TLS, instead of requiring X.509 certs. This would avoid self-signed certs, and would allow the client to request various proofs for the server's public key, which could be X.509, other cert formats, or other info (CT, TACK, DNSSEC, revocation data, etc.). But this seems like a minor layering flaw, I'm not sure it should be blamed for any TLS security problems. The problems with chaining CBC IVs, plaintext compression, authenticate-then-encrypt, renegotiation, and a non-working upgrade path aren't solved by better modularity, nor are they solved by redundancy. They're solved by making better choices. I guess the designers of SSL were simply following the lead of the original inventors of public key cryptography, who delegated certain critical unsolved problems to an underspecified Trusted Third Party. What a colossal, historic mistake. If you're talking about the New Directions paper, Diffie and Hellman talk about a public file. Certificates were a later idea, due to Kohnfelder... I'd argue that's where things went wrong... 1. Go, go, go! The path your thoughts are taking seems fruitful. Just design a really good inner layer of crypto, without worrying (for now) about the vexing and subtle problems of authorization, authentication, naming, Man-In-The-Middle-Attack and so on. For now. That's easy though, right? Use a proper KDF from a shared secret, do authenticated encryption, don't f*ck up the IVs The worthwhile problems are the hard ones, no? :-) Trevor ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Key stretching
Phillip Hallam-Baker hal...@gmail.com writes: Quick question, anyone got a good scheme for key stretching? http://lmgtfy.com/?q=hkdfl=1 Peter :-). ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
