Re: [cryptography] US Appeals Court upholds right not to decrypt a drive
Jon Callas j...@callas.org writes: I've spoken to law enforcement and border control people in a country that is not the US, who told me that yeah, they know all about TrueCrypt and their assumption is that *everyone* who has TrueCrypt has a hidden volume and if they find TrueCrypt they just get straight to getting the second password. They said, We know about that trick, and we're not stupid. Ditto. One other thing that you need to add, the police are very, very good at getting information out of people. They've been doing it with hardened criminals for decades, so your average random geek is no problem. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] US Appeals Court upholds right not to decrypt a drive
Bill St. Clair billstcl...@gmail.com writes: Which is why the average random geek needs to be reminded, over and over again, that you NEVER talk to the police. Not a word. Ever. If you're feeling kind, write them a note, I don't talk to police. They should leave wondering whether you're mute. Uh, you know the bit where I said that the police are very good at getting information out of people? That also applies to people who initially decide that they don't want to talk to the police. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] US Appeals Court upholds right not to decrypt a drive
Which is why the average random geek needs to be reminded, over and over again, that you NEVER talk to the police. Not a word. Ever. If you're feeling kind, write them a note, I don't talk to police. They should leave wondering whether you're mute. Uh, you know the bit where I said that the police are very good at getting information out of people? That also applies to people who initially decide that they don't want to talk to the police. In the US, you should tell them you're not going to talk to them without your attorney present. That should shut them up. Assuming they follow the law, they must stop all questioning at that point. Assuming they make a written record of your request, anything they get from you (other than information you volunteer) after that point should be inadmissible. Note that there are two assumptions in this paragraph. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Explaining crypto to engineers (was: Duplicate primes in lots of RSA moduli)
Hi, here is an attempt to summarize view of crypto from engineers' point of view. It's based on discussing the points raised in the Duplicate primes... thread with couple of HW/SW engineers and past experience with colleagues. Sorry for the length, this post grew quite a bit. Hopefully I caught the main common points on cryptographer-engineer axis that cause crypto to get broken. (I have mostly SW engineering background with bits of HW engineering and crypto that stuck along the way.) Suggestions welcome for making it easier to explain to engineers, please correct my misconceptions/mistakes when you see them. This could be a good chance to do a first step in avoiding disasters like the shared primes. Due to length, here's a short summary of engineer's view (expanded on below): - short summary of typical SW/HW engineer's view on crypto and bugs - A) I don't understand why are you interested in crypto, you put some number in and get some number out, never really sure if there's an error in the program. In 3D graphics or physics simulation I see the bug almost instantly. (A friend's more than decade old quote, but still quite a spot on explanation why crypto bugs go often unnoticed for long time.) B) cryptography, n.: about 15-20 general principles and plethora of special cases, whose count maybe could be less than Graham's number. C) things that cause bugs: cooperation paradox, pushing engineer to code/build insanely fast (almost a guarantee of security bug) or changing specification often (mostly covered in previous messages in thread) D) implementation of crypto-protocol is hard: engineer must understand both the protocol and the platform where it will run on, platform's quirks and quirks of other endpoints' implementations the communication will lead to. High probability in introducing side-channels. E) often there is no one with sufficient experience/expertise to ask (the mentoring part mentioned in this thread) F) understanding randomness/entropy is very hard, implementing correctly extremely hard - end short summary - Some answers/opinions on Kevin's points, couple of suggestions and links that could help engineers understand crypto pitfalls: On 02/22/2012 03:31 AM, Kevin W. Wall wrote: From where I sit, I see the following things that the development community in general are lacking when it comes to things crypto: 1) They think that key size is the paramount thing; the bigger the better. I'm not sure this is really that common (except really newbie crypto enthusiasts). One recent good answer I got relating keysizes: http://lists.opendnssec.org/pipermail/opendnssec-user/2012-January/001619.html See last paragraph about ECDSA keys. Someone might be interested in reading the whole Default ZSK sizes thread - for example, we found that registrars shared ZSKs for tens of thousands of domains (also tons of 512 bit RSA keys). The registrars are slowly rolling them over ATM. And with ECDSA you have to avoid weak RNGs when generating signatures... Estimating RSA key size: it's more an educated guess/magic given how the sizes are derived than anything else. And if you base your estimate for given time window on Lenstra or ECRYPT II keysize recommendations you might get reprimanded for suggesting too conservative values :-) 2) The have no clue as to what cipher modes are. It's ECB by default. Following image in the wiki article worked like charm in explaining why ECB is usually not what the developer wants: https://secure.wikimedia.org/wikipedia/en/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29 3) More importantly, they don't know how to choose a cipher mode (not surprising, given #2). They need to understand the trade-offs. 4) They have no idea about how to generate keys, derived keys, IVs, A good article explaining the Vaudenay padding oracle (mostly leaves imprint on developers if they dedicate the 30-60 min to read it thoroughly), explains why modes are important along the way and gives insight into engineer's mind: http://chargen.matasano.com/chargen/2009/7/22/if-youre-typing-the-letters-a-e-s-into-your-code-youre-doing.html There was even better article from Matasano that showed the Vaudenay's attack nicely step-by-step, included commentary about IV selection (can't find it right now). NaCl library - should have sane enough defaults to make it hard for a non-crypto-devoted developer to screw things up: http://nacl.cr.yp.to/ (Also the already mentioned PBKDF2 - for some reason people seem to fear the five-letter acronym, but once you explain how simple it really is and that it's present in every serious crypto library, they catch up quickly.) Question regarding the IVs: is there a cryptographically-secure pseudo-random permutation generation function for that? I've seen notices in this thread but can't remember if one was named explicitly. (Sure one could code one up from a PRNG, but I wouldn't want to be the person that
Re: [cryptography] US Appeals Court upholds right not to decrypt a drive
On Sat, Feb 25, 2012 at 2:50 AM, Jon Callas j...@callas.org wrote: [snip] But to get to the specifics here, I've spoken to law enforcement and border control people in a country that is not the US, who told me that yeah, they know all about TrueCrypt and their assumption is that *everyone* who has TrueCrypt has a hidden volume and if they find TrueCrypt they just get straight to getting the second password. They said, We know about that trick, and we're not stupid. Well, they'd be wrong with that assumption then. I asked them about the case where someone has TrueCrypt but doesn't have a hidden volume, what would happen to someone doesn't have one? Their response was, Why would you do a dumb thing like that? The whole point of TrueCrypt is to have a hidden volume, and I suppose if you don't have one, you'll be sitting in a room by yourself for a long time. We're not *stupid*. That's good to know then. I never had anything *that* secret to protect, so never bothered to create a hidden volume. I just wanted a good, cheap encrypted volume solution where I could keep my tax records and other sensitive personal info. And if law enforcement ever requested the password for that, I wouldn't hesitate to hand it over if they had the proper subpoena / court order. But I'd be SOL when then went looking for a second hidden volume simply because one doesn't exist. Guess if I ever go out of the country with my laptop, I'd just better securely wipe that partion. -kevin -- Blog: http://off-the-wall-security.blogspot.com/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We *cause* accidents.-- Nathaniel Borenstein ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] trustwave admits issuing corporate mitm certs
On Sun, 12 Feb 2012, Jeffrey Walton wrote: (2) Did the other end of the SSL/TLS tunnel also agree to be monitored? Ding! Yes, that is the key - and was the key the first time we visited this subject a few months ago. When all is said and done, and Jane Doe cube peasant signs away her life, and the browsers all look the other way and every CA is doing it ... after all of that, does Wells Fargo actually consent to your bullshit Fortune 30,000 firm monitoring their online banking ? I'll bet not. How about eftps.gov ? How about dmv.ca.gov ? There are two sides to an SSL transaction ... ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] trustwave admits issuing corporate mitm certs
On 02/25/2012 05:55 PM, John Case wrote: When all is said and done, and Jane Doe cube peasant signs away her life, and the browsers all look the other way and every CA is doing it ... after all of that, does Wells Fargo actually consent to your bullshit Fortune 30,000 firm monitoring their online banking ? I'll bet not. How about eftps.gov ? How about dmv.ca.gov ? There are two sides to an SSL transaction ... I agree with that sentiment. Still it might be worth pointing that if Wells Fargo really wanted to forbid a Trustwave network-level MitM, SSL/TLS provides the capability to enforce that policy at the protocol level. They could configure their web app to require a client cert (either installed in the browser or from a smart card). Would it be free? No. Would it work in every situation on every weird device anyone ever wanted to use? No. Would it protect from malware on the client system? No. Would it be less convenient for everyone? Yes. But there are some pretty large deployments out there, which proves that it is at least possible. B2b and embedded protocols use client certs all the time. If they were more widely used, they would certainly get easier to deploy. So if there are actually effective ways that a web site could disable Trustwave-style MitM, and the site elects not to deploy them for reasons that are essentially just cost and convenience, someone might make the argument that it represents tacit approval. I don't think I would try to make that argument in the current web environment today. But maybe we'll see it being made by someone at some point in the future? - Marsh ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] US Appeals Court upholds right not to decrypt a drive
On 2012-02-25 5:50 PM, Jon Callas wrote: There is no such thing as plausible deniability in a legal context. Plausible deniability is a term that comes from conspiracy theorists (and like many things contains a kernel of truth) to describe a political technique where everyone knows what happened but the people who did it just assert that it can't be proven, along with a wink and a nudge. Does the phrase innocent until proven guilty ring any bells? Similarly, there is no inner volume on a truecrypt drive until it is proven that there is, and so you cannot be compelled to produce a key that has not been proven to exist. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] US Appeals Court upholds right not to decrypt a drive
Jon Callasj...@callas.org writes: I've spoken to law enforcement and border control people in a country that is not the US, who told me that yeah, they know all about TrueCrypt and their assumption is that *everyone* who has TrueCrypt has a hidden volume and if they find TrueCrypt they just get straight to getting the second password. They said, We know about that trick, and we're not stupid. They may assume that - but they cannot prove it. On 2012-02-25 9:36 PM, Peter Gutmann wrote: Ditto. One other thing that you need to add, the police are very, very good at getting information out of people. They've been doing it with hardened criminals for decades, so your average random geek is no problem. Evidently in the case of http://www.ca11.uscourts.gov/opinions/ops/201112268.pdf They were totally unable to get information out of John Doe For the entire case turned on the fact that John Doe never admitted the existence of the hidden drive, and forensics were entirely unable to prove the existence of the hidden drive. Customs may have the authority to search through your stuff, but if they cannot find what they are looking for, they have no authority to make you tell them that it exists and where it is. But if you *do* tell them that it exists, then they can make you tell them where it is. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] (off-topic) Bitcoin is a repeated lesson in cryptography applications - was endgame
On 2012-02-26 1:18 AM, Benjamin Kreuter wrote: The demand for Bitcoin as a currency is driven by its properties as a digital cash system; people still need to get their nation's currency at some point Frau Eisenmenger writes in her 1919 diary: http://www.wolf1168.us/misc/Articles%20of%20Interest/When%20Money%20Dies.pdf I survey my remaining 1,000-kronen notes mistrustfully, lying by the side of the pack of unredeemed food cards in the writing table drawer. Will they not perhaps share the fate of the food cards if the State fails to keep the promise made on the inscription on every note? The State still accepts its own money for the scanty provisions it offers us. The private tradesman already refuses to sell his precious wares for money and demands something of real value in exchange. The wife of a doctor whom I know recently exchanged her beautiful piano for a sack of wheat flour. I, too, have exchanged my husband's gold watch for four sacks of potatoes, ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
