September 2013 - cypherpunks - lists.cpunks.org

Re: [liberationtech] Random number generation being influenced - rumors
by Eugen Leitl 07 Sep '13

07 Sep '13

----- Forwarded message from Andy Isaacson <adi(a)hexapodia.org> ----- Date: Fri, 6 Sep 2013 22:24:00 -0700 From: Andy Isaacson <adi(a)hexapodia.org> To: liberationtech <liberationtech(a)lists.stanford.edu> Subject: Re: [liberationtech] Random number generation being influenced - rumors User-Agent: Mutt/1.5.20 (2009-06-14) Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> On Sat, Sep 07, 2013 at 12:51:19AM +0300, Maxim Kammerer wrote: > On Fri, Sep 6, 2013 at 10:34 PM, Andy Isaacson <adi(a)hexapodia.org> wrote: > > This is not to say that RdRand is completely unusable. Putting RdRand > > entropy into a software pool implementation like /dev/urandom (or > > preferably, a higher-assurance multipool design like Fortuna) is a cheap > > way to prevent a putative backdoor from compromising your system state. > > Nearly nothing from what you wrote is relevant to RDRAND, which is not > a pure HWRNG, but implements CTR_DRBG with AES (unclear whether > 128/192/256) from NIST SP 800-90A [1,2]. That's the claimed design, yes. I see no particular reason to believe that the hardware in my server implements the design. I can't even test that the AES whitening does what it is documented to do, because Intel refused to provide access to the prewhitened input. Providing accessible "test points" (software interfaces to the innards of the implementation, with documentation of expected behavior between the components) would be the absolute minimum to provide believable assurance of the absence of a backdoor. Better would be documents from Intel of how the chip is designed at the mask level, and a third party mill-and-microphotograph of a retail chip showing that the shipped implementation matches the design. Intel will never go for that, of course, since their chip masks are their jealously guarded IP. Since they can't provide evidence of a lack of a backdoor, any reasonably cautious user should avoid depending on Intel's implementation. -andy -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [Cryptography] Why prefer symmetric crypto over public key crypto?
by Eugen Leitl 07 Sep '13

07 Sep '13

----- Forwarded message from "Marcus D. Leech" <mleech(a)ripnet.com> ----- Date: Fri, 06 Sep 2013 23:51:49 -0400 From: "Marcus D. Leech" <mleech(a)ripnet.com> To: cryptography(a)metzdowd.com Subject: Re: [Cryptography] Why prefer symmetric crypto over public key crypto? User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 > > The magic of public key crypto is that it gets rid of the key > management problem -- if I'm going to communicate with you with > symmetric crypto, how do I get the keys to you? The pain of it is > that it replaces it with a new set of problems. Those problems > include that the amazing power of public-key crypto tempts one to > do things that may not be wise. > I find public-key cryptography to be full of "dirty little secrets". Some of the notions inherent in public-key *infrastructure* are, on the face of them, preposterous. Consider the notion of a certificate authority. I am to trust some third party (the CA) that I've never met, and have not the slightest reason to trust, is able to make a "believable" assertion about the identity (and corresponding public-key binding), of some *other* party I've never met, and have no real reason to trust. It always struck me as another instance of "there's no problem in CS that can't be solved by adding another layer of abstraction". I think this is an instance of a general problem with digitally-signed documents of all kinds: confusion about exactly what they are--a signature on a document (like a certificate) says nothing about the *essential truth* of the statements contained within the document. When SlushySign issues a certificate for "www.crowbars-r-us.com", there's a subtle distinction between "we believe this to be the appropriate binding between this public-key, and an entitity known as www.crowbars-r-us.com" and "this really is the binding between this pubic-key, and the entity you all know as www.crowbars-r-us.com". I started thinking about the "essential truth" problem back when the whole TPM thing was popular, and proponents were talking as if the digital signature of a computer stating that it was "sane" was somehow the same is said computer actually being "sane". Absent independent verification, there's no way to distinguish a strongly-signed "lie" from a strongly-signed "truth". That isn't necessarily a problem that's confined to PK systems. Any digital-signature scheme has that problem. The other thing that I find to be a "dirty little secret" in PK systems is revocation. OCSP makes things, in some ways, "better" than CRLs, but I still find them to be a kind of "swept under the rug" problem when people are waxing enthusiastic about PK systems. However, PK is the only pony we've managed to bring to this circus, so, we we "make do" with making the "dirty little secrets" as inoffensive as we can. _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [Cryptography] NSA hates sunshine
by Eugen Leitl 07 Sep '13

