Frequently Asked Questions

The lack of trust in encryption is a huge problem for security software. It’s been 25 years since famous security software developer, Phil Zimmerman, wrote his essay, “Beware of Snake Oil”. We will now extensively address the issues of trust and encryption in the following FAQ sections.

We took the approach because the world faces a dilemma: more than ever, the world needs high quality secure encryption systems, but there is a worldwide shortage of people able and qualified to design such systems.

Quoting famous cryptography advocate and early Tor contributor, Lucky Green:

The present need for security products far exceeds the number of individuals capable of designing secure systems. Consequently, industry has resorted to employing folks and purchasing "solutions" from vendors that shouldn't be let near a project involving securing a system.

In our own words, the task of designing a secure cryptographic system is extremely challenging, requiring the very highest levels of cryptographic expertise to achieve. There are, unfortunately, comparatively few people in the world skilled enough to design such a system.

It is standard practice for applications with encryption systems to be designed and implemented by software developers (as distinct from cryptographers), whose primary role is to develop applications. There is no shortage of applications whose website state “Military grade encryption” or “AES-256” as bullet-point features. Encryption is most often a feature of an application, not the core system itself. The vendors of these applications do not publish further details about their encryption systems, and the general public, unaware of the problems, tend to view encryption as a “tick the box” requirement.

And given that even large, reputable corporations like IBM and RSA have intentionally introduced weaknesses into their crypto systems over time, it is becoming increasingly difficult to know which systems to trust.

Our approach of commissioning leading cryptography experts from world renowned universities and research institutions to design, implement, peer-review and audit our system is in direct response to the dilemma faced by the world regarding encryption products.

We believe that we are the pioneers in taking this approach, and we’re proud to partner with a variety of industry experts to help improve the quality of encryption solutions worldwide.

We’ll further elaborate on our approach in the answers to further questions, below.

Designing and implementing a secure cryptosystem is a non-trivial task that requires expertise and care.

Although Scram uses only existing, well-studied and reliable cryptographic primitives (for non-technical people, think of these as building blocks), knowing which primitives to use and how to use them to achieve an end-result is of paramount importance. Everything in a cryptosystem must be “exactly right” to yield a secure system. A slight error in a design or implementation can result in weaknesses that can be exploited by attackers.

Many companies rely on software developers to design their cryptosystems. Unfortunately, most software developers are generally unaware of the specific intricacies of cryptography or how to avoid mistakes that lead to insecure systems. (This is not intended to be a criticism of software developers themselves – more a commentary about the situation.)

Expertise level

One analogy to understand the distinction between cryptographers and software developers is to imagine doctors – there are General Practitioners who have a broad knowledge of many aspects of health and family medicine, who then refer patients to highly trained specialists such as cardiologists, dermatologists, emergency medicine and brain surgeons.

Designing and implementing (as opposed to using) cryptosystems requires extreme specialization in the field. Software developers are not cryptographers. As famous cryptographer Bruce Schneier said in his 1999 essay, the short answer to "how can I become a cryptographer" is: "Get a PhD in cryptography."

To put things in perspective, cryptographers are rarer than brain surgeons. There are more software developers in the world than doctors (18.2 million versus ~10-15 million), yet there are fewer cryptographers than brain surgeons (3755 authors of cited papers, versus ~3500 neurosurgeons in the USA and ~6000 in Japan alone).

This gives a ratio of 1 cryptographer per 4846 software developers, and yet encryption is required in every secure system and is the backbone of security on the Internet.

Mistakes can be made easily

Without the proper expertise, mistakes can be made easily. In fact, even with the proper expertise, mistakes are still possible. Many systems, such as DVD copy protection, GSM, Bluetooth and WEP Wi-fi were designed to be secure but were completely compromised fairly easily.

It is extremely easy for any generalist software developer to use “AES-256” encryption in an application incorrectly and to produce a completely insecure system. Worse still, the developer may be completely unaware of the flaws in his/her system. One of the easiest examples to understand is when a developer uses the wrong mode of encryption – as shown in the diagram below.

Although this is a very basic mistake that hopefully will never be replicated in real-life applications, there are many other subtle mistakes that a developer can make that results in an insecure system.

No, we do not open source our source code or detailed designs of our cryptosystems.

However, we do release the following information:

1. The functional requirements against which our cryptosystems were designed.
2. A detailed security analysis of the security model, complete with a no-nonsense statement of what is and is not protected against by our cryptosystem.
3. Peer reviews, test results and audits of our cryptosystems.

