- cypherpunks - lists.cpunks.org

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

09 Sep '13

----- Forwarded message from Doug Barton <dougb(a)dougbarton.us> ----- Date: Sun, 08 Sep 2013 15:44:05 -0700 From: Doug Barton <dougb(a)dougbarton.us> To: nanog(a)nanog.org Subject: Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 On 09/08/2013 02:25 AM, Eugen Leitl wrote: > ----- Forwarded message from Gregory Perry <Gregory.Perry(a)govirtual.tv> ----- > > Date: Sat, 7 Sep 2013 21:14:47 +0000 > From: Gregory Perry <Gregory.Perry(a)govirtual.tv> > To: Phillip Hallam-Baker <hallam(a)gmail.com> > Cc: "cryptography(a)metzdowd.com" <cryptography(a)metzdowd.com>, ianG <iang(a)iang.org> > Subject: Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN" > > On 09/07/2013 05:03 PM, Phillip Hallam-Baker wrote: > > Good theory only the CA industry tried very hard to deploy and was prevented from doing so because Randy Bush abused his position as DNSEXT chair to prevent modification of the spec to meet the deployment requirements in .com. > > DNSSEC would have deployed in 2003 with the DNS ATLAS upgrade had the IETF followed the clear consensus of the DNSEXT working group and approved the OPT-IN proposal. The code was written and ready to deploy. > > I told the IESG and the IAB that the VeriSign position was no bluff and that if OPT-IN did not get approved there would be no deployment in .com. A business is not going to spend $100million on deployment of a feature that has no proven market demand when the same job can be done for $5 million with only minor changes. I was also there in 2003, and for a long time before that, and was also one of the voices that was saying that we needed opt-in, and protection from zone walking, or else the thing wouldn't fly. I don't recall that any 1 person was the reason those things didn't happen sooner than they did; in fact I recall near-universal sentiment that zone walking was a non-issue, and that opt-in defeated the very nature of what DNSSEC was trying to accomplish. Fast forward to my time at IANA in 2004 and after considerable behind the scenes organization a coalition of TLD registries came forward and said that they would not deploy DNSSEC without those 2 features, and were willing to dedicate the resources to create them. So it was not 1 person who stopped DNSSEC deployment, and it wasn't 1 person who made it happen. Your larger point about fiefdoms and oligarchies in the IETF is, however, tragically accurate. The blindness of the DNSSEC literati to the real-world needs was a huge part of what caused the delay in deployment on the authoritative side, and the malaise caused by the decade+ of fighting to get it out the door is a big contributor to what's preventing any real solution to the last mile problem (which is what it takes to make DNSSEC really useful). Doug ----- 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: [guardian-dev] APK signing keys are vulnerable WAS: pgp, nsa, rsa
by Eugen Leitl 09 Sep '13

09 Sep '13

----- Forwarded message from Daniel McCarney <daniel(a)binaryparadox.net> ----- Date: Sun, 8 Sep 2013 18:31:35 -0400 From: Daniel McCarney <daniel(a)binaryparadox.net> To: Hans of Guardian <hans(a)guardianproject.info>, guardian-dev <guardian-dev(a)lists.mayfirst.org> Subject: Re: [guardian-dev] APK signing keys are vulnerable WAS: pgp, nsa, rsa > Wow, that is bad news indeed. It would be awesome to have androidobservatory.org also display full info about the signing keys, like the algorithm used, the bitness, generation date, etc. so we can easily check which keys are vulnerable. Working on rolling that functionality out. I had to rewrite the app import pipeline so that I could store that information. I have the data collected but it isn't user facing yet. I can tell you that looking at the ~6,000 unique certificates in the observatory data about 75% are RSA 1024. As far as I'm aware it isn't possible to learn the key generation date from the certificate data in the PKCS7 structure stored in the META-INF directory of an APK. > I figure if the NSA can break 1024 bit RSA, its only a matter of time before China also has that capability. China are experts at industrial espionage, and they certainly know how to make chips. It is very conceivable that they could acquire the NSA's RSA cracking chip design and then build it domestically. Then I imagine that China would also be willing to sell those chips to allies, or perhaps even the highest bidder. Yeah, the current NIST[1] advice on key sizes is very clear that 1024 bit RSA should be deprecated (though evidently NIST might not be an unbiased source of information...). > We'll have to make sure our signing key is not 1024 bit, and if so, work on a migration plan. The easiest way to start is to sign all new apps with a new key. The pubkey in the cert used for the core Guardian Properties (ChatSecure, Obscuracam, etc) is definitely 1024 RSA. So is the pubkey in the cert used for Orweb. It would definitely be a good idea to start talking about migration plan, (and using a strong keysize in a new cert for all new properties) - Dan [1] http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf _______________________________________________ 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

