Frequently Asked Questions

Here is a list of potential questions that may be asked and other miscellaneous information.

Questions

1. Is this software NSA-proof?
2. Are one-time pads too impractical to do properly?
3. Has the software been independently verified?
4. Why doesn't your site use HTTPS?
5. Who are you and what credentials do you have to develop such software?
6. Do you have a warrant canary?
7. Aren't you helping terrorists?
8. What about the government trying to ban encryption?
9. Explain Shannon's Perfect Secrecy?
10. Does this break US Export Regulations?
11. Is it possible to use the same server for multiple separate groups communicating?
12. What are some of the limitations of the software?
13. What are the capabilities of the NSA?
14. How can the author be re-verified if compromised?
15. What about Matasano Security's claims that JavaScript cryptography is insecure?

Is this software NSA-proof?

Encrypted messages sent with this software will be completely secure from NSA/GCHQ's "Upstream" collection from taps on the fibre-optic lines connecting countries. If a message is passively intercepted at any point from when it leaves the user's computer, through their ISP to the other users on the other side of the world, this will be impossible to crack even with unlimited time and computing power. Trying every possible key would simply reveal every possible plausible plaintext. NSA/GCHQ would have no idea what the real message was. Defeating this mass collection of data from all over the world is the main aim of the software.

The second aim for the program is the security of the connection to the server API to store encrypted messages until they can be retrieved by the other users. This connection should be secure against quantum computers, active MITM attacks, forgery, replay and timing attacks due to the 512-bit MAC and the pre-shared key that exists on the clients and server.

A better question would be: "Is this software TAO-proof?" Nothing currently may be truly safe from the Tailored Access Operations unit, which is NSA's cyber-warfare division. This is the same group that developed the Stuxnet worm, which jumped to an air-gapped system and ruined many of Iran's nuclear centrifuges. They have at least a thousand of the world's best hackers and engineers developing zero-day exploits against commonly used software every day. The NSA even infiltrates companies and open source projects with developers from their TAO unit to subtly add backdoors and weaknesses to the code. For any companies operating in the US they can also force them to include the backdoors by using a National Security Letter.

Perfectly defending against the TAO unit is not a reasonable expectation for this software to accomplish on its own. There are too many layers of systems and programs that can be compromised which could affect the security of this software. For example, for the server and the client computers, unless you have a truly open hardware and software stack then the whole system is likely vulnerable to the TAO unit. Unfortunately the computing industry has been running on closed hardware systems for a long time. If you are running Windows, MacOS or other closed source programs, it is highly likely that they are compromised or backdoored. It is best to use open source solutions that have been peer reviewed by trustworthy and competent people. The world does not even have confidence in the hardware stack. Many of the chips and firmware in your computer, tablet, phone, router or modem are closed design and closed source. Nobody in the public really has any idea what is running on them. As Brill says in Enemy of the State: "They've infected everything." It is known that this is exactly what they have been doing in the recent NSA leaks, by rerouting shipments of computer equipment and planting backdoors, to weakening security and encryption standards, and even forcing companies to plant backdoors in their systems through National Security Letters. It may be that nothing is truly secure until we have an openly designed and manufactured hardware platform. Even then you still have to be careful and fully secure all the software running on it. This is no different to regular cryptography programs running on a computer because they also need the whole environment to be secure.

If you follow the installation guides, extra security considerations and read through these frequently asked questions then you should be reasonably secure unless the TAO unit decides to target you specifically. These guides cover securing the server, the two endpoint devices and the browsers they are running.

Are one-time pads too impractical to do properly?

The main problem with using one-time pads is getting a quality randomness source, key distribution and key management. The first problem should be solved by the true random number generator included with the program which should be strong enough to not allow even a powerful attacker to predict outputs from it. Run it through an external test suite if you do not trust the output and ensure it has proper uniform distribution. It is also possible to import your own random data into the program if you wish to use your own TRNG. For the second problem of key distribution, all you need to do is get out from behind the computer and visit your friends, family, colleagues or associates and deliver the one-time pads to them in person. It is highly unlikely you are going to have your keys stolen or copied as you are going about your daily life. For the final problem of key management, this is a simple engineering problem. The program pre-allocates one-time pads to each user for sending so that no-one uses each other's one-time pads. The program detects which one-time pad was used to encrypt each message and decrypts it accordingly. After each message is encrypted, the one-time pad is removed from the sender's local database. After the message is received and decrypted it is also removed from the receiver's local database.

There are plenty of "security experts" that say that one-time pads are unnecessary, impractical or impossible. A few of the common counterarguments are covered here in the FAQ. Bear in mind you have to follow the installation guides and be aware of the security pitfalls listed on the site otherwise you are no better off than using standard cryptography. There is a lot of disinformation, fear, uncertainty and doubt on the internet about one-time pads and how they are apparently impractical. This proof of concept software proves them wrong. The design, source code and documentation speaks for itself. Do not forget the fact that the world's intelligence agencies, militaries and governments use one-time pads in their critical networks. Command and control systems for nuclear forces are not protected by commercial grade AES encryption. There is a concerted effort by spy agencies and JTRIG to discourage the use of unbreakable cryptography with plausible deniablity. It is clear that they would prefer everyone uses the same cryptosystems, which they have weakened through influencing and setting the cryptography standards. If everyone used one-time pads, their mass surveillance network would be rendered useless. Some reputable cryptographers think we need to make mass surveillance expensive again. This is not enough. We need to make it impossible so they give up entirely. Privacy is a fundamental human right, and they should never be able to decrypt our personal communications even if they spend billions of dollars trying to do so.