There are a number of differences between our approach (closed source but with paid peer reviews and security analyses) and the open source approach. CVE handling is arguably a critical difference, but we shall start with general arguments first.

General arguments for and against open source

Common arguments in favour of open source encryption software are:

1. The source code is available so you can inspect it.
2. If anyone finds faults with the code, it can be fixed rapidly and by any developer (subject to license terms).
3. Developers can fork or branch source code and start their own development, or contribute to the development team.

The problem with these arguments are:

1. Even if source code is open source, few people possess the qualifications and the time to inspect the source code. By way of example, the now-defunct TrueCrypt project was launched in 2004, and yet was not audited for many years, with formal audit reports only released in February 2014 and March 2015 – some 10 years later.
2. Forking source code can be dangerous if the contributors are not suitably qualified to manage the code, and merging development from the main trunk into branches is onerous and ongoing.
3. Despite the stated virtues of open source implementations, vulnerabilities are still discovered on an ongoing basis.

Our adopted model is to have our designs and implementation designed and peer-reviewed by appropriate experts prior to release. We also, on an ongoing basis, commission audits to ensure the quality of our code and designs.

Thus, you could say that Scram takes a proactive approach to security, whereas the open source model tends to be more reactive.

CVE-handling process

The CVE handling process is one area of significant difference between closed and open source.

General CVE-fixing process in the open source project is follows:

1. Someone finds a vulnerability and reports it in a private email to the project maintainers. Public exposure is not good from the ethical point of view because hacker does not give maintainers time to create a patch fixing the vulnerability.
2. After some time, project maintainers provide a patch, publish CVE and send a email to mailing lists that urgent security update is required.
3. Software users get the update after some delay, because software have to re-build, tested, packaged, deployed, shipped on user's computers - every step takes some time - from minutes to days.

Closed source CVE handling allows software vendors to handle the situation better. They can provide a security fix before publishing CVE details. Firstly, all installations can be patched and protected against the threat, and only then will the details of the CVE be published.

• Block cipher: AES-256.
• Authenticated encryption with associated data (AEAD) scheme: AES-256 block cipher used in the Galois counter mode authenticated encryption function described in Morris J. Dworkin, "Recommendation for block cipher modes of operation: Galois/counter mode (gcm) and gmac", 2007. NIST special publication 800-38D.
• Deterministic authenticated encryption with associated data scheme: AES-256 block cipher used in the SIV authenticated encryption mode algorithm described in P. Rogaway and T. Shrimpton, "Deterministic authenticated encryption", 2007.
• Fixed input-length pseudorandom function: AES-256 block cipher with key length 256 bits and input length 128 bits generating a pseudorandom output length 128 bits.
• Variable input-length pseudorandom function: Uses the authentication tag generated by the authenticated encryption (AEAD) scheme with the initialization vector set to the input and empty plaintext and associated data.
• Filename character encoding: custom encoding known as Base32k, 15 bits per Unicode character. (Note: this is a non-cryptographic operation.)

This is a complex and ambiguous question that requires a detailed answer.

This is a term that we do not like to use. It is more of a marketing term than one rooted in computer science. In fact, we believe our competitors are simply using the term incorrectly and such use is an example of “snake oil” encryption.

So, according to the industry’s common definition of “zero knowledge” – the answer is yes, on the basis that neither Scram, nor your cloud storage provider, is able to read your data.

However, we can succinctly say that that no commercial solution in the marketplace is truly “zero knowledge”, but ScramBox is as “least knowledge” as is possible for a product of its kind, as explained below.

In our view, “Zero knowledge” literally must mean that your cloud storage provider knows absolutely nothing about your data. This must give you plausible deniability. However, in virtually every case, this is not the situation, because certain details are impossible to hide from commercial cloud storage companies:

• Who you are (from your billing information)
• The total size of your data stored
• How often you access your data, and how much it changes
• How many files and directories that you have

The following table summarises the ScramBox solution in comparison to other typical solutions.

Who knows what summary table

Legend: Green = no data leakage / Red = data leakage

If data leakage is important to hide, the clear choice is the ScramBox solution and hosting your own private cloud.

In every case with Scram’s software, you hold your own encryption key, which we call your ScramKey. This is the master key from which all sub-keys are created. You are free to keep that ScramKey as private or public as you wish – but of course, if you make it public, you might as well not encrypt.

Naturally, if you value your privacy and the confidentiality of your data, you will keep your ScramKey private.