07 Sep '13

----- Forwarded message from John Gilmore <gnu(a)toad.com> ----- Date: Fri, 06 Sep 2013 19:13:17 -0700 From: John Gilmore <gnu(a)toad.com> To: Paul Hoffman <paul.hoffman(a)vpnc.org> Cc: Andy Steingruebl <steingra(a)gmail.com>, "cryptography(a)metzdowd.com List" <cryptography(a)metzdowd.com> Subject: Re: [Cryptography] NSA hates sunshine > > As of Jan-2014 CAs are forbidden from issuing/signing anything less than 2048 certs. > > For some value of "forbidden". :-) Yeah, just like employees at big companies are "forbidden" to reveal how they are collaborating with NSA. Years ago I heard what happened when George Davida filed a patent on something related to encryption, all the way back in 1978, and eventually received a communication from the government telling him that his patent was subject to patent secrecy, that it would never issue, and that he could not even tell anyone that it had been suppressed, nor could he ever tell anyone how his invention worked. In theory, the law was all on the NSA's and the patent office's side. But in fact, they were in a very weak position. Instead of acquiescing, Davida shouted it to the housetops, engaged the press and his university about censorship of academic freedom, involved his Congressperson, etc. Within months, the secrecy order was rescinded. NSA hates sunshine. NSA secrecy relies on the cowardice of most people. Courage is all it takes to beat them. If NSA tries to shut you up, just shine a lot of attention on their attempt to shut you up. Spread the information that they are trying to suppress, far and wide. Send copies to a dozen random post-office boxes in different cities, asking the recipient to physically bring it in to their local newspaper. Leave your cellphone at home, then stash copies in places that you don't frequent, so that government agents can't come raid your house and office and steal all copies of what they're trying to suppress. In my case I posted something like this (a suppressed paper by Ralph Merkle) to Usenet, and it was suddenly on thousands of servers overnight. NSA habitually decides that the publicity that their activities get from any continued effort to suppress the information is FAR worse than the damage caused by the initial release of the info. Any efforts they make to shut you up, prosecute you, jail you, etc give you a perfect soapbox, and the attention of the news media and the public. Keep repeating the info, from your jail cell if necessary, and you're likely to win. Because if NSA relents, your revelations become "last week's news" and get a lot less public attention. When NSA found out I had copies of an early encryption tutorial that they considered classified (I was suing them under FOIA to get a copy, but then found copies in a public library), they first tried to persuade my lawyer to "bring in all the copies so we can secure them in a safe place". That's NSA-ese for "throw them down a deep hole where you'll never see them again". When we refused, and instead contacted the New York Times, which printed a story about the attempted suppression, NSA and DoJ buckled within one day. (Indeed, the way I found out they had suddenly declassified the document is that they called the NYT reporter to tell him. They never did tell me; I got the news from the reporter.) As part of suing the government, the Al Haramain foundation accidentally received a government report making it clear that the government had illegally wiretapped their phone calls. They noticed this but it took the government 60 days to notice. Unfortunately, instead of making hundreds of copies of the document, and spreading them all over the world and to the press, they did what the government asked, and destroyed all their copies of the document. Once all copies of the document were gone, NSA went to the court and claimed first that the whole thing was a state secret and couldn't proceed, and then second that the group didn't have any standing to challenge the wiretaps in court because Al Haramain (now) had zero evidence that the taps had even occurred. The foundation and their lawyers have literally spent years of work recovering from that one mistake, and only the kind indulgence of a smarter than average judge enabled their lawsuit to survive at all. See this story by one of their lawyers: http://www.salon.com/2008/07/09/alharamain_lawsuit/ Don't make the same mistake when NSA, or their minions at the FBI or FISA or DoJ come to threaten YOU to suppress information that came to you through no fault of your own. John Gilmore _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

[tor-talk] NIST approved crypto in Tor?
by Eugen Leitl 07 Sep '13

07 Sep '13