1 0

Quark : A Web Browser with a Formally Verified Kernel
by Eugen Leitl 09 Sep '13

09 Sep '13

http://goto.ucsd.edu/quark/ Quark : A Web Browser with a Formally Verified Kernel University of California, San Diego Computer Science and Engineering Quark is an experimental, formally verified browser. Watch it run popular sites like GMail, Facebook, and Amazon! [video 1] [video 2] Web browsers mediate access to valuable private data in domains ranging from health care to banking. Despite this critical role, attackers routinely exploit browser vulnerabilities to exfiltrate private data and take over the underlying system. We present Quark, a browser whose kernel has been implemented and verified in the Coq proof assistant. We give a specification of our kernel, show that the implementation satisfies the specification, and finally show that the specification implies several security properties, including tab non-interference, cookie integrity and confidentiality, and address bar integrity. Our Web browser, Quark, exploits formal verification and enables us to verify security properties for a million lines of code while reasoning about only a few hundreds. To achieve this goal, Quark is structured similarly to Google Chrome. It consists of a small browser kernel which mediates access to system resources for all other browser components. These other components run in sandboxes which only allow the component to communicate with the kernel. In this way, Quark is able to make strong guarantees about a million lines of code (e.g., the renderer, JavaScript implementation, JPEG decoders, etc.) while only using a proof assistant to reason about a few hundred lines of code for the Quark kernel. Because the underlying system is protected from Quark's untrusted components (i.e., everything other than the kernel) we were free to adopt state-of-the-art implementations and thus Quark is able to run popular, complex Web sites like Facebook and GMail. Publications Establishing Browser Security Guarantees through Formal Shim Verification [Tech Report] USENIX Security 2012 Dongseok Jang, Zachary Tatlock, Sorin Lerner Downloads Source code(.tar.gz) (Version 0.1, 08/07/2012, 1.3MB) Contributors Dongseok Jang Zachary Tatlock Sorin Lerner

1 0

Re: [cryptography] Random number generation influenced, HW RNG
by Eugen Leitl 09 Sep '13

09 Sep '13

----- Forwarded message from "James A. Donald" <jamesd(a)echeque.com> ----- Date: Mon, 09 Sep 2013 07:25:11 +1000 From: "James A. Donald" <jamesd(a)echeque.com> To: Thor Lancelot Simon <tls(a)panix.com> Cc: cryptography(a)randombit.net Subject: Re: [cryptography] Random number generation influenced, HW RNG User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 Reply-To: jamesd(a)echeque.com On 2013-09-09 1:54 AM, Thor Lancelot Simon wrote: > On Sun, Sep 08, 2013 at 03:00:39PM +1000, James A. Donald wrote: >> On 2013-09-08 1:25 PM, Thor Lancelot Simon wrote: >>> On Sun, Sep 08, 2013 at 08:34:53AM +1000, James A. Donald wrote: >>>> Well, since you personally did this, would you care to explain the >>>> very strange design decision to whiten the numbers on chip, and not >>>> provide direct access to the raw unwhitened output. >>> You know as soon as anyone complained about this, they turned around >>> and provided access to the unwhitened output in the next major version >>> of the same product family, right? >> I am not aware of this. Could you provide further details? > http://software.intel.com/en-us/blogs/2012/11/17/the-difference-between-rdr… RDSEED provides the output of the /enhanced/ non-deterministic random number generator (ENRNG Which is "enhanced" by being whitened. And therefore makes it just as impossible to tell if the supposed randomness is backdoored as RDRAND does. What we need is the output of the entropy source. Supposedly we have a circuit that generates fairly random offwhite noise. (The entropy source) This is then AES encrypted (the enhanced non deterministic number generator), and the enhanced non deterministic random number generator then continuously seeds a pseudo random number generator, which provides the output of RDRAND To tell if there is a backdoor or not, we need the output of the entropy source, unenhanced. If the entropy source is real, it will show its analog characteristics leaking into the digital abstraction. The correlations and anti correlations between nearby bits will reflect the analog values of the circuit, thus no two chips will show quite the same correlations, and the correlations will vary with temperature and overclocking. These analog variations would be compelling evidence that the entropy source is the something very like the claimed circuit. Because RDSEED gives us the encrypted output of the entropy source, we cannot tell if the entropy source is a real entropy source, or a counter encrypted with the NSA's secret key. Since the whitening is deterministic, it is potentially reversible, but Intel does not appear to be releasing sufficient information to reverse it. _______________________________________________ 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] Techniques for malevolent crypto hardware (Re: Suite B after today's news)
by Eugen Leitl 09 Sep '13

