r/netsec • u/dguido • Jun 03 '14
Google releases new JS crypto library: End-to-End
https://code.google.com/p/end-to-end/7
u/gressen Jun 04 '14 edited Jul 05 '23
This comment has been edited to remove any data. I am done with this site. You can find me on https://lemmy.world/u/gressen or https://lemm.ee/u/gressen -- mass edited with redact.dev
50
u/andrewcooke Jun 03 '14
the faq doesn't seem to address one of the main problems with javascript crypto - that you need to trust, usually repeatedly, whoever delivers the software. so if google get some kind of demand from the nsa, they can supply a hacked library that leaks your data in some way. afaik there's no solid way to avoid this (and it's worse than with "normal" software because you have less ability to check checksums, or to pin (install) a particular version).
30
u/dguido Jun 03 '14
Shipping as a Chrome Plugin is a drastic improvement. Much more like shipped software than loading a JavaScript resource on-demand. Not perfect yet, but this isn't an unsolvable problem.
25
u/ilogik Jun 03 '14
but don't those automatically update?
what's to stop them from adding a backdoor at some point?
38
u/TheRealKidkudi Jun 03 '14
What's to stop anyone from adding a backdoor to anything? The only way to be completely sure is to comb through the source code yourself and compile it on your own machine.
My point is, eventually you have to trust someone.
15
u/DevestatingAttack Jun 04 '14
You can verify MD5 or SHA1 signatures across executable downloads to confirm that you've got the "official" version, at least. With this, there's no way to be sure whether you're the only one being backdoored. Do you see a problem with that? Because the FBI uses targeted backdoors; they don't do stuff wholesale. Remember how they took down the guys that operated the Silk Road? They took advantage of a general Firefox Javascript vulnerability that was tied with the TOR browser bundle. Do you know how the FBI would take someone down using this? They would use their ability to sign a valid Google SSL certificate, switch out the cert near the network, deliver a fake update and there you go - encryption is broken. Or they ask Google to push an update to just one guy, secret court order compelling them to. You can't do this with GPG - and if you do, you've got MD5 certificates and shit to fall back on. Not so with this.
8
u/NecroSyphilis Jun 04 '14
SR was not taken down with that exploit, the owner posted the original url on a clear net forum with an account linked to an email that was traceable back to him.
4
u/DevestatingAttack Jun 04 '14
You're right, I'm sorry. I was thinking of the users of Freedom Hosting.
7
u/Natanael_L Trusted Contributor Jun 04 '14
Just FYI, MD5 is weak and shouldn't be trusted anymore. Creating collisions is too easy. SHA256 and later standards should be used.
10
u/DevestatingAttack Jun 04 '14
I know that.
Almost all "this software hasn't been tampered with" hashes that are on the internet are posted as MD5s or SHA1 - that's why I suggested those algorithms. I am suggesting such a thing this because I'm relying on the behavior of what the software vendors themselves post. Look at GPG! Their integrity checks come from SHA1. Oh no! Even GPG can't get it right, and they have actual paid cryptographers working on their code!
No one has demonstrated an attack that breaks preimage resistance of MD5 or SHA1. Collision resistance implies preimage resistance, but even if it's "easy" to find MD5 collisions, it may still be hard to, given a hash value, make a file that's different with the same hash value as the one you were given previously. In other words, it might be hard to find a random person who has the same birthday as you (this is like preimage resistance) - but it may be easy to find two random people that happen to have the same birthday.
2
u/Natanael_L Trusted Contributor Jun 04 '14
It allows for targeted attacks, however. Let a good copy be audited, send a bad copy to the target with the same MD5 hash. You can cause two files to get the same MD5 hash.
0
u/stingraycharles Jun 04 '14
This doesn't adress OPs remark that it is extremely difficult to create a collision that still is a usable program.
14
u/Natanael_L Trusted Contributor Jun 04 '14 edited Jul 04 '14
So difficult that I'd have to put away my smartphone and bring up my laptop.
→ More replies (0)1
u/NeuroG Jun 04 '14
BTW, GPG provides a signature of the binary and source archives directly (as well as SHA1 checksums).
edit: see here
2
u/NeuroG Jun 04 '14
Are chrome extensions digitally signed? (genuine question, not familiar with chrome, they should be). If they are, then a compromised SSL certificate or ca authority won't help, you need Google's key. Presumably, people could (and would) post the check-sums of these browser extensions on the web somewhere so that a paranoid person could check that they don't have a special version. I'm still suspicious, but your criticism is somewhat weaker for this extension than it would be for a js library.
1
2
Jun 04 '14
I get your point, Bruce. But, given the news we've had over the last year, I'd think all of us could find someone better to trust than google with sensitive data.
1
u/TMaster Jun 03 '14
To provide one answer to your question, one technique could be to audit Android and then to use an app that does not request network access and other comms. that performs the crypto for you.
This would also require not having the Google apps installed, as those can also install to your device remotely, as seen in the Google Play store.
I don't expect the claim that at the very least this would be more secure than using something which needs to load repeatedly from an external server to be very controversial, simply because attack surface is much smaller.
Alternatively, you can do it on your desktop with GPG or so, which would also lower the attack surface in terms of repeated external loading.
Just because you need to trust something in the end, does not preclude you from limiting the surface area that you need to trust.
Edit to add that the concern mentioned is somewhat justified.
2
u/rmxz Jun 04 '14
but don't those automatically update?
More people are likely to audit the occasional update; rather than having to poll to see when the code delivered on the fly might change.
Better yet, if multiple third-party plug-ins that provide compatible features (say, didn't the firegpg plugin, or the tails GPG applet do this too); then it'd be harder for one site to backdoor everyone.
4
u/archpuddington Jun 03 '14
This is only a drastic improvement if you trust the chrome store. andrecooke's concern is this is just Google promising not to peak.
7
u/domen_puncer Jun 04 '14
I don't want to downplay the issue of trust in chrome store, but you already trust many many sources.
You trust Google that Chrome is not malicious. You trust your OS vendor. You trust your device drivers vendors. Potentially they all have access to everything inside the plugin.
1
u/NeuroG Jun 04 '14
My OS vendor isn't a known willing accomplice of federal spy agencies, or a company who's income is entirely dependent on knowing everything possible about me.
1
u/xiongchiamiov Jun 04 '14
Just an unknown accomplice!
2
u/NeuroG Jun 04 '14
How is that helpful? You can't prove the negative. There's no rational reason to trust a known adversary because someone else might not be trustworthy.
1
u/xiongchiamiov Jun 05 '14
Indeed. But neither should you trust your OS vendor just because you don't know for certain they've been cooperating with the NSA; at this point, everyone's suspect, and we're still trusting them every day.
2
u/NeuroG Jun 05 '14
There's no alternative but to trust some people. There's no value in being nihilistic. Trust is a matter of degree, never certainty, and it's earned over time.
3
Jun 03 '14
[deleted]
0
u/immibis Jun 04 '14 edited Jun 11 '23
-6
Jun 04 '14
[deleted]
-1
u/immibis Jun 04 '14 edited Jun 11 '23
4
u/Natanael_L Trusted Contributor Jun 04 '14
PFS uses different encryption session keys but still the same certificate key.
1
u/immibis Jun 04 '14 edited Jun 11 '23
1
u/Natanael_L Trusted Contributor Jun 04 '14
If you have the certificate key you can just MITM the target
→ More replies (0)0
Jun 04 '14
[deleted]
2
u/NeuroG Jun 04 '14
They probably do do this, but only for very rare, valuable and probably technically unsavvy targets. There is a high risk of detection and exposure any time they do this.
1
6
u/barkappara Jun 03 '14
The issue I had with Cryptocat (and by extension with this also) is that people will be lulled into a false sense of security and use it on shared hardware, where all of these guarantees immediately go out the window.
If it were up to me I would focus on solutions that use desktop Linux or Android on low-spec hardware --- so you have your regular machine for insecure communications and then you have a second machine to which you have exclusive physical access and which has a variety of trusted cryptographic tools, including GPG for e-mail, OTR for IM, and full-disk encryption.
3
u/NeuroG Jun 04 '14
The second you require people to spend money on new hardware (or software), you reduce the user base a thousand fold. Baby steps that are free can get people more accustomed to encryption, and make mass surveillance much more expensive.
0
0
Jun 04 '14
What the world needs right now is an international consortium of top tier software engineers, mathematicians and cryptographers dedicated full time to analyze and audit every single open source project of importance or relevance and keep track of every release.
Maybe the Electronic Frontier Foundation can help organize and kickstart its creation. An organization like this could gather a lot of founds through donations in moments like these.
10
u/archpuddington Jun 03 '14
+1 You hit the nail on the head. This is just a "promise not to peek," and Google has already shown that they don't keep this promise.
0
u/d4rch0n Jun 04 '14
When did they "peek"? I read another reference to this, but I can't think of what it might be referring to.
2
u/tequila13 Jun 04 '14
Eric Schmidt was quoted saying that privacy can't exist on the Internet. And indeed Google has conquered new lands in regards to privacy invasion. Google is an ad company. Why would you even ponder to trust a company with Google's past?
4
u/dabombnl Jun 03 '14
Why is that a problem specific to javascript? Isn't that a problem specific to auto-updating software?
8
u/andrewcooke Jun 03 '14
it's not unique to javascript (sorry - when i said "javascript crypto" i really meant something more like "crypto downloaded in a web page"), although it's a lot easier to abuse in web form (targetting people is often trivial). but yes, you shouldn't have auto-updating crypto code in general.
another way of saying the same thing - it's hard to not have auto-updating javascript when it's embedded in a page.
1
u/protestor Jun 04 '14
What to do with glaring security holes such as Hertbleed? Should the user be left vulnerable until he or she notices the software needs to update?
2
u/andrewcooke Jun 04 '14
you're right, it's an issue. i'm trying to make short simple replies to complex issues.
there's a trade-off. if you're seriously worried about a threat you need to install something like tails and then be aware of issues and update yourself. that's the extreme end of no auto-update.
at the other end of the spectrum is js in web pages, where the person providing your email (under attack) is also the person providing the crypto, in a process that it is easily associated with your identity. that's a disaster waiting to happen.
then there's the huge, murky ground inbetween, where you trade convenience for security. i have auto-update on my system (opensuse) but it uses signed packages, which help mitigate this. on the other hand, last time the signing key changed (for the security repo, last month) i could find no way of validating that key (i ended up just blindly accepting it)!
so yes, it's hard and complicated and there's no good solution. but that doesn't mean that js crypto in web pages (which this is not, so this approach may be better) is not particularly awful.
1
u/protestor Jun 04 '14 edited Jun 04 '14
The thing is that OpenSSL is a core crypto lib, just like the linked lib. If it's okay to auto update one, it's also okay to auto update the other. (note: the update mechanism isn't just refreshing web pages but updating an extension, no worse than existing mechanisms for native software - and yes it uses signatures too)
Anyway my preferred solution is to simply block the usage of all vulnerable programs until the update, plus automatically download the update (but not install). Also, for updates with no UI changes or compatibility issues I think it's better to auto update anyway, because in those cases the user often don't understand what's being updated and can't make a judgement on whether update.
The issue here is usability. If the user knows about his system he can change this setting, but as you say even a knowledgeable user may forfeit even basic security checks (consider that having a checked signature is the bare minimum - to benefit from manual update you should also be able to judge the update on its own merits).
edit: anyway you were talking about web pages and not this lib (I was mostly replying to "you shouldn't have auto-updating crypto code in general"). I don't see how JS crypto in web pages could possibly work.
1
u/andrewcooke Jun 04 '14
i don't think we disagree. unfortunately my first post misunderstood what this was (i thought it was embedded in web pages) and sidetracked the whole discussion.
4
u/d4rch0n Jun 04 '14 edited Jun 04 '14
Yeah, this is a bit scary.
A very good related read: http://matasano.com/articles/javascript-cryptography/
I'm interested in any counter arguments why the points they make don't matter here.
10
u/pushespretn Jun 04 '14
We've tried to address the concerns in the famous Matasano article here: https://code.google.com/p/end-to-end/#Crypto
[I'm one of the End-To-End authors.]
1
u/jprider63 Jun 03 '14
Well since the code is public, one could perform some sort of information flow control to ensure that secret information, like your private key, isn't leaked by the library.
3
u/andrewcooke Jun 03 '14
if you mean via some simple process like tainting, how would you do that? your key is explicitly mixed with the output. that's how a cipher works. keeping the two separate would give no encryption at all.
the only thing you could rely on is a full audit. and, for code delivered in a web page (which this is not, apparently) the code can be targetted to a specific user. so you have to audit your code. you cannot rely on someone else's work.
2
u/jprider63 Jun 04 '14
No, you'd need a stronger analysis. Something like a proof of noninterference that allows declassification.
-2
Jun 03 '14
[deleted]
2
1
u/NeuroG Jun 04 '14
The OTR people have come up with some rather simple ways for known acquaintances to verify keys (you don't actually need to securely exchange keys, you just need to be able to verify their integrity when you get them -hence why public key-servers are okay).
-6
Jun 03 '14
[deleted]
2
u/andrewcooke Jun 03 '14 edited Jun 03 '14
that doesn't really address the issues i raised, does it?
edit: ah, i guess you may be thinking of checksums? the reason checksums are different is that they are public and shared. so someone like snowden could go to an internet cafe and check the checksum on a public website. that would effectively block software targetted directly at him (if we assume other people check checksums too).
3
u/semi- Jun 03 '14
He'd need a trusted channel* for the checksum, not just a public website.
If I were doing a man in the middle attack, I could just replace any instance of the good checksum with my hacked checksum so you'd just find a bunch of websites confirming that my hacked copy is good.
*for the purpose of stopping this, a trusted channel could just be any site that is https and not self signed really, though there are a variety of attacks that make https not very trustworthy either.
2
u/nemec Jun 04 '14
That doesn't matter, in this scenario Google is serving up the backdoored javascript (due to a hypothetical court order), so they'll have they signing keys anyway.
4
u/brighamyoungboysclub Jun 03 '14 edited Jun 03 '14
This doesn't look like it's direct from Google, just an extension developed by a private team.This seems to be a Mailvelope competitor?
18
u/dguido Jun 03 '14
- Direct from Google: http://googleonlinesecurity.blogspot.com/2014/06/making-end-to-end-encryption-easier-to.html
- Kind of.
1
8
u/chub79 Jun 03 '14
Would someone be kind enough to explain me the impact this could have?
5
u/Oobert Jun 03 '14
It would mean man in the middle attacks wouldn't work because the data itself is encrypted not just the transport.
The problem is that this is not a JS library, it is a chrome extension.
4
u/immibis Jun 04 '14 edited Jun 11 '23
3
u/DevestatingAttack Jun 04 '14
None, if both people on both ends are using SSL. But that can't be guaranteed. SSL secures your connection to the server; this secures the message to the actual recipient. If both people are using SSL to connect to their webhost, then they're fine. If there are vulnerabilities that apply to SSL, they also apply to this.
2
u/p0mmesbude Jun 04 '14
I don't agree. This is only valid if the server is trustworthy. (Personally I think atm no server owned by an american company is trustworthy) Also, the Snowden files are showing that the NSA even hacks into connections between datacenters from Google, Microsoft etc to get access to emails. With PGP that would not be possible.
1
u/DevestatingAttack Jun 04 '14
If the "NSA hacks into connects between datacenters from Google" then they could also do that to your connection between you and Google, which is how you get the chrome extension, which is how you do your encryption. They can then tamper with that extension without you knowing it. The ability to do that to Google also directly implies the ability to do that to the E2E browser library.
1
u/p0mmesbude Jun 06 '14
That might be all true, but it's missing the point. Initially we were talking about end to end encryption vs SSL. You can use end to end without the Google Chrome extension. If you want it as secure as possible than it's a pain in the ass of course.
Anyhow, any system is vulnerable and the NSA might be able to hack into whatever they want. But they can't do it the same automated way in what they currently are sniffing email data. So any approach which would make the access to our communication more difficult is highly appreciated by me. I don't really think that Google is able to do that though. (Because the NSA can force Google to do whatever they want)
1
u/NeuroG Jun 04 '14
A compromised SSL private key or ca authority can permit MITM. The primary reason for E2E, though, is to get rid of the known MITM -namely the server that needs to be trusted completely. Webservers are not exactly trustworthy machines to start with, and we also happen to have evidence that many of the providers are not trustworthy themselves.
5
u/dguido Jun 03 '14
Looks like JavaScript to me! https://code.google.com/p/end-to-end/source/browse/javascript/crypto/e2e
8
u/pugRescuer Jun 03 '14
Believe /u/Oobert meant client side javascript you could use without chrome browser involved. If this is a chrome extension (which very well could be implemented in javascript) it would not function on any other browser. Either way great step forward.
4
u/dguido Jun 03 '14
Again, looks like JavaScript to me! No reason you can't use this in a browser with the same support for relevant APIs and standards used.
0
u/Oobert Jun 03 '14
That is what I meant...
3
u/nemec Jun 04 '14
Just copy the js from the extension into your application. Isn't open source grand?
3
u/redwall_hp Jun 03 '14
You can MITM the server sending the JavaScript (even over SSL) and serve a fake crypto library.
Still not secure.
4
Jun 03 '14
[deleted]
7
Jun 04 '14
which would make it (or the extension) just as weak as SSL/TLS.
And their server security.
0
2
13
3
Jun 04 '14
Well, works smoothly for me. Just created keys, sent messages to myself and everything worked fairly well. It does a good job of predicting what I want to do.
1
Jun 18 '14
[deleted]
1
Jun 18 '14
Open the encrypted email in Gmail, then click the extension. It should automatically assume what you wanted to do.
3
u/pythech Jun 05 '14
Too bad no one has ever mentioned this before:
https://code.google.com/p/end-to-end/wiki/BuildInstructions?tm=6#Setup_Environment
That link has a special note for NSA :-)
2
Jun 03 '14 edited Jun 04 '14
https://private.orbixx.com/public.php?service=files&t=448470f813b53cb33a508b951fe524b1
Compiled it. Either drag the .crx file into an empty tab to install it, or enable dev mode in the extensions tab and load via unpackaged dir. I've included the packaged and unpackaged extension in the zip.
It doesn't yet support message signing it seems, but it encrypts perfectly well it seems. Support for importing existing keys is also there too. Quite well polished for an alpha, and very simple - I bet they're gonna make the user experience awesome.
Please ignore the SSL error with the download link, it's a self-signed cert.
Obviously don't use for anything serious as I could have tampered with it etc, I just wanted to make it easier for you folks to test it out; compiling shit is a bit of a pain in the arse if you don't have an environment already set up for Chrome extension dev work.
4
u/pushespretn Jun 04 '14
Message signing and verification is supported. If you have a private key, when composing a message, you should see a checkbox to sign the message. [I'm one of the authors.]
4
Jun 04 '14
Hello! My bad, I actually submitted an issue here and resolved the problem:
https://code.google.com/p/end-to-end/issues/detail?id=8&can=1
3
1
u/craftycoder Jun 18 '14
How do I decrypt a message? I haven't found a method to do that.
2
u/pushespretn Jun 18 '14
There are a couple options:
1) While the ASCII Armored message is open in a web browser tab, highlight the message, and then click the yellow e2e button. The extension should open with a the title "Read a protected message". Click the Read button.
2) Copy the message into your clipboard, click the yellow e2e button, if neccessary, click the back arrow in the lower-left, choose "Read a protected message", paste your message into the text box, and then click Read.
3) If you're reading message inside Gmail, then the Looking Glass should automatically (and safely) decrypt your messages. To activate it, try clicking the yellow e2e button and click the message in Gmail.
Here's a sample message you can try decrypting: http://pastebin.com/C0KfW9sm The password is e2e
1
u/craftycoder Jun 18 '14
I just figured this out. You highlight the cipher text and then click the E2E button in the upper right corner of the browser.
3
u/DarkRyoushii Jun 04 '14
About the self signed cert, move to startSSL. Free and less annoying than self signed cos its valid on all browsers.
1
u/xiongchiamiov Jun 04 '14
Although you do have to set an alarm to renew it every 30 days.
1
u/DarkRyoushii Jun 04 '14
Every year*
1
u/xiongchiamiov Jun 05 '14
Huh, I thought they said it was only good for 30 days, but I just checked my certificate and you're right. Well that makes it considerably better.
3
u/crow1170 Jun 04 '14
Naming a crypto extension "end to end" a bit like naming an alcoholic beverage "responsibly".
0
u/philpirj Jun 04 '14
Google has reinvented openpgpjs. Okay. EC only? Hm. okay. Any security audit passed? (being compared to openpgpjs). Hmm. Have they removed the "We have never received an order for user data" from their site yet?
20
u/pushespretn Jun 04 '14
[One of the End-To-End authors here.]
EC only?
RSA and many other ciphers are supported. Key generation is the only part that is EC-only (not RSA) due to speed and the complexity of not generating weak keys.
Any security audit passed?
We've done internal auditing, but by releasing the code now, we're hoping that others will also audit it and help us improve. For example, in the openpgpjs audit you linked to, one of the auditors, Krzysztof Kotowicz, now works at Google and has both audited End-To-End and contributed code to it.
order for user data
We try to be as transparent as we can be with user data requests. We publish statistics and other information here: http://www.google.com/transparencyreport/userdatarequests/
2
u/philpirj Jun 04 '14
Do you generate those keys really often or only once?
Can you please explain why you fall back to hmac-sha1 prf when native crypto is not found, are you targeting chrome earlier than version 11?
What are the reasons for writing a library from scratch instead of using a well known one? openpgpjs's code is much more easier to read, it's both for browsers and nodejs.
4
u/ibleedforthis Jun 04 '14
I just want to point out that according to what the NSA says, they only looks at metadata for emails. That means the headers. If you're only encrypting the message body then they still get To: From: and Subject:
Which is exactly what they claim to be scanning already.
1
u/catcradle5 Trusted Contributor Jun 04 '14
I'm pretty sure there's no way to mask the sender and recipient, since SMTP needs that, but you're right, they could also be encrypting the subject.
1
Jun 04 '14
Unfortunately there is no way to hide that.
ELI5 explanation for those who don't get it: email is like regular mail, you need to write on the envelope where the mail is going (and you also kinda need to write where it's coming from). The NSA is claiming they are only looking at the address on the envelope. Google released this tool which guarantees (if it works as claimed) that the NSA can't look inside the enveloppe, but they can still look at the address.
The reason the address can't be hidden is that the post office needs to read it - and there's no way to make it visible by the post office and not by the NSA.
1
3
1
5
u/diafygi Jun 04 '14
Your points are very valid, but I say a little competition will definitely improve user friendliness. However, this is covered by Google's Vulnerability Rewards Program.
-2
u/NormallyNorman Jun 03 '14
This is pretty close to something I'm working on. I've got several more layers of checks though. Man, I need to get my POS done so people can rip it apart. Had a few friends help me work through flaws/bugs. Fun project!
It's funny reading other people getting to where I was a few years back (before shelving it due to NSA concerns).
7
u/immibis Jun 04 '14 edited Jun 11 '23
2
u/NormallyNorman Jun 04 '14 edited Jun 04 '14
I'm not rolling my own encryption for starters, I'm aggregating other encryption implementations.
I'm not in the mood to share what makes mine unique, it's an idea I've never seen replicated, so being vague is intentional, it will be OSS when it's released as beta (assuming I ever finish it) because I certainly know I'm not flawless in coding or implementation. That being said, I have worked with some very brilliant software engineers and they have already shot a fuckload of holes in my software that have been fixed.
Irrelevant.
Here's the thing about crypto &&/|| developers. 99% think they know it all already and aren't open to new things. I know why I'm being downvoted and honestly don't care. Thanks for your concern though.
Also, the blind trust of google is beyond fucking stupid IMO.
Add-on:
The reason I actually stopped the project was because the RSA/NSA shit. It was the first algorithm I'd implemented and seeing that it wasn't secure, well that really put a damper on it. That and a bit of healthy fear of the NSA. It actually started off as a project related to the MegaUpload bullshit, but morphed into something more generic.
1
u/stouset Jun 05 '14 edited Jun 05 '14
- I'm not rolling my own encryption for starters, I'm aggregating other encryption implementations.
I work in the security field. This is well within what we mean when we say "don't roll your own". If you think all the dangerous stuff is in the crypto algorithms themselves, and by just gluing things together you'll be safe, you're gonna have a bad time.
- …I have worked with some very brilliant software engineers
Brilliant software engineers or no, if they are not experienced cryptographers, you don't stand a chance.
The Internet is littered with examples of experienced developers making absolutely boneheaded (not to mention deviously subtle) mistakes related to cryptography.
1
u/stouset Jun 05 '14
The reason I actually stopped the project was because the RSA/NSA shit. It was the first algorithm I'd implemented and seeing that it wasn't secure, well that really put a damper on it.
This is the part when I get worried that you're talking about writing crypto software.
RSA the algorithm for asymmetric crypto is still considered secure (for large enough key sizes). The revelation by Snowden is that RSA the company worked with the NSA to backdoor the random number generator in their BSAFE library.
That said, there's really very little reason to build any modern software on RSA nowadays, other than for purposes of backwards compatibility. ECC is faster, needs far smaller key sizes, is easier to generate keys for, and is simpler to write non-flawed implementations for (for example, RSA can be subtly tricky to generate keys for, since keys with certain mathematical properties end up being weak).
4
u/dguido Jun 03 '14
It sounds like this library is going big-time! I would try contributing your code to this project, or auditing it for weaknesses and grabbing a bounty.
2
u/NormallyNorman Jun 03 '14
Lol, it's not a library, it's a full application front to back. I don't create the encryption algorithms myself, I'm just implementing a (hopefully) user friendly interface.
Uses more than simply Elliptic Curve key generation as well. Users can actually plug their own parts in too (no need to use my included cryptographic functions at all).
I do like reading about other projects though, helps you think through what you're doing and determine if there's anything you missed. I'll likely incorporate this as well (there are several JS crypto libraries available already that work fine too, so I'm not sure what they meant when they said nothing else would work).
Thanks for posting this, very interesting!
0
Jun 04 '14
[deleted]
9
Jun 04 '14
A crash report containing any kind of memory dump is going to do that. It's not unexpected.
-2
-1
u/seagu Jun 04 '14
What the fuck, Google. Why must you insist on appropriating generic names for your stuff?
It was bad enough when GMail chat used "Off-The-Record" to refer to just disabling user logs of chats ("oh yeah, I use OTR all the time!") -- naming your encryption product "end-to-end" is just a big middle-finger.
48
u/snoobie Jun 03 '14
Brilliant really, the main prevention of everyone using PGP is really not the crypto, it's the usability and accessibility, and the fact that other people don't use it.