----- Forwarded message from "Sebastian G. <bastik.tor>" <bastik.tor(a)googlemail.com> ----- Date: Sat, 07 Sep 2013 11:25:24 +0200 From: "Sebastian G. <bastik.tor>" <bastik.tor(a)googlemail.com> To: tor-talk(a)lists.torproject.org Subject: [tor-talk] NIST approved crypto in Tor? User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 Reply-To: tor-talk(a)lists.torproject.org Hi, Tor switches over to ECC what's a reasonable step. I'm unable to find the blog post (or maybe it was an official comment on the blog) [With DDG and StartPage] where someone said that if the NIST (I guess) is not lying ECC is safe. Is the ECC used by Tor in some way certified by NIST? Are other parts of Tor certified by NIST? Recent leaks revealed that the NSA spends many resources in influencing standards to make their lives easier (or not too hard). NIST could be either participating or tricked into preferring standards that are weak in some regard. Note that I'm not saying that this is the case, but it could be. I was able (it was not a blog post, it was an essay) to find what Bruce Schneier wrote about the NSA preferring a weak random-number-generator. [1] Quotes [my comments, notes]: "The U.S. government released a new official standard for random-number generators this year [essay from 2007], and it will likely be followed by software and hardware developers around the world." "(...) the 130-page document contains four different approved techniques, called (...) "Deterministic Random Bit Generators." All four are based on existing cryptographic primitives. One is based on hash functions, one on HMAC, one on block ciphers and one on elliptic curves." " (...) one of those generators (...) Dual_EC_DRBG [elliptic], (...) three orders of magnitude slower than its peers." " It's in the standard only because it's been championed by the NSA, which first proposed it years ago in a related standardization project at the American National Standards Institute." "The math is complicated, but the general point is that the random numbers it produces have a small bias. [2006 knowledge]" "But today [2007] there's an even bigger stink brewing around Dual_EC_DRBG" (...) Dan Shumow and Niels Ferguson showed that the algorithm contains a weakness that can only be described as a backdoor." "There are a bunch of constants -- fixed numbers -- in the standard used to define the algorithm's elliptic curve. These constants are listed in Appendix A of the NIST publication, but nowhere is it explained where they came from." " (...) these numbers have a relationship with a second, secret set of numbers (...). If you know the secret numbers, you can predict the output of the random-number generator after collecting just 32 bytes of its output. (...) you only need to monitor one TLS internet encryption connection in order to crack the security of that protocol. If you know the secret numbers, you can completely break any instantiation of Dual_EC_DRBG." "The researchers don't know what the secret numbers are. (...) the way the algorithm works, the person who produced the constants might know; he had the mathematical opportunity to produce the constants and the secret numbers in tandem." " (...) we have no way of knowing whether the NSA knows the secret numbers that break Dual_EC-DRBG [or not, we can't know]" Read the full essay which contains links to papers if you are interested. And the NSA work on standards repeatedly. "The NSA has always been intimately involved in U.S. cryptography standards -- it is, after all, expert in making and breaking secret codes." That's also what comes out of the Snowden leaks. I understand that ECC used for Tor is different from what the essay is about. However the NSA may found something it can exploit in ECC and made NIST (maybe unknowingly) standardize the curve (or whatever) that is most vulnerable or recommends for a weak one, or for too short keys. Does Tor use stuff certified or recommended by NIST? If so would it be reasonable to move to international standards (whatsoever) without the involvement of NIST and NSA 'consultation'? (Completely unrelated to what might be going on, just as defense-in-depth.) The NSA likes playing around. [2][3] (found while searching) Oh and I'm not trying fear-mongering here or try to conspire whenever or not the NSA has subverted cryptographic functions (in one way or another). Best, Sebastian G. [1] https://www.schneier.com/essay-198.html [2] https://www.schneier.com/blog/archives/2008/01/nsa_backdoors_i.html [3] https://www.schneier.com/blog/archives/2013/07/simon_and_speck.html -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN"
by Eugen Leitl 07 Sep '13

07 Sep '13