09 Sep '13

----- Forwarded message from "Perry E. Metzger" <perry(a)piermont.com> ----- Date: Sun, 8 Sep 2013 14:34:26 -0400 From: "Perry E. Metzger" <perry(a)piermont.com> To: Ray Dillinger <bear(a)sonic.net> Cc: cryptography(a)metzdowd.com Subject: [Cryptography] Techniques for malevolent crypto hardware (Re: Suite B after today's news) X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.20; x86_64-apple-darwin12.4.0) On Sat, 07 Sep 2013 19:19:09 -0700 Ray Dillinger <bear(a)sonic.net> wrote: > Given some of the things in the Snowden files, I think it has > become the case that one ought not trust any mass-produced crypto > hardware. Yes and no. There are limits to what such hardware can do. If such hardware fails to implement a symmetric algorithm correctly, that failure will be entirely obvious since interoperation will fail immediately. If it uses bad random numbers, that failure will be subtle. The most obvious implementation defects are bad RNGs and bad protection against timing analysis. One might also add side channels to leak information. Obvious side channels for malevolent hardware are radio frequency interference (if you can deploy listening equipment in the same colo this might be quite a practical way to extract information) and timing channels (not only in the sense of failure to protect against timing analysis but also in the sense of using inter-event delays to encode information like keys). I think that in most applications power consumption side channels are probably not that interesting (smart cards etc. being an exception) but I'm prepared to be proven wrong. Any other thoughts on how one could sabotage hardware? An exhaustive list is interesting, if only because it gives us information on what to look for in hardware that may have been tweaked at NSA request. > Given good open-source software, an FPGA implementation would > provide greater assurance of security. I wonder, though, if one could add secret layers to FPGAs to leak interesting information in some manner. It seems unlikely, but I might simply not be creative enough in thinking about it. Perry -- Perry E. Metzger perry(a)piermont.com _______________________________________________ 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: [linux-elitists] Surveillance
by Eugen Leitl 09 Sep '13

09 Sep '13

----- Forwarded message from Teh Entar-Nick <nick(a)teh.entar.net> ----- Date: Sun, 8 Sep 2013 18:01:34 +0000 From: Teh Entar-Nick <nick(a)teh.entar.net> To: linux-elitists(a)zgp.org Subject: Re: [linux-elitists] Surveillance User-Agent: Mutt/1.5.21 (2010-09-15) Eugen Leitl: > I'm only aware of how Debian does things, and not in any detail. What > I would do is to separate the signing secrets across multiple key > people, and do a recorded/witnessed ceremony following a CA-like > model, signing on an air-gapped machine which is securely wiped > afterwards and transferring packages via sneakernet (making sure > there's nothing autoexecuted on plugin) to the machine where it is > being published. Yes, this is a huge pain. This is what Ubuntu does, and I was under the impression that they learned it from their Debian experiences with the same process. Also I'm not entirely sure what you meant by "a CA-like model" but if you're only talking about identity verification, you're missing a few things. Most important is keeping the real secrets in a master key that can authorise or revoke functional signing keys as needed. There are other steps that the security experts all worked out when they first realised that crypto wasn't magic and needed human processes to keep it relevant. It's all In The Literature. > So have a secure process in place, monitor the process by external > parties so that we can be sure that it is actually being done the way > it is said to be done. Trust, but verify. I'm not sure how you audit something that's meant to happen in a sealed bunker with a select few trusted shardholders. -- "Man, if everything were object-oriented then rsync could do this already. Of course, if everything were object-oriented I'd have a bushy moustache and be wearing flares, which would suck." -- Sean Neakums _______________________________________________ Do not Cc: anyone else on mail sent to this list. The list server is set for maximum one recipient. linux-elitists mailing list linux-elitists(a)zgp.org http://zgp.org/cgi-bin/mailman/listinfo/linux-elitists ----- 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] Points of compromise
by Eugen Leitl 09 Sep '13

