crpt.info -- How Combinatorial Security Works
In 2013, we built https://crpt.info/ and used it for secure, ephemeral messaging. I called it the "anti-email" because email is un-securable and should be used for anything you want to save for later, retain, and remain searchable (that's how I use email). But for those messages and transmissions of files that you don't want tracked, and won't leave any trace, you should use crpt.info. The slideshare below gives a layperson's description of what crpt.info was and is and how it can be used for secure, ephemeral messaging and file transmission.
I am here to disclose in laypersons' terms how we rolled our own security, called "Combinatorial Security," so that we are not reliant on secure certificates, domain names, or standard encryption algorithms which contain NSA backdoors. The patent was filed in 2019 for those who want to inspect it more closely themselves -- US20210194859A1 System and Method for Combinatorial Security
From my study of cybersecurity, we have seen cases where SSL certificates have been compromised to allow MitM (man-in-the-middle) attacks. So we do not want to be dependent on SSL certificates or https to "secure the pipes" (i.e. packet transmission), although we will use it when available. Further, we have seen attacks on DNS servers (e.g. DYN in 2016 causing outages with Twitter, Spotify, etc.) that render major websites unusable. So we needed to avoid that choke point. Finally, if we assume attackers have unlimited computing power, an arms race against them using stronger encryption is meaningless; additionally one should operate with the assumption that any commercially available and widely used encryption algorithms have NSA backdoors built in. Therefore we chose not to use any standard encryption algorithms.
Combinatorial Security
When each message is sent, it is encrypted with the public key of the intended recipient and then broken into a random number of shards. Each shard is of a different size and each shard is encrypted with one of a library of reversible mathematical transforms that we created in-house. None of these are standard encryption algorithms used by others commercially. Each shard is then hidden in an random number of "haystacks." Each haystack is a server with a unique IP address. Haystack servers are geographically distributed and multi-cloud for redundancy. Shards are stored in temporary subdirectories with alphanumeric addresses of random length. Redundant copies of shards are stored on redundant haystacks for further redundancy. Once a message is picked up by the intended recipient, all shards everywhere evaporate and all temporary subdirectories on the filesystems of the haystacks are deleted. Security is further increased by using larger numbers of haystack servers.
Assuming attackers have unlimited computing power, they would still have to brute-force traverse all subdirectories to find the shards. But they wouldn't know which shard belonged to which message. Assuming they could find all the shards, they would have to brute-force decrypt each shard. But they would not know when to instruct their decryption process to stop because no shard ever resolves to recognizable patterns (e.g. English words); each shard in decrypted state is still just an alphanumeric string. Assuming they could decrypt all shards correctly, the attacker would still have to re-assemble the shards in the right order and decrypt the resulting string with the private key of the intended recipient. But they would have to have the correct private key, since the public key, private key pair is single use and changed every message. So cracking one message does not help the attacker with any subsequent message; they'd have to start from scratch each time there is a new message.
If attackers find that each message is impossible to retrieve and break in time, or not worth the amount of computing power and bandwidth necessary to be successful, they might attack the infrastructure to render it inaccessible or unusable by provisioned users. To foil this type of attack, we use the same security mechanisms built into #FouAnalytics, a site and media analytics platform that tracks fraud and bots, and has cybersecurity measures in place to prevent tampering and false data.
Secure, Ephemeral Messaging That is NON-Discoverable
Combinatorial security secures each message better than end-to-end encryption, which only secures the pipes/transmission. Messages and files are not stored anywhere, encrypted or not. Shards are individually mathematically transformed and stored in geographically disperse, multi-cloud environments. Neither the platform nor attackers know where the shards are distributed, the subdirectories where they reside, the mathematical transform needed to reverse the encryption, or which shards go with which messages. There are no encryption keys that can be given to any party to break the system or to use as backdoors. The messages are unrecoverable during transit and after it is picked up by the intended recipient when all the shards and temporary subdirectories evaporate. Each public-private key pair is changed per message.
I will continue to review the "combinatorial security" method with cybersecurity and encryption experts. If you see any loophole that I have not addressed above, please let me know.
领英推荐
Primer on Workplace Email Discoverability
I am drawing from and citing examples from this blog post from a lawfirm - https://www.setlifflaw.com/news/2019/01/workplace-emails-employer-considerations-for-communications-discoverable-in-the-event-of-litigation/
"Client-Attorney privileged emails are not discoverable. To assert the privilege, these basic elements must be present:
"Given the limited application of the attorney-client privilege, most email correspondence done in the regular course of business will be discoverable in litigation and thus, possibly made public and/or used in support of a claim made against your business. Email forwards and attachments are discoverable too. If possible, don’t write anything you wouldn’t want shown to a jury on an eight-foot screen. Of course, when in doubt, the safest method is to simply pick up the phone."
Unfortunately, phone or voice calls can be easily snooped and new forms of calling that travel through IP (e.g. VoIP - voice over internet protocol) are easily and regularly intercepted, often not even encrypted. Law firms and businesses need a method of communications that is truly secure, ephemeral, and non-discoverable.
Privacy By Design and By Default
For the astute observers, this platform has privacy by design and by default. In the first iteration, in 2013, we were experimenting with facial recognition and biometrics to make logins more secure. I have since determined that using any form of biometrics is NOT a good idea for login purposes, because if compromised a person cannot change their fingerprints or irises like they can change passwords. So a principle of our security schema is to never require biometrics and never use it for login purposes. See: The challenge of cybersecurity in the age of surveillance.
Furthermore, I decided in 2014 to do away with logins entirely. This is meant to serve journalists reporting from hostile territories. We assume they can only get a message out by going to a cyber cafe and using available computers and internet connections. We assume those connections are continuously monitored, have man-in-the-middle permanently set up, and all keystrokes are logged. If a journalist were required to log in to use this service, they would be immediately compromised the moment they logged in. Using crpt.info, they would only need to type in the recipient's sendtoit code, send the message, and walk away - this is like walking up to a public phone booth, dialing your recipient's phone number, leaving a message, and walking away. No logins or other identification needed.
Furthermore, none of the "end points" (sender or receiver) of the message are ever associated. There are no phone numbers stored; and no other identifier is needed to use the system. The identities of the end points (e.g. phone numbers) are meta data that can be used by attackers and law enforcement to know this party called that party. Even if they cannot intercept and decrypt the contents of the message, they can subpoena it. In the case of this platform, there is no meta data, there are no logins, and neither end point of a message is ever associated with the other end point. The users of the platform are truly anonymous. The messages are secure and no user data is present anywhere -- that is what we mean by privacy by design and by default.