There may be some that complain about the programming languages or environment used. We have specific responses to complaints about browser based cryptography in the FAQ and the setup guides cover securing the browser, client machines and server. If they are complaining about any particular language e.g. PHP, realise that the design is portable to other platforms too with some extra development. JavaScript and PHP were chosen because they were the fastest to develop in and get a solution working. There may be some purists that claim cryptography should only be done in C or C++. Don't forget that these are not memory safe languages. Also do not forget the issue of whether there is a backdoor or trojan in the compiler. Did you compile your own compiler or use a trusted compiler? Did you compile the whole tool chain from scratch? Or are you just using a precompiled binary distribution that everyone else is using? These issues are just as important in an open source C++ cryptography program. Small weaknesses introduced over time into the open source stack can be very difficult to detect. Cryptography and security in any platform is not without its risks.

From what we have seen from the recent leaks and the NSA's long term goals of mass surveillance, backdooring encryption technology and weakening encryption standards, you can be absolutely sure they have not benevolently gifted the public with unbreakable cryptography that they themselves can't break. Be realistic, Suite B is great for keeping other companies from reading your emails and communications because they clearly lack the computing power to break the encryption. It was never designed to stop the government itself from decrypting your data. Especially when that government has secret knowledge of all the weaknesses of the algorithms before the approve them. None of the ciphers they recommend are information-theoretically secure. They want to retain the ability to break your encryption for "national security" reasons. Therefore you cannot use their recommended "secure" encryption standards if you want any assurance of privacy.

Remember that this program is designed to solve a specific solution, that is, for helping two or more people who need to communicate in absolute secrecy, who do not want their communication decrypted now or anytime in the future due to advances in computing, mathematics or cryptanalysis and are prepared to deal with the minor hassles of setting it up and exchanging encryption keys in person. It is not trying to solve all the world's cryptography problems at once, there are other algorithms and protocols for that. You can rest assured that everything possible has been done to make this software secure and there are no intentional weaknesses. If there are legitimate security concerns or fixes that can be made then let us know and they will be taken seriously and fixed as soon as possible.

The program mainly uses specifications and libraries that have provable security such as strong cryptographic hash algorithms and the one-time pad cipher. The program brings together these strong algorithms and principles into a single strong solution. The aim was also to avoid using a CSPRNG algorithm as "stretching" entropy is not conducive to quality randomness required for a one-time pad. The generator took many months to develop and properly test. There's no pseudorandom generation going on to "stretch" the entropy and produce large amounts of data based on a single seed. It is entirely possible NSA can deduce a pattern or the original seed from most CSPRNGs. This program's approach is much more secure for a one-time pad and ensures each bit of entropy collected is only used once. Of course you would be well advised to export the raw hexadecimal output from the random number generator into any number of testing programs to make sure it holds up to proper statistical analysis. There are also basic statistical self tests built into the program you can run. The next version will include an option to load user provided entropy directly into the program. Then the user can use their own trusted true random number generator and this program will just split the random data into the separate one-time pads and handle the chat/communications side of things.

Has the software been independently verified?

The full software has not been independently verified yet. However the code is well designed, written and documented enough to enable a security reviewer to perform a successful review without much effort. It is not anticipated that there are any serious or critical security issues in the current software. Anyone is welcome to do a review if they will provide an honest, constructive and unbiased review. Any feedback or suggestions will be much appreciated and changes made where necessary. Please contact us with your review beforehand if there are any issues so we have a chance to fix any problems before the review is made public. The author will also sponsor an independent professional review after the majority of development is complete.

Cryptography with one-time pads is very simple, but also very secure if all reasonable precautions are taken. It does not require a PhD in mathematics or cryptography and it is simple to implement, meaning there is much less chance of making mistakes with the implementation compared to complex cryptography involving Diffie-Hellman key exchanges, RSA, AES or elliptic curves. It also means it is easier to review and you do not have to understand complex mathematics and try figure out whether the code is implemented properly and avoids side channel attacks. Anyone can run the source code live in the browser with a tool like Firebug and step through the code line-by-line to verify exactly what it is doing. The source code is well commented and well unit tested. There is no ambiguous or obfuscated code anywhere. Most web or software developers should be able to follow what is going on.

It is important to note that a lot of the security will be obtained by properly configuring the server and securing the client endpoints. The new implementation guides cover off all the necessary security precautions. If you're running a closed source OS like Windows with no firewall and anti-virus then you can't really rely on this software to protect you. If other people have physical or network access to your PC or device then there won't be much stopping them from retrieving your one-time pads.

Why doesn't your site use HTTPS?

Hosting the site on a private VPS just for HTTPS capability was getting expensive so the project has been moved to GitHub pages for hosting. The consequence of this is that GitHub only supports HTTP domains linking to the site content. You can of course access GitHub via HTTPS and the project's home page via HTTPS as well using this link. The advantage of this is that low level network snoops like your ISP will not know which GitHub page you are actually visiting. Using HTTPS to visit a site is not foolproof however and won't stop state level attackers like the NSA if they want to attack your connection or serve you malware.