09 Sep '13

----- Forwarded message from Phillip Hallam-Baker <hallam(a)gmail.com> ----- Date: Sun, 8 Sep 2013 13:53:49 -0400 From: Phillip Hallam-Baker <hallam(a)gmail.com> To: "cryptography(a)metzdowd.com" <cryptography(a)metzdowd.com> Subject: [Cryptography] Points of compromise I was asked to provide a list of potential points of compromise by a concerned party. I list the following so far as possible/likely: 1) Certificate Authorities Traditionally the major concern (perhaps to the point of distraction from other more serious ones). Main caveat, CA compromises leave permanent visible traces as recent experience shows and there are many eyes looking. Even if Google was compromised I can't believe Ben Laurie and Adam Langley are proposing CT in bad faith. 2) Covert channel in Cryptographic accelerator hardware. It is possible that cryptographic accelerators have covert channels leaking the private key through TLS (packet alignment, field ordering, timing, etc.) or in key generation (kleptography of the RSA modulus a la Motti Young). 3) Cryptanalytic attack on one or more symmetric algorithms. I can well believe that RC4 is bust and that there is enough RC4 activity going on to make cryptanalysis worth while. The idea that AES is compromised seems very less likely to me. 4) Protocol vulnerability introduced intentionally through IETF I find this rather unlikely to be a direct action since there are few places where the spec could be changed to advantage an attacker and only the editors would have the control necessary to introduce text and there are many eyes. 5) Protocol vulnerability that IETF might have fixed but was discouraged from fixing. Oh more times than I can count. And I would not discount the possibility that there would be strategies based exploiting on the natural suspicion surrounding security matters. It would have been easy for a faction to derail DNSSEC by feeding the WG chair's existing hostility to CAs telling him to stand firm. One concern here is that this will fuel the attempt to bring IETF under control of the ITU and Russia, China, etc. -- Website: http://hallambaker.com/ _______________________________________________ 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

[Cryptography] A Likely Story!
by Eugen Leitl 09 Sep '13

09 Sep '13