Your ScramKey, which is a master key, is never used when sharing your data.

When you share data with another user, a derivative “subkey” is used. We can create an unlimited number of subkeys to share and give others access to your data. However, it is impossible to go back from a subkey to your master key.

Therefore, when you share your data, you’ll only share exactly what you intend, while keeping everything else private.

Based on:

1. The security model, which minimizes the amount of data leaked (refer to the Who knows what summary table)
2. Our published security analysis and audits

we are confident that our solution is at least equal to or better than other commercially available systems.

For backup purposes, we recommend that you back up your key to paper as a QR code – as a paper copy of your key is not vulnerable to online hacking or malware like cryptolocker. An alternative is to burn it to a DVD.

You can then store this back-up in a secure place, such as in a bank vault. We recommend that you use nondescript media to store your backup ScramKey.

Those of you who are ultra security conscious can use steganography to embed your ScramKey into photos, etc.

Quantum computers pose a real threat to cryptography.

It is known that many ciphers such as RSA and ECC are vulnerable to attack from quantum computers – “quantum-breakable”. What this means is that most forms of cryptography in use today will be easily broken by quantum computers.

It is estimated that by the year 2029, a quantum computer will have been built that will be capable of breaking RSA-2048.

The state-of-the-art of quantum computers is not known because research and development into quantum computing is likely to be a trade secret or classified information. However, it is believed by top cryptographers that we should transition away from using encryption techniques that are known to be vulnerable.

This is relevant to ScramBox because data stored in the cloud can live for decades or even posterity. The data that’s stored in the cloud may be encrypted and safe for now, but could be easily broken in a number of years.

ScramBox does not rely upon any encryption algorithms that are quantum-breakable. Instead, we follow the recommendations of the PQCRYPTO (Post-Quantum Cryptography for Long-Term Security) group. Their latest recommendations can be found in the Initial recommendations of long-term secure post-quantum systems report (Horizon 2020 ICT-645622).

No. It’s the mission of Scram to “Secure the world’s data in the cloud”, and it’s our aim to provide the very best security we can.

In our view, it wouldn’t be ethical of us to provide encryption systems that we already know are quantum-breakable. Even if the problem is estimated to be decades away, this is a matter of principle. (Speaking of which, you can read more about our guiding principles on our company website.)

We recommend that you use the ScramBox beta in a test environment.

We anticipate that the encryption will change slightly between the beta and release versions, as we will be performing final tests and optimizations during the beta period.

Therefore, when the release version is available, you will need to start over – deleting the encrypted versions of your files in the cloud and re-sync your data your computer to the cloud.

This is going to be a “one-off” situation between beta and release versions of ScramBox. Once ScramBox goes into release, the versions of your files in the cloud will be forwards compatible with future versions of ScramBox.

For everyone who registers as a beta tester, and supplies us with one of the following:

1. Useful feedback or bug reports that help us improve our product,
2. A testimonial that you’re happy for us to use on our website, or
3. A case study

We will give you a free commercial-use license to use ScramBox for 1 year past the beta testing period.

Data sovereignty is a complex legal issue and ScramBox allows you to comply with various laws relating to data storage.

Put simply, we see two reasons to be concerned about where you store your data:

1. In the case of health, financial, classified and government data, it’s likely to be the case that your home country has laws about where such data can be stored. Oftentimes laws may state that the data must be stored within the home country’s borders – ruling out many cloud services that store data in offshore data centres.
2. The governing laws regarding the privacy of the information are unclear. Until recently, it was common belief that if your data was stored in a foreign country, it was governed by the laws of that country. However, in a recent case involving Microsoft and the FBI, U.S. courts ruled in 2014 that Microsoft could be compelled to hand over data stored in an Irish data centre. But in 2016, that decision was overturned by an appeals court.

We have written an article about data sovereignty, and recommend you read it to understand the issues you may face.

ScramBox allows you to solve data sovereignty issues by giving you freedom of choice as to where you store your data. In particular, you can choose the best public cloud solution to comply with local regulations, or host your own private cloud storage server to retain full control of your data.

We believe that you should conduct your own due diligence when choosing where to host your data.

Our own research has revealed 5 best countries:

• Iceland
• Norway
• Switzerland
• The Netherlands
• Romania

We recommend you read our article about privacy-friendly countries and conduct your own research when making this decision.

ScramBox is not available for purchase during the Beta Testing period.

Once the software goes into release, you will be able to purchase ScramBox from our website.