----- Forwarded message from Jon Callas <jon(a)callas.org> ----- Date: Fri, 6 Sep 2013 17:58:33 -0700 From: Jon Callas <jon(a)callas.org> To: Jerry Leichter <leichter(a)lrw.com> Cc: cryptography(a)metzdowd.com, Jon Callas <jon(a)callas.org>, "Perry E. Metzger" <perry(a)piermont.com> Subject: Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN" X-Mailer: Apple Mail (2.1508) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 6, 2013, at 6:23 AM, Jerry Leichter <leichter(a)lrw.com> wrote: > Is such an attack against AES *plausible*? I'd have to say no. But if you were on the stand as an expert witness and were asked under cross-examination "Is this *possible*?", I contend the only answer you could give is "I suppose so" (with tone and body language trying to signal to the jury that you're being forced to give an answer that's true but you don't in your gut believe it). I'd be happy to give a different answer, like -- almost certainly not. > > Could an encryption algorithm be explicitly designed to have properties like this? I don't know of any, but it seems possible. I've long suspected that NSA might want this kind of property for some of its own systems: In some cases, it completely controls key generation and distribution, so can make sure the system as fielded only uses "good" keys. If the algorithm leaks without the key generation tricks leaking, it's not just useless to whoever grabs onto it - it's positively hazardous. The gun that always blows up when the bad guy tries to shoot it.... We know as a mathematical theorem that a block cipher with a back door *is* a public-key system. It is a very, very, very valuable thing, and suggests other mathematical secrets about hitherto unknown ways to make fast, secure public key systems. To me, it's like getting a cheap supply of gold and then deciding you'll make bullets out of it instead of lead. To riff on that analogy, it feels like you're suggesting that they would shoot themselves in the foot because they know that the bullet fragments will hurt their opponent. That's why I say almost certainly not. It suggests irrationality beyond my personal ken. It's something I classify colloquially as "too stupid to live." My assumptions about the NSA are that they're smart, clever, and practical. Conjectures about their behavior that deviate from any of those axes ring false to the degree that they deviate from that. My conjectures start with assuming they're at least as smart as me, and I start with "what would I do if I were them?" I think they're smart enough not to attack the strong points of the system, but the weak points. I think they're smart enough to prefer operating in stealth. Yeah, yeah, sure, if with those resources I stumbled into a fundamental mathematical advantage, I'd use it. But I would use it to maximize my gain, not to be gratuitously sneaky. The math we know about block ciphers suggests (not proves, suggests) that a back door in a cipher is impractical, because it would imply the holy grail of public key systems -- fast, secure, public key crypto. It suggests secure trapdoor functions that can be made out of very simple components. If I found one, it would be great, but I'd devote my resources to places where I technology is on my side. Those include network security and software security, along with traffic analysis. If I wanted to devote research resources, I'd be looking closely at language-theoretic security. I'd be paying close attention to the fantastic things that have come out of there. The stuff that Bangert, Bratus, Shapiro, and Smith did on turning an MMU into a Turing machine is where I'd devote research, as well as their related work on "weird machines." I apologize for repeating myself, but I'd fight the next war, not the last one. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFSKno7sTedWZOD3gYRAjMUAJ9qDQcQZVr/1580qZStlu/7fFgLIwCg2U5r WFth65Vi4GIDF1wu5oVukYs= =M/f+ -----END PGP SIGNATURE----- _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [cryptography] Compositing Ciphers?
by Eugen Leitl 07 Sep '13

07 Sep '13

----- Forwarded message from Natanael <natanael.l(a)gmail.com> ----- Date: Sat, 7 Sep 2013 02:53:22 +0200 From: Natanael <natanael.l(a)gmail.com> To: noloader(a)gmail.com Cc: Cryptography List <cryptography(a)randombit.net> Subject: Re: [cryptography] Compositing Ciphers? http://blog.cryptographyengineering.com/2012/02/multiple-encryption.html Apparently it's called "cascade encryption" or "cascade encipherment", and the implementations are apparently called "robust combiners". And by the way, Truecrypt already lets you pick your chosen combo of AES and two other ciphers. I think you should worry about your PRNG and it's seed before you focus on AES. Your key should both have enough entropy and be secret. Is your PRNG backdoored already? And I'm guessing the cipher mode probably matters a bit more than the exact choice of algorithm. On Sat, Sep 7, 2013 at 2:27 AM, Jeffrey Walton <noloader(a)gmail.com> wrote: > Hi All, > > With all the talk of the NSA poisoning NIST, would it be wise to > composite ciphers? (NY Times, Guardian, Dr. Green's blog, et seq). > > I've been thinking about running a fast inner stream cipher (Salsa20 > without a MAC) and wrapping it in AES with an authenticated encryption > mode (or CBC mode with {HMAC|CMAC}). > > I'm aware of, for example, NSA's Fishbowl running IPSec at the network > layer (the "outer" encryption") and then SRTP and the application > level (the "inner" encryption). But I'd like to focus on hardening one > cipherstream at one level, and not cross OSI boundaries. > > I'm also aware of the NSA's lightweight block ciphers > (http://eprint.iacr.org/2013/404) I may have been born at night, but > it was not last night.... > > Has anyone studied the configuration and security properties of a > inner stream cipher with an outer block cipher? > > Jeff > _______________________________________________ > cryptography mailing list > cryptography(a)randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

