Frequently Asked Questions
In-depth Q&A with the team behind ScramFS. Everything you wanted to know, plus more!
- Encryption software has been around since the 1970s. What’s so special about ScramFS?ScramFS provides a file system interface to a collection of encrypted data, and to answer the question, we consider the differences between encrypting a string, a file and an encrypted file system.
Securing a string
To secure a string, it is encrypted and also authenticated. Authentication allows us to detect changes to stored data. It involves calculating a 128-bit number from the string and a key. The number is stored with the encrypted string. When we decrypt the string, we try to calculate the number again, and if it differs from the stored number we know that the encrypted string has been changed.
Securing file contents
However it is impractical to secure a string of arbitrary length using this approach. To read part of the string we must decrypt and authenticate the entire string, and similarly to change part of it we must re-encrypt and recalculate the tag on the entire string. So it is sensible to partition the string into blocks that are encrypted separately. And by encrypting each block with a different key, we ensure that a single key is not over-used. Also, we can pad the last block to hide the exact length of the string. ScramFS uses this approach to secure file contents.
Securing an entire file
There are further considerations to secure a file. In addition to encrypting and authenticating the file contents, ScramFS hides the file name, which is encrypted and authenticated in a similar manner to encrypting a string. Also, ScramFS hides the file's modification time and plaintext size, which is encrypted and stored in the file body. To detect if the encrypted file has been renamed, or any contents of the file changed, ScramFS calculates an authentication tag on the file contents and name, and stores the tag in the file.
Securing a complete file systemLastly, to secure a file system we need to encrypt and authenticate all of the file contents and all of the file and directory names. One principle need is to create a single master key from which all keys used in the file system can be derived or decrypted. This is a core aspect of ScramFS, which has been carefully designed to manage keys in a scalable manner so that the data security is not reduced as more data is added.
Securing against untrusted storage systems
Additionally, ScramFS does not reveal information to an attacker monitoring the file system calls, and will detect when the call return values have been falsified. ScramFS detects any new data that has been written to the file system by an attacker, or any modification to existing data.
Exposing a file system interfaceFinally, in addition to securing the data, ScramFS provides a file system interface to the data. The ScramFS API provides the standard file system calls, such as open(), read(), write(), makedir(), listdir(), and remove(). An application using the ScramFS API sees the decrypted paths and file contents and ScramFS performs encryption and decryption needed to secure the stored data. Similarly to an unencrypted file system, ScramFS manages operations from concurrent threads and handles error conditions. In particular, ScramFS must manage the file system limitations imposed by the operating system, such as maximum lengths of names and paths, as well as handling a range of character formats and encodings.
- What cryptographic primitives does your system use?All cryptographic primitives used have been publicly verified with extensive cryptanalysis. Further, all are recognised as post-quantum safe, meaning that they provide long term security and resistance to attack by quantum computers.
- 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.
- Why are encrypted file names in Chinese?
When you first look at the output of ScramFS encryption, you will notice that file names and directory names become unintelligible:
This is obviously by design and is an important security feature of ScramFS.
However, many people wonder why they see so many Chinese characters, and whether we just translated English file names into Chinese.
Our ciphertext file and directory names are indistinguishable from random.
The text that you see in the screenshot above is an encoding of the raw binary ciphertext data. The text is, in fact, not all Chinese. It is a mixture of many different character sets, including Chinese, Japanese, Korean (which account for about 83% of characters that you'll see). But we also use characters in Thai, Tibetan, Ethiopic, Braille, Canadian Aboriginal, Tamil, Javanese, and other languages (including some extinct languages).
In short - the encrypted path names are pure gibberish to anyone who can read any of those character sets.
- Does Scram Software have access to my encryption keys?No, Scram Software does not have access to your encryption keys. The encryption keys are solely your property. Scram Software cannot decrypt your data, and cannot assist if you lose your encryption keys.
- Is your encryption “zero knowledge”?
This is an ambiguous question that requires a detailed answer.
“Zero knowledge” is an often misused term. It is not a term used in cryptography, and it appears to be a marketing buzzword rather than one originating from computer science. In fact, we believe other encryption vendors are using the term incorrectly and such use in marketing is an example of “snake oil” encryption.
According to the industry’s common definition of “zero knowledge” (which is technically incorrect) – 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 ScramFS 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 you or 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 cloud storage companies:
- Who you are (from your billing information)
- How often you access your data, and how much it changes
- Various attributes about your data - such as its total size, and how many files and directories that you have
The following table summarises the ScramFS solution in comparison to other typical solutions.
The who knows what summary table
Solution ScramFS Tresorit DropBox Enterprise Entity Scram Software Pty Ltd (Australia) Your cloud storage provider Tresorit AG (Switzerland) DropBox Inc. (USA) KNOWLEDGE The fact that you use ScramFS or other encryption software Known Impossible to prove but difficult to deny Known Known Your private encryption key Hidden Hidden Hidden Know How much data you have stored Hidden Known Known Known Access patterns for your data Hidden Known Known Known Content of your data Hidden Hidden Hidden Known
Legend: Green = no data leakage / Red = data leakage
If data leakage is important to hide, the clear choice is the ScramFS solution and hosting your own private cloud.
- Who holds the key in your systems?
In every case with Scram’s software, you hold your own encryption key. This is the master key from which all sub-keys are created. Each ScramFS instance has its own master encryption key.
Of course, you are free to keep that master key 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 encryption keys private.
- What about when I share my data?
When you wish to share your data, we recommend creating a new ScramFS instance solely for that purpose and copy only the subset of data intended to be shared. We see common mistakes where authorised people (such as contractors) can get access to data that was never intended for their eyes. For example, misconfigurations due to human error can occur easily, resulting in people being granted access to files in a part of a file system not intended for them.
Therefore, creating a separate (and possibly temporary) shared storage space will ensure that data sharing is a deliberate, intentional act, where accidents will not result in unintentional disclosures.
You should also remember that once you share data with someone, it may be impossible to guarantee that they "forget" it. The worst case scenario is that the other party has taken copies of the data, and retains those copies even when the sharing ceases and the ScramFS instance has been deleted.
- How do I back up my ScramFS encryption keys?
We provide the ability to back up your encryption keys via the ScramFS CLI and ScramExplorer GUI.
Each backup of the encryption key is protected by a password. You can back up your encryption keys an unlimited number of times, each with potentially a different password.
- When can I purchase ScramFS?
The General Availability date for ScramFS is 14th February 2018.
- How do I satisfy data sovereignty regulations?
Although data sovereignty is a complex legal issue, ScramFS allows you to comply with various laws relating to data storage through one very simple philosophy:
You have 100% control over your data and where you put it.
ScramFS 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.
More generally, we offer the following observations about data sovereignty and why it's important to consider. We see two reasons to be concerned about where you store your data:
- In the case of health, financial, classified and government data, it’s likely 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.
- 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.
- What are some privacy-friendly countries you can recommend for cloud storage?
If data sovereignty is not a concern for you, and you have freedom to decide where you store your data, then you may wish to consider which country you store your data.
While you should conduct your own due diligence when choosing where to host your data, in general our view is that European countries offer the best privacy laws. In particular, a major problem data retention - if you store data in the cloud, and subsequently discontinue using that service, how can you be sure that the cloud provider has fully deleted your data? From 25th May 2018, the EU's General Data Protection Regulation (GDPR) legislation protects citizens. Article 17, known as "Right to erasure ('right to be forgotten')", provides rights to the data owners to request that their data be erased.
Our research has revealed 5 best countries to store your data:
- The Netherlands
Of course, where you choose to store your data is entirely within your control. ScramFS was designed to support any generic cloud storage provider through open protocols such as SFTP and WebDAV. This also gives you the flexibility to switch providers in the future, only migrating across encrypted data from one provider to another, thereby eliminating the possibility of data leaks during the migration process.
- Can I use your beta version on “production” environments?
We recommend that you use the ScramFS beta in a test environment.
The main reason for this is:
- We anticipate that the encryption will change slightly between the beta and release versions.
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 ScramFS goes into release, the versions of your files in the cloud will be forwards compatible with future versions of ScramFS.
- What rewards are you giving to your beta testers?
For everyone who registers as a beta tester, and supplies us with one of the following:
- Useful feedback or bug reports that help us improve our product,
- A testimonial that you’re happy for us to use on our website, or
- A case study
We will give you a free commercial-use license to use ScramBox for 1 year past the beta testing period.
- Who are you, Scram Software?
Scram Software Pty Ltd is a private company founded in 2014 and headquartered in Melbourne, Australia. It is our mission to secure the world’s data in the cloud.
Our team of highly talented cryptographers, security engineers and software developers are passionate about security and making the world a safer place.
Please read more about us on the About Us webpage.
- How can I trust your encryption?
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.
- Why did you engage leading cryptographers and university professors to design and peer-review your cryptosystems?
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.
- What are the challenges with designing and implementing cryptosystems?
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.)
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, our research shows that 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.
- What is an example of insecure encryption?
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.
- Is your encryption open source?
No, we do not open source our source code or detailed designs of our cryptosystems.
However, we do release the following information:
- The functional requirements against which our cryptosystems were designed.
- 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.
- Peer reviews, test results and audits of our cryptosystems.
- How does your approach compare to open source encryption?
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:
- The source code is available so you can inspect it.
- If anyone finds faults with the code, it can be fixed rapidly and by any developer (subject to license terms).
- Developers can fork or branch source code and start their own development, or contribute to the development team.
The problem with these arguments are:
- 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.
- 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.
- 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.
The CVE handling process is one area of significant difference between closed and open source.
General CVE-fixing process in the opensource project is follows:
- 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.
- After some time, project maintainers provide a patch, publish CVE and send a email to mailing lists that urgent security update is required.
- 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 clients can be patched and protected protected against the threat, and only then will the details of the CVE be published.
- How does this compare with other common systems?
- The security model, which minimizes the amount of metadata leaked, and
- our published security analysis and audits,
we are confident that our solution is the most rigorously designed general purpose file encryption system available in the marketplace.
- I’ve heard that quantum computers will break many cryptosystems. What does this mean for the long term security of my encrypted data?
Personal data stored at rest should be encrypted with a long-term view. Even if you do not intend to store the data for the long term, your encrypted data may be copied during a security breach and an attacker may attempt to decrypt it in the future. Or your cloud provider may retain an archive or backup, even after you have deleted the data. For personal data, we should consider the security of data for the duration of the person's life, which may be 100 years.
We cannot know what will happen centuries from now, but there are developments we can expect in the coming decades. Quantum computing and the continued exponential decrease in the cost of computation are well understood development that we must anticipate. Other developments can be imagined, such as the discovery of a mathematical weakness in existing encryption algorithms, but we cannot mitigate against such threats and can only hope for their continued security.
For the moment, the main concern in the cryptographic community is the threat that Quantum computers pose to many kinds of cryptography used commonly today.
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 security in use today (such as TLS) 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 all customers of cryptography 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.
- How do you know that ScramFS is long-term secure?
There are general measures and precautions that crypto designers can take now to achieve quantum resistance and minimise the risk of our data privacy being compromised in the future:
1. Use long keys. As the cost of computation decreases over time, the feasibility of an attack that exhaustively tries all possible keys is improved. Longer keys have a larger set of possible keys that the attacker must test. ScramFS uses 256-bit keys, which are considered best practice with symmetric encryption for long term storage.
2. Use symmetric encryption. Quantum computers are known have a small (a factor of square root) advantage when attacking AES symmetric encryption. However they have a much greater advantage against RSA and ECC public key encryption, which is now considered to be insecure against attack by quantum computers.
3. Minimise the quantity of data encrypted with each key. This reduces the attack surface against each key, and also reduces the quantity of data revealed to an attacker should they be successful.
ScramFS has been carefully designed to rigorously adhere to these principles.
ScramFS follows 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).
Further, ScramFS maintains security with scale: the encryption keys are managed so that the data encrypted with each key is limited while the data stored in ScramFS increases. Even when ScramFS contains multiple terrabytes, adding additional data does not compromise the security of the previously encrypted data.
- Aren’t you being paranoid here? Quantum resistance sounds like science fiction.
It's actually our job to be paranoid about your data.
The American standards organisation, NIST, recently solicited proposals for post-quantum resistant public-key ciphers. The European Union have the PQCrypto project, which has been running for several years. The mathematics behind quantum computing and its threat to cryptography has been well known for decades.
Therefore, we need to stay ahead of the curve.
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.
This includes providing long-term confidentiality of data protected by our systems.
When purchasing a cryptosystem, we recommend that you consider the long term protection offered.