Visitors to this site are probably making themselves a target so be advised that at a minimum you should use the Tor browser or Tails and also enable NoScript to block all JavaScript from executing on this site. Even better if you visit the site from a cafe or library as well for proper anonymity. This site uses pure HTML, CSS and images only. No advertising. No analytics. Any JavaScript running on this site is likely to be malware or tracking code that has been injected into it without our permission. Make sure you do not allow it to run.

If you have doubts to the authenticity of the content of the webpage you can always check out the gh-pages branch on GitHub and verify the signature. All commits are signed by us with GnuPG (Key ID: 0xDC768471C467B6D0 and Fingerprint: CF3F 79EE 0114 59BA 0A59 9E9C DC76 8471 C467 B6D0. There are instructions here for verifying our signatures for file downloads and you can easily tailor this to verify the code signatures. For stronger verification of our public key you should also confirm the public key is a match on onename.com and keybase.io. Both of these identies are published on the Bitcoin blockchain. The GnuPG fingerprint may also be added to Namecoin in the immediate future.

Who are you and what credentials do you have to develop such software?

The author has senior commercial web application development experience, senior network and security architecture experience working for corporates and in recent years has moved into applied cryptographic application development and research. That is all the information that will be provided without compromising the author's true identity as it is preferred to remain anonymous so as not to invite interrogation, detainment or exile by authorities for developing this software. That has already happened with other developers of cryptographic software. Revealing your real identity and saying you work on cryptography software to avoid government surveillance is a one-way trip onto a terrorist watchlist and restricted air travel for the remainder of your life.

The author subscribes to the philosophy in the Cypherpunk's Manifesto. They have no affiliations with any government and no interest at all in supporting them with their mass surveillance and human rights violations. For other developers thinking of contributing to this software, please do not base yourself in the US. The reason for this is that if you develop a trusted reputation within the project team, then you are given a National Security Letter or gag order, we will not know and it could compromise the security of the project. There may be an exception for US citizens wanting to contribute if they have their own personal warrant canary and it is signed with their GnuPG key.

Do you have a warrant canary?

Like all critical cryptography software these days, we provide a warrant canary. This is a text file signed by the author's GnuPG key which will be updated after every release to say that we have not received a warrant, National Security Letter, subpoena, been captured, blackmailed or forced into weakening or inserting a backdoor into the software. It is a passive way to tell you if future versions of the software are compromised and may be our only way of telling you without violating a secret court order or being tortured. The private GnuPG key is also stored offline, in a secret location and encrypted so no-one else can use it. At the first sign of trouble the author will destroy the private GnuPG key to prevent future releases being compromised.

This means any software released on or prior to the date in the signed warrant canary text file is verified to be from us and we are not under duress of any kind. Should a release appear after the date specified in the warrant canary, then this would indicate we are under duress and you should not use any software released after the last valid warrant canary. Likewise if the warrant canary text file is unavailable, or does not match the GnuPG signature of the warrant canary text file then that also indicates that something is wrong. At that point your option is to fork the last valid version of the project which was made before the last valid signed warrant canary, or switch to using some other software. Also remember to validate the software of each release using the GnuPG key to ensure it is legitimate.

Current warrant canary
Current warrant canary file signature

Aren't you helping terrorists?

• It is not the intention of this software to help actual terrorists i.e. people who want to harm innocent people. Terrorists don't even need impenetrable encryption to commit terrorist attacks and some terrorist attacks don't even require communications at all, as evidenced by real life events.
• The term "potential terrorist" is now being applied by the US government for a very wide variety of people these days. If you are on that list you're a potential terrorist in the eyes of the US government. See also the secret government rulebook for putting you on a terrorist watchlist. There have been over 1.5 million people added in the past 5 years. The net is so wide it can practically include anyone based on suspicion alone.
• The intention of this software is for everyone on the planet to have private communications and avert Orwellian government control. No government can arbitrarily decide they can spy on everyone's communications. Our right to privacy is a fundamental human right and that is what this software provides. It appears some US citizens do not really care that their government had been spying on citizens of other nations and conducting economic espionage to steal trade secrets and company information to benefit US military and industry. They seem to be only concerned that their government had turned the system on them and has been breaching their Fourth Amendment rights. Well actually, the rest of the world do not deserve the NSA spying on them either. The US are running an Orwellian, oppressive, undemocratic and undiplomatic regime designed to destroy everyone's privacy. They have no right to steal ideas and trade secrets from other nations for the benefit of their corporations or government. They are in breach of our human rights, not just the Constitution of the United States.
• The hope is that activists and citizens of the world can unite by using this software and organise plans and protests to restore democracy back to their governments without fear of the government trying to arrest them. With this software, freedom of the press can be maintained, whistleblowers can leak information securely, anything you say to your family, friends, colleagues or associates remains completely confidential. If you use this software the government can not ever decrypt your communications when they are intercepted. This software is not just for the US, the rest of the world needs protection as well until the NSA and Five Eyes surveillance networks and systems have been completely dismantled.
• Knowledge of the one-time pad has been around for decades. It is nothing new. The "terrorists" could have been using this technology for a long time if they were smart. People just thought it too difficult to use and there are JTRIG agents on most cryptography/security forums discouraging its use due to "insurmountable practical issues" and telling people to use government sanctioned cryptography instead. They have particular pre-defined talking points and scripts about one-time pads which they use. It is easy to notice a pattern in that they try divert the reader to just use a NIST standard instead. That way the government stays in control and can secretly decrypt the world's communications by backdooring and weakening the very standards they claim are safe. In reality with a program like this the only minor inconvenience is the initial setup and exchanging one-time pads with your chat partner in person. After that you can chat for years in the future.
• Citizens in every country deserve to have strong cryptography and avoid oppressive global surveillance networks. The price of freedom and privacy for the good people, is that sometimes the bad people will also use that to evade justice. This is considered a worthy sacrifice, in that the benefit to the majority of good people far exceeds the danger that "terrorists" may pose.
• Note that use of the software, design or source code means you agree to not use it for evil. That generally means if you intend on harming innocent people then you are not permitted to use this software, its design, or source code to help with that. If you cannot agree to this rule then your software licence permissions are null and void.

What about the government trying to ban encryption?

The United Nations Special Rapporteur has already called upon states to promote and protect strong encryption and anonymity online. That should be the end of the matter right there. If however you find yourself living under an increasingly paranoid and controlling government you should start using steganography as well to disguise the fact that you are even using encryption. Also some cryptographic techniques such as Chaffing and Winnowing can be applied to hide a real message within a plaintext channel and not be considered 'encryption'. The entire debate of banning encryption is a ridiculous and pointless exercise designed to enact fear, legalised mass surveillance and control of entire populations.

Explain Shannon's Perfect Secrecy?

Claude Shannon's "Communication Theory of Secrecy Systems" is a proof that all theoretically unbreakable ciphers must have the same requirements as the one-time pad. It states that if the rules are applied correctly, the one-time pad can be proven unbreakable. Even infinite computational power and infinite time cannot break one-time pad encryption, simply because it is mathematically impossible. Without the correct key, trying every key simply reveals all possible plaintexts but there's no way of knowing if that plaintext was actually what was sent. However, if only one of these rules is disregarded, the cipher is no longer unbreakable. Jericho Comms was designed in accordance with these rules. The rules are as follows:

• The key is at least as long as the message or data that must be encrypted.
• The key is truly random (not generated by a simple computer function or such).
• Key and plaintext are calculated modulo 10 (digits), modulo 26 (letters) or modulo 2 (binary).
• Each key is used only once, and both sender and receiver must destroy their key after use.
• There should only be two copies of the key: one for the sender and one for the receiver (some exceptions exist for multiple receivers).

In reality even if you used a well seeded CSPRNG the randomness will be extremely difficult to predict however that would make the system a stream cipher, not a one-time pad. With this software we have ensured that the program only collects and uses true random data. The software uses a solid TRNG and randomness extraction process described on the information page. The output from the extractor is then used solely for the one-time pad. The generator does not use this output to seed a CSPRNG and produce more random data that was originally generated. So this software is not a CSPRNG. Users can even use entropy from their own sources e.g. hardware random generators at their own risk.

Does this break US Export Regulations?

US Export Regulations on cryptogaphy and related products are not applicable to this software as this software has been developed outside of the US. There are no laws against importing or exporting cryptography here. Nor are US patents applicable. In fact the very idea of export or import laws against cryptography undermines our basic human rights to liberty and privacy. If this software were created in the US, this website and the program's source code can be considered free speech so it would still be protected under the First Amendment to the US Constitution. You can also read about how PGP was distributed in book form to bypass US Export Regulations.

If you have fear about downloading this software in your country then take a few measures to protect yourself. Download it using Freenet, Tor, a VPN or proxy hosted in another country. Download it from an internet cafe or library. That way it can't be tracked back to you. Strong cryptography should never be illegal. It is necessary for a free society, freedom of speech and freedom from totalitarian governments. Privacy is not achieved by politely asking those in power to not violate your privacy. Privacy is achieved by using unbreakable cryptography and enforcing your right to privacy. The Universal Declaration of Human Rights states clearly that:

"No one shall be subjected to arbitrary interference with his privacy, family, home or correspondence, nor to attacks upon his honour and reputation. Everyone has the right to the protection of the law against such interference or attacks."

Cryptography laws forcing you to use weak encryption and thus allow the government to interfere with your privacy or correspondence are against this fundamental human right.

Is it possible to use the same server for multiple separate groups communicating?

Yes it is possible. The server installation script allows the automated creation of other groups on the server. Each group uses the same server IP address but a different port on the server. The port differentiation allows the web server to know which group is making a request.

1. Run the server script on the server e.g. sudo ./setup.sh and select the option to add an additional group. This step will output the server IP, server port and API key. Note these down.
2. Copy the client files to a different directory on your laptop/PC. This means that there will be separate local storage in the browser for each group you want to communicate with. For example ~/Documents/jericho/client-bob-alice-carol/ and ~/Documents/jericho/client-dave-mike-bob-jacob/. The browser allocates separate local storage per unique file path.
3. Open the index.html file in each of the client directories in different browser tabs.
4. When connecting, use the new server URL path and port e.g. http://your.ip:8008 and the new server API key.

What are some of the limitations of the software?

• Local storage size is limited in the browsers. Chromium has a limit of 2.5MB and Firefox has a limit of 5MB. This can be increased in Firefox by typing about:config in the address bar and searching for the dom.storage.default_quota option. Its value is in kilobytes. To be on the safe side it may be best to generate a maximum of 2.5MB worth of one-time pads (approximately 9000 one-time pads) so it will work in most browsers and operate at a fast speed. If you need ability to communicate with a person for more messages than that or over longer periods of time, create separate sets of 9000 one-time pads and both users can load the next set when you run out. In future versions the program may use the IndexedDB database so that larger, more reliable storage is available.
• Chatting is limited to desktops, laptops and tablet devices at the moment. The one-time pads should definitely be generated on a desktop/laptop as the TRNG is resource intensive. The software is not optimized for mobile phones just yet. Also there may need to be some creative methods developed to get the one-time pads onto the device as the mobile browsers only recognise loading images. Android devices generally accept MicroSD cards or you can attach the USB cable which is very useful for this, however you have to load up the one-time pads in a plain text editor on the device, then copy/paste them into the load screen which is difficult.
• Browser limitations limit use to Firefox and Chromium currently. This is due to a few of the other browsers not supporting a few of the HTML5 features. It may work in Safari but it has not been tested on that yet. Do not use Google Chrome as it is closed source and not secure.
• The one-time pads for each user should only be loaded on one device at a time. If you load the same one-time pads for a user onto a notebook PC and also a desktop PC then you risk re-using the same one-time pads and allowing for cryptanalysis. A secure way to do this would be to add another user to the chat group for the extra device e.g. Bob, Alice (home) and Alice (work). This way each device will get their own set of one-time pads for sending new messages and there is no risk of pad re-use. One device may end up getting another copy of the conversation which occurred on the other device, but that is just a minor annoyance.

What are the capabilities of the NSA?

It's a well known fact that the NSA has massive datacenters and supercomputers all over the US. Any of these are theoretically capable of breaking encryption regardless of their official use. The Titan supercomputer for example which uses CPUs and GPUs has a peak performance of 27 petaFLOPS. There is plans to replace that with a machine capable of 200 petaFLOPS in 2016. At their Oak Ridge facility which is known to be used by the NSA and DARPA they have plans to build a machine capable of one exaFLOP by 2018. These are just the supercomputers that are public knowledge.

Recent leaks in 2012 by a senior intelligence official involved with the NSA program has said they made "an enormous breakthrough" years ago in their ability to break complex encryption systems used by governments, companies and people around the world. This can clearly only mean a few things, either they've made mathematical advancements or they have quantum supercomputers. At any rate everyone should be highly concerned.

If quantum computers are a reality they could use Shor's algorithm for integer factorization and Grover's algorithm for brute force cracking of encryption. Coupled with weak or backdoored psuedo-random number generators in the operating system this makes cracking of most encryption currently in use entirely feasible for the NSA. Currently a 512-qubit quantum computer has been installed at the University of Southern California (USC). Recently a 1024-qubit one has been released from the same company. There are some skeptics which claim (without even working with the machine) that it is not a general purpose quantum computer and it can't be used for cracking encryption. Then again it would be rather convenient for the US government if they can throw misinformation and doubt into the public arena and get everyone to believe that a working quantum computer doesn't exist, then they go and build a cluster of them underground. Meanwhile everyone thinks they're still safe for a few more years using RSA and 128 bit AES. It is confirmed that this quantum computer performs equivalent to the 5th ranked supercomputer in the world at about 5 petaFLOPS for solving problems such as the Travelling Salesman Problem. This single machine is equivalent to an entire datacenter full of computers which is impressive. It has been speculated that NSA's new Utah datacenter will be comprised of quantum computers. The Snowden leaks definitely show that the NSA is seeking to build a quantum computer that can crack encryption. It is only a matter of time until they succeed and they are not going to make a public announcement when they do.

Because everything on the internet is being collected and stored indefinitely, anything you say today using standard encryption that can't be cracked today can likely be cracked in the near future when quantum computers become available. They will simply save your secret messages away and have another try at cracking it in a few years time when they're able to. Anything said previously could be used against you in the near future. It is a pointless game to keep ever increasing your encryption key sizes to try and stay ahead of the government and future advances in computing. At some point you want encryption that can never be cracked, ever, even with unlimited computing power.

In the NSA leaks we have seen the methods used by NSA to bypass or get around encryption by installing backdoors, weakening encryption standards and hacking computers to retrieve keys. There is also a secret laboratory at Oak Ridge where all the NSA's top code breakers are. We do not know anything about NSA's cryptanalytic capabality from the NSA leaks. It is classed as Sensitive Compartmented Information (SCI), which only very few people have access to within the NSA. Unfortunately Edward Snowden did not have this clearance level so we do not know what the NSA's true code breaking abilities are and which ciphers they can break. Edward Snowden famously stated: "Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on." However he cannot actually qualify that statement to say which encryption is actually strong and which is not. He never had access to the SCI information about this at the NSA in the first place. We would need another leaker with this top secret SCI information to come forward.

Have you ever wondered why the UK or US militaries do not use public encryption standards like TLS or block ciphers for their secure military communications? One would have to ask why the classified NSA Suite A Cryptography algorithms exist. What types of encryption do they use or what key sizes are they using for that? Why have they used and are currently using systems like BATCO or DRYAD which are basically paper based one-time pads. If only one-time pads are good enough for the military or the Washington-Moscow hotline, why are we using anything less and allowing Orwellian governments to read our communications? In other words, why use B grade cryptography when you could be using something that is actually mathematically proven to be unbreakable?

With so many unknowns about what cryptography is or is not broken and so much disinformation out there, maybe it is wiser to just use the safest option, the only cipher proven to be unbreakable, the one-time pad.

How can the author be re-verified if compromised?

In the case of a newly released quantum computer capable of breaking the RSA 4096 signing key, or if the signing key becomes compromised, or if the site is taken down and needs to be moved, then the author can be reverified using one of the hashes below.

Below are the hash digests of multiple echo -n key | sha384sum commands, where key is a long independent secret key for each command. The secret key(s) can be revealed at a later time when some event occurs and signing things with the PGP key is no longer possible or trusted. For an external adversary to break SHA-384 they will need a difficult pre-image attack. SHA-384 on its own is a truncated output so it is not vulnerable to length extension attacks. Publishing the key to the hash should be sufficient proof of authenticity for the author to announce a new signing key (ideally one with post-quantum protection) or a site / code repository transfer to somewhere safer.

Emergency hashes:

1. 21aa4423186373bb060dc1ff85284edfc65181654537773fc0617a7447fe6bb4a1dd7a16ef2a3cb450bcca84d4d97b16
2. 3137a69e91548f850f6de77ba9257eb740b16ca46174cb065f09120e7298eefd4088277d267c4f492a5d5279130f0747
3. 8e14164e00dd66ad8ebcfc3852865c225c3186b3982bd3dba746db4c0dcdd20068b3bb0a6c0b96855ff6199c964f26ab
4. db3ccea4a00c39a6d1b9854e7cf6c7eaa4d62bb62a55dd4553d6eec25ed2096f87a8d7cb5bac426dd352a474f9b85107
5. 4566d810a59b30253b9b99cced4248df856e65befadc6226b4c09c388f613708931aea919ea54af0dc243dfd4f582907

What about Matasano Security's claims that JavaScript cryptography is insecure?

Matasano Security wrote an article back in 2011 regarding cryptography in JavaScript which is well known in security circles. Most claims are now largely out of date and there are sensible measures that can be taken to ensure cryptography can be done securely in JavaScript. A few other people have made comments on the article and have a number of counter points which you can read here and here. Outlined below are some of the statements made by Matasano Security in the article, counter arguments for each and how this software is still secure regardless.

"Secure delivery of Javascript to browsers is a chicken-egg problem."

This is a problem when executable JavaScript code is delivered to a browser from the web server. It needs to be secured by HTTPS/TLS otherwise you can't trust that the JavaScript code being sent hasn't been modified. If it was modified by an attacker then the JavaScript cryptography code could be rendered insecure. Even if using TLS and web server delivered JavaScript, the security of the application would only be as secure as the cryptography used in the TLS protocol.

There are two ways around this:

1. Deliver the code as a signed extension for the browser.
2. Download the code separately in a compressed archive, validate the hashes and signatures of the archive file, then run the code in its entirety from the local machine inside the web browser.

This program currently uses the second method. All code is self-contained and run locally on the user's machine from the file:/// path in the browser. No executable code is retrieved from the server as the program is running at all. Only JSON requests are made to/from the server to send/receive one-time pad encrypted messages. Any response sent from the server is escaped for XSS attacks. Therefore the program's code cannot be modified by an attacker.

"... having established a secure channel with SSL, you no longer need Javascript cryptography; you have "real" cryptography."

There are some major problems with this statement.

1. The first problem is that SSL/TLS encryption is between the client and the server. Once it's on the server it's in cleartext. For true end-to-end security you need another layer of encryption which encrypts the message from one browser all the way through to the other person's browser and is never decrypted in transit. SSL/TLS does not provide that. You may think your email with GMail or Hotmail is secure because you're connecting to them with HTTPS. In reality only your browser session with them is secure. The actual email data and your information is sitting on their servers in cleartext. Even if they were encrypting it serverside you have to trust them that they're not keeping the cleartext version before they've encrypted it serverside. Not to mention when you send an email it's sent over the internet through any number of servers along the way in cleartext as well. Anyone can read it, and the NSA can most certainly intercept it. With the PRISM program the NSA can also access GMail or Hotmail's servers and pull all your emails from them in plaintext anyway.
2. The second problem is the complete reliance on SSL/TLS for securing the messages. TLS/HTTPS is not without its security issues and there are plenty of attacks on it. Can you safely assume the NSA cannot crack standard SSL/TLS with their supercomputers or quantum computers? There is also new news that the government has cracked most encryption used on the internet. Because of the FISA laws and Patriot Act, the US government can literally force Certificate Authorities to give them their root signing certificate and put a gag order on them. This would allow the government to perform MITM attacks on all communications transiting their networks and retrieve the symmetric keys sent in the Diffie-Hellman key exchange which are used for the actual encryption.
3. Finally there is the definition of "real" cryptography. Is "real" cryptography good enough to stop an Orwellian government with huge amounts of computing power? Is the cryptography good enough to secure your messages for 5, 10, 50 or 100 years in the future so your secret stays safe even after death? Or will future computing advances allow them to decrypt your past messages? Could you be thrown in prison for something you said 5 years ago when they finally manage to decrypt your message? Could your future political campaign be ruined by the messages decrypted in the future? If you can't take these chances then you can't take chances using B Grade cryptography recommended by the government to secure your messages. The only "real" cryptography is the one-time pad because it's mathematically proven to be unbreakable. Every ciphertext can reveal every plausible plaintext of the same length. If you want "real" privacy you better be prepared to deal with the minor inconveniences that come with it. Jericho Comms solves most of the major inconveniences in using one-time pad cryptography.

"The problem with running crypto code in Javascript is that practically any function that the crypto depends on could be overridden silently by any piece of content used to build the hosting page."

Again none of this is possible because we are not accepting server delivered executable code. Any data that is received from the server is JSON encoded and escaped for XSS attacks. All code is run from the user's machine locally in the browser. The code cannot be modified by an attacker as it is running on the machine without some kind of outside attack e.g. a trojan installed on the machine.

"... 99.99999 percent of the crypto needed by web applications would be entirely served by a simple, well-specified cryptosystem: PGP."

The problem with public key cryptography like RSA and PGP is that it is based on a theory that factorizing integers is a hard problem to solve. It's not information-theoretically secure. There's no proof that PGP is truly secure in reality. Mathematical advances can make finding factorizations much faster and possible to break cryptography with standard supercomputers.

Moore's law means the number of transistors on integrated circuits doubles approximately every 2 years. This has been suprisingly accurate. It may not translate directly to an increase in single-threaded raw computing power but can mean significant increases in parallel processing power due to more cores. If the NSA built a new supercomputer every 2 to 4 years they would get the increase in power from each chip, multiplied by the thousands of chips that go into each supercomputer. For example, the Titan supercomputer has 18,688 CPUs paired with an equal number of GPUs, giving a total of 299,008 processor cores. This gives a peak of 27 petaFLOPS which is a phenomenal amount of processing power. Are you increasing your PGP key size every year to keep up? Unfortunately as the key sizes increase the time to create the key and decrypt data with it starts to scale up quickly.

Let's assume the government actually has working quantum computers now. If this can be used for integer factorization then all bets are off. Shor's algorithm demonstrates that the integer factorization problem can be efficiently solved on a quantum computer. Sure you can increase the key size up to really long lengths e.g. 16,384 bits so they need more and more qubits to crack the encryption, but this is a never ending arms race. It's also extremely slow to generate and use keys of that length.

Remember the government will never tell you they already have quantum supercomputers. All research and knowledge about it is classified. Does anyone outside of the highest levels of security clearance know what DARPA are working on at any given time? It's been said that the commercial world or academic community is 15+ years or more behind the US government, especially in the realms of cryptography. See the DES story. If a quantum computer factored the number 15 in 2001 and we're now in 2013, what advances have been made in the past 12 years towards quantum computers and integer factorization? 12 years is a long time with the pace of advancements in the field of information technology. What do the government have if they are another 10 years more advanced than the commercial world? The truth is PGP, RSA and eliptic curve based cryptography are no longer a viable option.

"What systems programming functionality does Javascript lack? ... a secure random number generator."

That was correct, back in 2011, when this article was written. Even two years is a long time in the field of information technology. Now with the Web Crypto API available in HTML5 and implemented in Firefox and Chromium the browser can access the getRandomValues() method. This draws on the Operating System's entropy source e.g. /dev/urandom. Of course Jericho Comms does not blindly assume this entropy source is completely trustworthy so it's not used as a sole source of entropy for generating the one-time pads. Only user generated entropy is included in the key material. Users can manually include entropy from the Web Crypto API into the entropy pool and key material if they have a trusted hardware random number generator connected and feeding into /dev/urandom. Otherwise this API is used only to help "stir" or shuffle the entropy pool, randomizing which order hashing algorithms are applied, or picking a random MAC algorithm to use in authenticating each message being sent.

"But how easy is it to attack an insecure random generator, really?"

Most psuedo-random and cryptographically secure psuedo-random number generators "stretch" the available entropy by gathering an initial amount of entropy to "seed" an algorithm. This algorithm then generates as much random data as needed far beyond the initial amount of entropy. For a one-time pad we absolutely can't rely on the output from any of these generators being included in the key material. It must be assumed that the NSA can and will find a pattern or bias with their supercomputers and be able to discover the seed used for the generator or predict future output, thus allowing them to decrypt future messages. With the one-time pad each bit of key material must be unpredictable. This software aims to do just that.

"What else is the Javascript runtime lacking for crypto implementors?"

Matasano Security mentions secure erase and timing attacks. Timing attacks have been mitigated in the code. Secure erase is potentially a problem as it is hard to conclusively erase data from memory or hard drives after it is no longer needed. If the pads are being stored anywhere they must be inside an encrypted storage container. Some of the lingering data in memory can be removed with a reboot and there may be special programs to overwrite the free RAM after you have finished a chat session. The major threat however is not these issues. You've already got major issues if you need secure erase to protect your data. That means you should have encrypted your data before putting it on any storage medium.

The real threat is having your communications collected, decrypted, read and stored indefinitely as it is sent over the internet. Not having secure erase are essentially problems if the government have physical access to your data. In reality this is not an issue unless the government does a raid on your house or has planted malware on them. If you're performing activities that lead them to require a raid on your house then you've got bigger problems to worry about and all bets are off anyway. It's also recommended to have the one-time pad data stored on a USB drive and using Firefox portable within a Truecrypt container. This means your important data is mobile and ready to go at a moments notice. If the one-time pads are about to be compromised you can also initiate the auto nuke which will wipe the local pad database, server database and notify the other user's client to remove their pads as well.

"Wait, can't I generate a key and use it to secure things in HTML5 local storage?"

Matasano Security says you can't because that scheme is, at best, only as secure as the server that fed you the code you used to secure the key. That's true if you're depending on server delivered code from the web server. Not true if you're using a locally run, self-contained JavaScript program inside the browser. Why? Because each website or URL can only access local storage for that particular website. If a user went to google.com and the site stored something in local storage and then the user visited amazon.com, Amazon cannot access the data stored in local storage by google.com. The browser's security rules prevent it. Similarly if a user accessed the program by the file:/// URL which is a reference to the file path on the local disk and the program stored the one-time pads in the local storage, that local storage is unique to that address and only the locally run website from that file path can access it. It's also recommended to run the chat program from its own dedicated browser or browser profile to avoid malicious websites or extensions from stealing private data inside your browser. The installation guides cover doing just that.

"You can't outsource random number generation in a cryptosystem; doing so outsources the security of the system."

Matasano Security mentions using random numbers delivered over the internet from random.org or a web server that is sending you random numbers from its CSPRNG. They mention this is insecure even if the numbers are delivered by TLS and they're absolutely right. The site random.org could be storing that random data at their end and then you're trusting them with your one-time pad keys. Also the NSA can intercept that traffic and possibly decrypt it. Terrible idea. This advice has been recommended by particular people on cryptography forums with reputation in the 10k range. It's likely they work for the NSA giving terrible advice like that. Also on Ivy Bridge CPUs, Intel added a new hardware random number and possibly colluded with the NSA while developing it. This paper (PDF) discusses how it could be compromised. There is some confusion around whether Linux now actually uses that entropy source without mixing it into the pool with dev/random. That's why Jericho Comms includes a true random number generator. Therefore the user is incentivised to create quality entropy if their security is on the line.

"Check back in 10 years when the majority of people aren't running browsers from 2008."

You can't wait around for slow corporations and users still in last decade to upgrade their web browser. HTML5 is ready to go now. If you want real privacy you better be prepared to install the latest version of Firefox or Chromium so you can use this program. Also it's a good idea to keep it up-to-date regularly for security fixes and new web technologies. That's the prerequisite for using this software. Current versions of Opera and Internet Explorer don't have support for the getRandomValues() Web Crypto API. Also IE 10 doesn't have support for HTML5 Web Workers.

You don't want to use a closed source browser for cryptography anyway. There's no telling what the code is doing behind the scenes. A modification and background update could allow them to send your chat messages off to the NSA in clear text. Along that line, don't use Windows too if you can help it. It could also potentially contain a backdoor for the US government. We've already seen companies like Microsoft being coerced into assisting the NSA with PRISM. It's not difficult for the government to force any US company to include a backdoor for law enforcement. In fact, it's possible they already have. So use an open source operating system as well.

"The "view-source" transparency of Javascript is illusory."

It's true that cryptography software implementations should be independently reviewed by cryptography and security professionals. This is no different for any other programs written in any other software language. You can't single JavaScript out for that. The view-source functionality benefit is not however illusory. You can debug and step through the code line-by-line as it is running in real-time with the brower's native debugger or an extension like Firebug. Try doing that with a compiled application. You'll be trying to read assembly code which is a much more difficult task. Also you have to have assurance that a backdoored compiler hasn't injected some nefarious code, or the cryptography software creator hasn't maliciously included a backdoor in the compiled version. It would be prudent to always compile the code yourself from the source code. However that takes time and is an extra step. With JavaScript, it's running the raw source code live in the browser. There's no need to compile anything to get it running. Any half-decent web developer can read, understand and debug the program as it's running to make sure it's doing what it's supposed to be doing. We have made sure the program is extremely well commented and documented so there is no doubt about what it is doing. With compiled programs there's even less people that would know how to debug the program from a binary compiled file. Contrary to Matasano Security's claims, the ability to view the source code as it is executing is actually a security benefit.

"... attackers have many hundreds of opportunities to break web app crypto, where they might only have one or two opportunities to break a native application."

Matasano Security talks about how "nobody installs hundreds of applications every day and that nobody re-installs each application every time they run it. But that's what people are doing, without even realizing it, with web apps." However the way Jericho Comms works is that a source code archive file is downloaded once, the user verifies it, and then runs the web application locally inside the browser. It's not being downloaded at all from the web server when it is opened.

"SJCL is also practically the only example of a trustworthy crypto library written in Javascript..."

Back when Matasano Security wrote their article in 2011, the Stanford JavaScript Crypto Library may have been one of the few libraries available. As we know, two years is a long time in information technology. There are now a number of excellent JavaScript libraries around such as CryptoJS that can perform various cryptographic functions. There's also the HTML5 Web Crypto API which is still in development. This aims to natively implement cryptographic functions inside the browser. For now Jericho Comms uses some of the more secure digest (hash) functionality available in the CryptoJS library. The hash outputs have been verified to be correct from the test suites and comparing the outputs to the specification test vectors.

Summary

In summary, none of the claims of Matasano security about JavaScript are true for this program. Their claims are only valid for web browsers delivering executable JavaScript code from the web server and in that scenario you're totally reliant on the security of the TLS connection. Reasonable measures have been taken to ensure the integrity of this software against possible attacks and concerns listed by Matasano Security. With this program you have end-to-end encrypted and authenticated messages using the perfect secrecy of the one-time pad.