[cryptography] Compositing Ciphers?
by Eugen Leitl 07 Sep '13

07 Sep '13

----- Forwarded message from Jeffrey Walton <noloader(a)gmail.com> ----- Date: Fri, 6 Sep 2013 20:27:47 -0400 From: Jeffrey Walton <noloader(a)gmail.com> To: Cryptography List <cryptography(a)randombit.net> Subject: [cryptography] Compositing Ciphers? Reply-To: noloader(a)gmail.com Hi All, With all the talk of the NSA poisoning NIST, would it be wise to composite ciphers? (NY Times, Guardian, Dr. Green's blog, et seq). I've been thinking about running a fast inner stream cipher (Salsa20 without a MAC) and wrapping it in AES with an authenticated encryption mode (or CBC mode with {HMAC|CMAC}). I'm aware of, for example, NSA's Fishbowl running IPSec at the network layer (the "outer" encryption") and then SRTP and the application level (the "inner" encryption). But I'd like to focus on hardening one cipherstream at one level, and not cross OSI boundaries. I'm also aware of the NSA's lightweight block ciphers (http://eprint.iacr.org/2013/404) I may have been born at night, but it was not last night.... Has anyone studied the configuration and security properties of a inner stream cipher with an outer block cipher? Jeff _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN"
by Eugen Leitl 07 Sep '13

07 Sep '13

----- Forwarded message from John Gilmore <gnu(a)toad.com> ----- Date: Fri, 06 Sep 2013 17:22:26 -0700 From: John Gilmore <gnu(a)toad.com> To: Cryptography <cryptography(a)metzdowd.com>, gnu(a)toad.com Subject: Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN" Speaking as someone who followed the IPSEC IETF standards committee pretty closely, while leading a group that tried to implement it and make so usable that it would be used by default throughout the Internet, I noticed some things: * NSA employees participted throughout, and occupied leadership roles in the committee and among the editors of the documents * Every once in a while, someone not an NSA employee, but who had longstanding ties to NSA, would make a suggestion that reduced privacy or security, but which seemed to make sense when viewed by people who didn't know much about crypto. For example, using the same IV (initialization vector) throughout a session, rather than making a new one for each packet. Or, retaining a way to for this encryption protocol to specify that no encryption is to be applied. * The resulting standard was incredibly complicated -- so complex that every real cryptographer who tried to analyze it threw up their hands and said, "We can't even begin to evaluate its security unless you simplify it radically". See for example: https://www.schneier.com/paper-ipsec.html That simplification never happened. The IPSEC standards also mandated support for the "null" encryption option (plaintext hiding in supposedly-encrypted packets), for 56-bit Single DES, and for the use of a 768-bit Diffie-Hellman group, all of which are insecure and each of which renders the protocol subject to downgrade attacks. * The protocol had major deployment problems, largely resulting from changing the maximum segment size that could be passed through an IPSEC tunnel between end-nodes that did not know anything about IPSEC. This made it unusable as a "drop-in" privacy improvement. * Our team (FreeS/WAN) built the Linux implementation of IPSEC, but at least while I was involved in it, the packet processing code never became a default part of the Linux kernel, because of bullheadedness in the maintainer who managed that part of the kernel. Instead he built a half-baked implementation that never worked. I have no idea whether that bullheadedness was natural, or was enhanced or inspired by NSA or its stooges. In other circumstances I also found situations where NSA employees explicitly lied to standards committees, such as that for cellphone encryption, telling them that if they merely debated an actually-secure protocol, they would be violating the export control laws unless they excluded all foreigners from the room (in an international standards committee!). The resulting paralysis is how we ended up with encryption designed by a clueless Motorola employee -- and kept secret for years, again due to bad NSA export control advice, in order to hide its obvious flaws -- that basically XOR'd each voice packet with the same bit string! Their "encryption" scheme for the control channel, CMEA, was almost as bad, being breakable with 2^24 effort and small numbers of ciphertexts: https://www.schneier.com/cmea-press.html To this day, no mobile telephone standards committee has considered or adopted any end-to-end (phone-to-phone) privacy protocols. This is because the big companies involved, huge telcos, are all in bed with NSA to make damn sure that working end-to-end encryption never becomes the default on mobile phones. John Gilmore _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [tor-talk] Tor users are not anonymous
by grarpamp 07 Sep '13

07 Sep '13

On 9/6/13, Carsten N. <cane(a)jondos.de> wrote: > An analysis of Truecrypt was done by the Privacy-CD team: > > en: https://www.privacy-cd.org/downloads/truecrypt_7.0a-analysis-en.pdf > de: https://www.privacy-cd.org/downloads/truecrypt_7.0a-analysis-de.pdf Just taking a moment to thank anyone reviewing the code of others. Regardless of how complete or accurate, or even in some cases dated, the review is... this donation of time to the betterment of some other project than your own is *important* and needed for the open source model to succeed, especially up against the adversaries we all face together. Thanks.

1 0

[guardian-dev] Crazy Nate's Guardian Project Open-Source Secure App Emporium!
by Eugen Leitl 07 Sep '13

07 Sep '13

----- Forwarded message from Nathan of Guardian <nathan(a)guardianproject.info> ----- Date: Fri, 06 Sep 2013 12:19:51 -0400 From: Nathan of Guardian <nathan(a)guardianproject.info> To: Guardian Dev <guardian-dev(a)lists.mayfirst.org> Subject: [guardian-dev] Crazy Nate's Guardian Project Open-Source Secure App Emporium! User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Happy Friday everyone! Keep your chins up out there. https://www.youtube.com/watch?v=3KBcbumRX9I Crazy Nate with an important message for all of you lamenting the loss of your private bits... I am here with some good news... Announcing the: Crazy Nate's Guardian Project Open-Source Secure App Emporium! All Year, All Time Blow Out Sale! with savings up to 100% for ever We've got Bots that eat Onions Onions for your Webs Browsers that can Proxy and Proxies that can Mobilize, Anonymize and Obfuscate! Off-the-record Chats and On-the-record Cameras Blurry Cameras, Smart Cameras and everything in between! And for you developers, developers, developers out there, don't think we forgot about you! Ciphers for your SQL Ciphers for your IO Ciphers for your Network and to wrap it up, the Lilest Debi evah! We've got it all for the very low price of FREEEEEE! You get the app for free. The code for free. The developer support for free. You can mix it, mash it, slice it and dice it. Free Code, Free Beer, Free Speech, what more can you want? and if you act now, we might just thrown in some Free Dumb too! This is a non-limited time 365 day a year sale, with prices that are insane, but true! Crazy Nate's Guardian Project Open-Source Secure App Emporium! WOW! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSKgCnAAoJEKgBGD5ps3qppAEP/3kp1q3FxYSpD7MoeCiVwXf1 DJwvhgat+5PXAg1GjTq2zJnoZpkEAlLRCifqUVsbw++3wRTNJOkENNHxAEAKdKtn KI7lDWmSeaT9JOCyYeGaZGi8GqiEuLfyHLZKtpgB5D0uasTdAc+zyU8RgI5mWZUa sLgWvXX4aLdQ9foHmtwasB8zNEXh3rcTEYOG2KXwgtfem2VNxJ7fno/73E822JFL Ji0Qp2JPEJVHozuWqx1OkfHOsJYP6N6tIw5HrpqUagY94Dlsn4pumvZ0sIYacrU6 ViEmFIr4XX4rP8JOrfQjaqyMKh44LbaX5CWBf+1Lq4b8kdryeKebfe4skq7ZpJOG yW5UhNecpL+0j7rD7iDpqiiqfVlRwils0WqDnFNiHzystPcYOWmo8I1QeAF1CL0L ZiOY1YSup0u/0IJmgazcD5zfadiROY0uEjZWLTlV9Ctbt2cGjFw25O5vDv+f39Fd yZDc5FqDt9DAWYaHoHE0/NnbDJ8NdfTr1geZ8SlQ0xQBvJbSlN7kRtsN0iavEfkS XbN1Dh1VYA8jHLdPbh1Pv9gYN4u7R4I6ylSRCNBlekZ/mFmc+XOfK8HqvQGIx+Ik p5yteUx9RzfFZzrWs0TrmcY2NNCd6Wwnmdd7OfwcniyBLbGOiDr4I9RLPMEKnI6W Rlkbb3Cu3yHoctdaV8ob =VA2N -----END PGP SIGNATURE----- _______________________________________________ Guardian-dev mailing list Post: Guardian-dev(a)lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: Guardian-dev-unsubscribe(a)lists.mayfirst.org Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/eugen%40leitl.org You are subscribed as: eugen(a)leitl.org ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

2 1