----- Forwarded message from Peter Fairbrother <zenadsl6186(a)zen.co.uk> ----- Date: Sun, 08 Sep 2013 16:20:40 +0100 From: Peter Fairbrother <zenadsl6186(a)zen.co.uk> To: Cryptography Mailing List <cryptography(a)metzdowd.com> Subject: [Cryptography] A Likely Story! User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130704 Icedove/17.0.7 This is just a wild story, It isn't true. If we cryptographers found it was true we would all be totally gobsmacked. The Beginning: Sometime in 2008 the NSA - the United States National Security Agency, who employ many times more mathematicians than anyone else does - discovered a new mathematical way to factorise big numbers better. It wasn't a huge advance, but it would be good enough for them to factorise several hundred 1024-bit-long numbers per month using some big computers they wanted to build. In the form of RSA public keys, these 1024-bit numbers were (and sometimes still are) used to generate the session keys which encrypt and protect internet traffic. A session key is the key which is used to encrypt the traffic between you and a website, using a normal cipher - it is a shared secret between you and the website. Setting up a shared secret session key, when the communications used to set it up may also be intercepted, is quite difficult and involves considerable tricky math. That's where RSA and factorising comes in. In 2008, when you saw a little padlock in your browser, the connection was almost always encrypted using a session key whose secrecy depends on the inability of anybody to factorise those 1024-bit RSA numbers. They change every few years, but usually each big website only uses one RSA key per country - so when the NSA factorised just one of those RSA keys it could easily find the session keys for all the internet sessions that website had made in that country for a couple of years. Now the NSA had been collecting internet traffic for years, and when the big computers were built they would be able to see your past and present online banking, your secret medical history, the furlined handcuffs you bought online .. The Dilemma: So, did the NSA then go "Hooray, full steam ahead?" Not quite. The NSA has two somewhat conflicting missions: to be able to spy on people's communications, and to keep government communications secure. On the one hand, if they continued to recommend that government people use 1024-bit RSA they could be accused of failing their mission to protect government communications. On the other hand, if they told ordinary people not to use 1024-bit RSA, they could be accused of failing their mission to spy on people. What to do? Some Background: Instead of using 1024-bit RSA to set up session keys, people could use a different way, called ECDHE. That stands for elliptic curve Diffie Hellman (ephemeral), the relevant bit here being "elliptic curve". You can use any one of trillions of different elliptic curves,which should be chosen partly at random and partly so they are the right size and so on; but you can also start with some randomly-chosen numbers then work out a curve from those numbers. and you can use those random numbers to break the session key setup. The other parts are: starting from the curve, you can't in practice find the numbers, it's beyond the capabilities of the computers we have. So those if you keep those random numbers you started with secret, only you can break the ECDHE mechanism. Nobody else can. And the last part - it is convenient for everybody to use the same elliptic curve, or perhaps one or two curves for different purposes. So if you know the secret numbers for the curve, you can break everybody's key setup and get the secret session keys for all the traffic which uses those curves. The Solution: Make government people use ECDHE instead of RSA, but with the NSA's special backdoored elliptic curves. Ordinary people will follow suit. This solves both problems - when people change to the new system the NSA can still break their internet sessions, and government communications are safe from other people (although the NSA can break US government communications easily - but hey, that's the price of doing business, and we're the NSA, right?). Someone else might find the factoring improvement, but it is thought infeasible that someone else would be able to find the secret backdoor. "Hooray, full steam ahead!" That's the story. The rest is just details - maybe the NSA somehow got NIST to put their special backdoored curves into NIST FIPS 186-3 recommendations in 2009, so people would use them rather than make up curves of their own - it is usual and convenient, but not strictly necessary, for ECDHE software to only be able too use a small selection of curves. Maybe they asked the US Congress for several billion in extra funding in the 2010 budget to run the RSA-breakers. Maybe they are building a new "data center" in Utah to use the session keys to decrypt the communications they have intercepted over the years. Maybe they put those special backdoored curves into Suite B, their official requirements for US Government secret and top secret communications. Or maybe they didn't. It's just a story, after all. The cryptography, while incomplete, is correct, and it may all seem plausible - but of course it isn't true. -- Peter Fairbrother _______________________________________________ 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] Why prefer symmetric crypto over public key crypto?
by Eugen Leitl 09 Sep '13

09 Sep '13

----- Forwarded message from Jerry Leichter <leichter(a)lrw.com> ----- Date: Sun, 8 Sep 2013 07:32:14 -0400 From: Jerry Leichter <leichter(a)lrw.com> To: Christian Huitema <huitema(a)huitema.net> Cc: 'John Kelsey' <crypto.jmk(a)gmail.com>, 'Crypto' <cryptography(a)metzdowd.com>, 'Jon Callas' <jon(a)callas.org>, "'Naif M. Otaibi'" <otaibinm(a)gmail.com>, 'Jaap-Henk Hoepman' <jhh(a)cs.ru.nl> Subject: Re: [Cryptography] Why prefer symmetric crypto over public key crypto? X-Mailer: Apple Mail (2.1283) On Sep 7, 2013, at 11:06 PM, Christian Huitema wrote: >> Pairwise shared secrets are just about the only thing that scales worse than public key distribution by way of PGP key fingerprints on business cards. > The equivalent of CAs in an all-symmetric world is KDCs.... If we want secure crypto that can be used by everyone, with minimal trust, public key is the only way to do it. > > I am certainly not going to advocate Internet-scale KDC. But what if the application does not need to scale more than a "network of friends?" Indeed, that was exactly what I had in mind when I suggested we might want to do without private key cryptography on another stream. Not every problem needs to be solved on Internet scale. In designing and building cryptographic systems simplicity of design, limitation to purpose, and humility are usually more important the universality. Most of the email conversations I have are with people I've corresponded with in the past, or somehow related to people I've corresponded with in the past. In the first case, I already have their keys - the only really meaningful notion of "the right key" is key continuity (combined with implied verification if we also have other channels of communication - if someone manages to slip me a bogus key for someone who I talk to every day, I'm going to figure that out very quickly.) In the second case - e.g., an email address from a From field in a message on this list - the best I can possibly hope for initially is that I can be certain I'm corresponding with whoever sent that message to the list. There's no way I can bind that to a particular person in the real world wit hout something more. Universal schemes, when (not if - there's no a single widely fielded system that hasn't been found to have serious bugs over its operation lifetime, and I don't expect to see one in *my* lifetime) they fail, lead to universal attacks. I need some kind of universal scheme for setting up secure connections to buy something from a vendor I never used before, but frankly the NSA doesn't need to break into anything to get that information - the vendor, my bank, my CC company, credit agencies are call collecting and selling it anyway. The other thing to keep in mind - and I've come back to this point repeatedly - is that the world we are now designing for is very different from the world of the mid- to late-1990's when the current schemes were designed. Disk is so large and so cheap that any constraint in the old designs that was based on a statement like "doing this would require the user to keep n^2 keys pairs, which is too much" just doesn't make any sense any more - certainly not for individuals, not even for small organizations: If n is determined by the number of correspondents you have, then squaring it still gives you a small number relative to current disk sizes. Beyond that, everyone today (or in the near future) can be assumed to carry with them computing power that rivals or exceeds the fastest machines available back in the day - and to have an always-on network connection whose speed rivals that of *backbone* links back then. Yes, there are real issues about how much you can trust that computer you carry around with you - but after the recent revelations, is the situation all that different for the servers you talk to, the routers in the network between you, the crypto accelerators many of the services use - hell, every piece of hardware and software. For most people, that will always be the situation: They will not be in a position to check their hardware, much less build their own stuff from the ground up. In this situation, about all you can do is try to present attackers with as many *different* targets as possible, so that they need to split their efforts. It's guerrilla warfare instead of a massed army. -- Jerry _______________________________________________ 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

Standard Open Crypto Libs
by Wilfred Guerin 09 Sep '13

09 Sep '13

Standard libraries for encoding, compression, and encryption have existed for decades. In addition to plain text or block data, stego and a diversity of other encoding methods exist. JS, ecmascript, javascript, flash, as3-5, swf, all have standard libraries available for most if not all functions. Unless everyone has been killed again, it is impossible to claim that noone can produce a tutorial to explain general encodings and operational demonstration in any diversity of easily accessible methods. Additional to bouncy-castle or gnu libs, there are varieties of functions and state machine with validation for every standard encoding method. HTML5 includes typed arrays in addition to html standard text boxes or canvas, there are public tools to package JS w/ html into phone apps in addition to http access. There is need to explain the reasons for the efficiency and effectiveness of certain functions, and the general concepts of multiple factors, nested encoding or wrapping, and use of multiple disparate routes for both raw data and encoding data. Any idiot can fabricate a wrapper function in html5 javascript using standard published libraries in a matter of minutes. Please someone provide an educational demonstration of the viability and efficiency of all combinations of encoding which includes all functions for public demonstration. Text boxes with javascript were common over a decade ago before Y2K, where are they now? All this situation really needs is the standard libraries to be packaged with a wrapper function and placed on an appropriate publicly accessible server with the demonstrations and access instructions. One should note diversities of data transport methods, including visual image, audio and video encoding via air, especially for private factor based encoding methods. Who can bother with 5 minutes to save the poor little world and teach them to save themselves? Wilfred(a)VT.edu

1 0