As with other forms of encryption, there's still the issue of key management / delivery over a secure channel. If you can't guarantee the pad cannot be intercepted, this method is also insecure...
I don't know. You can easily get sdhc cards that are 128GB, ditto for usb sticks. You'd need a high-bandwidth source of random data - or possibly proxy that with high-quality seed for a stream/bloc cipher (conceivably, it's easier to guarantee a one-time, controlled secure generation of a 256 bit symmetric key that's thrown away after generating your stream, than handling of session keys and complicated calculations on a message by message basis) - but I'm not aware of any secure system designed to work with such a one-time pad.
You'd need a way to keep track of sections of the pad [probably framing the message, maybe a start keyword could work - it'd give away the section of the pad, but as that section is never re-used... or, if you can assume few messages will be lost, just keep a local counter, and do a sliding search] - and there are other issues. Split the pad into sender/receiver sections (A only encrypt and send with a-apd, B only encrypts with b-pad - to avoid two messages encrypted with the same section of pad, crossing each other).
Still, if Eve gets a hold of a plaintext message from Bob, and can intercept the ciphertext before it gets to Alice - Eve gains access to a section of the otp by xoring - and can send anything to Bob (up to the same message length).
I'd be interesting to hear if there are modern cryptosystems /research based around one time pads?
I bet you cannot beat OTP written/printed/punched on toilet paper: Key hard to discover plus medium is easy to carry, easy to destroy, and degrades with time (bad archival medium).
-Then again, nothing to prevent you from digitally signing the message encoded in OTP.
So, you verify the integrity by a mechanism separate from the encoding. (This may or may not be sufficient, depending on the needs of the OP.)
Also, of course - the odds of someone tampering with a message encoded using OTP and having the tamper still appear a valid message once decoded could probably best be described as astronomical.
Not really astronomical. If you're just XORing your message with a pad, they can trivially flip bits by position. There are a lot of things an attacker can do with that, especially if they have some idea what you're sending.
All of these problems are present with any pure encryption method. That's why authentication hashes, message ids, high quality randomness sources, and so forth exist. OTP can use these just as well as any other encryption method.
What do you mean by "pure encryption method"? No one (no smart people) uses AES purely, but of course in some mode of operation such as GCM which provides integrity.
The problem may become delivering the key securely though. It probably has to be agreed upon in advance by the people being physically in the same location. But then each key still only usable for a single message. I think number stations communicating with spies use one time pads?
Define secure. Is leakage of meta data (who communicated with whom, when, and what size of data was exchanged) relevant? Or just the content? Is reliability of delivery part of "secure"?
What's your threat model? If you don't care about metadata and you can exchange keys, use some form of symmetric encryption. If you care about metadata then things are a lot more complicated.
But if you can assume that you have a secure channel for exchanging keys, you can just use that channel for communication.
There are latency issues. Suppose you meet up once to exchange CDs full of random data 20 years ago.
Now you can exchange messages with newspaper adds secure in the knowledge nobody can ease drop even though your secure communication happened 30 years ago. Granted, this is limited to low bandwidth text, but you can leverage this for key exchange if you happen to trust some other form of crypto.
You can mitigate the metatdata leakage by posting your GPG-encrypted message on pastebin, over Tor. Address it by putting the title of the next message in the encrypted text. For bonus steno disguise the message as a GPG signing block for something boring.
If you want it to not only be the most secure, where the answer in my opinion is symmetric encryption, but also the easiest to use, I would say using the app "Signal" on a smartphone. As long as you're able to meet afk and you can verify the safety number between the two phones, you should be good to go. Disappearing messages adds another layer of security.
I'm sure there are ways that are more secure in terms of encryption strength and opsec, but in the real world most people you want to communicate with aren't savvy enough for most "truly secure" setups to be realistic.
What I dislike the most about Signal is the need for a phone number though. Yes, I understand I could register with a temporary phone number but that still is not good enough.
Surely most smartphones will have a phone number anyway, no? It doesn't have to be connected to you personally and it's a good way to keep illegitimate Signal registrations down.
If you're talking pragmatically you may be correct.
Otherwise I don't see how trusting a third party binary (that you cannot easily verify) provides a more secure way of communication than other means where you have this possibility.
They publish some code, but the app itself is distributed in a form where you have to trust a whole bunch of third parties not to implement a backdoor to spy on you, and at least one of the parties benefits from both cooperating with the government and spying on you.
Not anymore. It has been decoupled with google services. Its even possible to install it on Replicant (entirely foss version of Android) they have the APK availible on their website. Please tell me if there are any non free parts in this APK. Because afaik its entirely free.
Does a one time pad qualify for what you defined as "key exchange"?
One time pads are proven to be perfectly safe as long as they are used correctly (read the first paragraph of the wikipedia page at https://en.wikipedia.org/wiki/One-time_pad )
>Assuming that I can exchange keys of some sort (physical, digital) with the other contact.
Each contact has an identical table of data (pure-random, 1 terabyte, ASCII 256 or choose your own encoding); this is your "Key of some sort". Messages sent between contacts are encoded character-by-character as offsets from the start of the table. No offset can be used more than once. After offset 1099511627776 (for a 1 terabyte files) has been used for encode, a new key file is generated and exchanged.
Example:
tables contains a terabyte of random data such as "ahx Ui D 7gu3a7NrdMr 9y&S )iM AAt 8'9s 98m..e kj j uhbd f..."
1,5,6,9,12,15,18,20,23,25,30,33,35,36,39,41 = hi garry it's me
If you're gonna go through the trouble of exchanging 1TB of one time key, use a standard one time pad. This method is either insecure (when offsets are not strictly ascending), or unnecessarily wasteful.
After searching the definition of one-time-pad, I'm pretty sure post is redundant and shall be deleted (in T-minus 2 minutes). [edit] No delete option. Mod please delete.
There's a subtle flaw in your design here. You're selectively discarding data with meaning and those decisions can be seen and you are not being strict enough with your rules about reuse of data. Although the user doesn't have to use the first possible index according to this scheme, chances are they would (and you did in your example)
The short form of the problem is where you say "No offset can be used more than once." where you actually want "No offset can be used unless it is higher than all previously used offsets".
Consider an assassin and their controller using this scheme for designating targets. Garry is first, the controller sends
10, 13, 16, 19, 22 = garry
The security services intercept this and notice that garry is killed.
They now know that 0-9 != g, 11-12 != a, 14-15 != r, 17-18 != r, 19-21 != y
They suspect that either andi or rory is the next target, the controller orders Andy killed and sends:
0, 15, 17, 27 = andi
The security services can then infer that the person to be killed is matched by the regex:
^[^g][^r][^r].$
andi matches, rory doesn't.
It's much better to treat your random characters as numbers to add to the your data mod 256 (in your ASCII 256 example), and also set rules like fixed message length and scheduled messages that can be 'no-op'.
This really depends on who you are and from what you are hiding:
1) Communication between non-targeted (unimportant) individuals hiding information from:
1.1) other individuals or non-governmental institutions
1.2) governments or GOs
2) Communication with targeted (important) individuals hiding information from:
2.1) other individuals or non-governmental institutions that target you
2.2) governments or GOs
The first one is the easier one as expected:
1.1) Individuals want to secretly share information without someone else notice. "Someone else" can be another person, family, friends, a teacher, collegues or their boss.
Important here is, that the person to hide the information from doesn't target you. This makes it VERY easy because the person doesn't necessarily expect any secrets to be exchanged.
Simple chat apps do here. Telegram and others support self destroying messages.
1.2) Individuals want to secretly share information without being (potentially) tracked by the government. They are part of the grey mass of "normal citizens".
As long as you or your partner are not actively watched by a government, things can still be relatively easy. Standard apps (eg WhatsApp, Telegram) might be even enough. Mass surveillance might be a problem though (in China, Iran or the US for example) so to be on the save side, better use non-standard software that is decentralised and uses hard encryption and something like Off-The-Record messaging. Good and mature candidates would be of course XMPP (aka Jabber) with OMEMO or the newer Matrix protocol.
2.2) Individuals want to hide information from someone who knows or suspects that they do it:
As soon as you or your communication partner is targeted, things get a lot harder. Now not only the information itself needs to be encrypted (good old rubber hose decryption works against the best encryption methods). Other individuals usually don't have sophisticated surveillance methods, so it should still be relatively easy. Important is, that meta-information (who communcated with whom at what time, etc) needs to be secret, too. As soon as the one who suspects you to secretly share information knows that you did, they will ask questions. Better they don't have anything at hand to do so.
Plausable denyability is the keyword. Off-the-record messaging provides this but is of no use if you keep the chat logs or be seen. Even the contact in your phone could be suspicious enough. Better use a dedicated system or memorise the contact information and only use it without saving it. Never ever communicate while the watching person could see it.
2.2) Governments or governmental organisations watch you:
Now this is the hard part. Hiding from a government that watches you and/or your communication is REALLY HARD. Don't be fooled by advertised end-to-end encryption and public law-suits of companies trying to defend their users privacy.
You have no idea what GOs are capable of which is why you need to implement measurements even against unknown attack vectors.
The best you can do is to hide your communication traces by following at least the following rules:
* Never use something that leaves a trace of personal information. Use pre-registered sim-cards or internet cafes in different cities. Always use public proxies, TOR, everything.
* Use asynchronous communication: Leave an encrypted blob somewhere in the void of the internet without any receiver. The receiver needs to be potentially everyone but of course nobody except the receiver can be able to read the message.
* Use disposable keys. Hide signatures but never forget to use them! A cryptographic secure signature is the only way for the receiver to be sure that it is really your message and nothing intercepted or faked. But the signature needs to be hidden inside the unreadable crypto-blob.
Phew… that was a long one. But I hope it gives you and the interested reader some insights.
Secure messaging on a bockchain. Due to the fact you no longer have to trust a 3rd party.
If you choose the Bitcoin blockchain then you can send your encrypted data and no-one will know who decrypted it due to the P2P nature of the network. Every node receives every message.
Example.
AES encrypt your message with a key you both know.
Add it to the message field of a bitcoin tranasction.
The person at the other end decrypts any transaction they find with a message until they find one which does decrypt with that key.
For more securtity you can hide the message in the content of the transaction. i.e. the public keys you pay to.
Or the public keys you pay from. You can break a txn into multiple components, each of which is formed as a function of a deterministic wallet. By having multiple change addresses you'd have more message space.
> Every node receives every message.
You could even send it with a very low mining fee, and theoretically the message would disappear. But it would require gaming of the system, because many nodes wouldn't pass-on txns that don't have a minimum txn fee.
This functionality is one of the key reasons that blocksize space needs to be controlled on a block-chain.
Neither one of these strike me as desirable characteristics of a secure messaging system. I can see the advantage in a third party not being able to tell who received a message, but in a perfect world as the sender I'd like to know that only my intended recipient received it, which is the opposite of what's going to happen with the block chain.
Also, to encrypt with AES you need to pick a key length, and since your message is going to everyone in the world, you need to pick a key that is both impractical to break using today's technology, but using all future technology for as long as your secret remains relevant. If AES is ever broken, then all bets are off.
If you have a chance to exchange keys of unlimited length ahead of time, then you could use a one time pad and message over the block chain. This would be secure, but then if you have a OTP, almost any message channel you pick is going to be secure. Someone else in this conversation recommended using newspaper ads.
These are contradictory statements, because privacy is an essential protection against censorship. You're never completely free to speak if you can't speak anonymously, and you can't speak anonymously if you don't have privacy.
As the SCOTUS wrote in McIntyre v. Ohio Elections Commission, “Anonymity is a shield from the tyranny of the majority.”
Signal, Wire, Privus SecurLine, Riot (Matrix), Threema are good candidates for audio and text secure communications.
Some leak metadata, some have countermeasures like not using own's phone number (SecurLine and Threema) or using fixed bitrate for audio calls (Signal, Wire, SecurLine).
If you want privacy and trust choose a solution in that you can audit the source code and that it is verified by a third party auditor.
For letter-like communications GPG is fully open-source, has gone through the fire of decades of use, and if you believe the Snowden leaks then even the NSA can't break it. If you're serious about security use it via something like Tails - keep the thing you boot from on you at all times, and never let plaintext leave your securely-booted system
For OTR-style messages I'd find a fully open-source messenger that uses an atoxl-like protocol - i.e. OMEMO (Conversations/ChatSecure) or Riot/Matrix
The problem with GPG and the like is that the assumption is made that the end platforms are secure (where the message is generated or read). They are not.
Is there something like a state of the art one time pad implementation which provides integrity and other security properties which are lacking with pure OTP?
The process of exchanging keys will theoretically leak metadata unless you already have an established secure line. In which case you will not need to open a new one, defeating the purpose.
Anyway, the most secure method of communication would be to leave all electronic devices somewhere far away and ideally locked in a solid metal box, then meeting in person somewhere where surveillance is hard or impossible. In the ideal case this will obfuscate all metadata including sender and receiver, unless someone happens to see you travelling to or away from the meeting place.
70 comments
[ 3.1 ms ] story [ 145 ms ] threadBut this is not very practical
You'd need a way to keep track of sections of the pad [probably framing the message, maybe a start keyword could work - it'd give away the section of the pad, but as that section is never re-used... or, if you can assume few messages will be lost, just keep a local counter, and do a sliding search] - and there are other issues. Split the pad into sender/receiver sections (A only encrypt and send with a-apd, B only encrypts with b-pad - to avoid two messages encrypted with the same section of pad, crossing each other).
Still, if Eve gets a hold of a plaintext message from Bob, and can intercept the ciphertext before it gets to Alice - Eve gains access to a section of the otp by xoring - and can send anything to Bob (up to the same message length).
I'd be interesting to hear if there are modern cryptosystems /research based around one time pads?
There's this implementation from 2015: https://techcrunch.com/2015/03/24/one-time-pads-ride-again/
If the key is pseudorandom instead of purely random, then you have yourself a stream cipher and not the OTP.
So, you verify the integrity by a mechanism separate from the encoding. (This may or may not be sufficient, depending on the needs of the OP.)
Also, of course - the odds of someone tampering with a message encoded using OTP and having the tamper still appear a valid message once decoded could probably best be described as astronomical.
Your OTP is extremely sensitive to the quality of randomness and requires a lot of it - which makes things very difficult.
It provides no authenticity and integrity or at least proof of tampering.
It does not protect from message reordering and capture+retransmission.
It obviously leaks metadata in a real-world usage: sender, receiver, msg length, time of message.
Cameras are harder to hide, so handing over some folded paper that you wrote on in private will be even easier. Just burn after reading :)
But if you can assume that you have a secure channel for exchanging keys, you can just use that channel for communication.
Now you can exchange messages with newspaper adds secure in the knowledge nobody can ease drop even though your secure communication happened 30 years ago. Granted, this is limited to low bandwidth text, but you can leverage this for key exchange if you happen to trust some other form of crypto.
I'm sure there are ways that are more secure in terms of encryption strength and opsec, but in the real world most people you want to communicate with aren't savvy enough for most "truly secure" setups to be realistic.
One time pads are proven to be perfectly safe as long as they are used correctly (read the first paragraph of the wikipedia page at https://en.wikipedia.org/wiki/One-time_pad )
Each contact has an identical table of data (pure-random, 1 terabyte, ASCII 256 or choose your own encoding); this is your "Key of some sort". Messages sent between contacts are encoded character-by-character as offsets from the start of the table. No offset can be used more than once. After offset 1099511627776 (for a 1 terabyte files) has been used for encode, a new key file is generated and exchanged.
Example:
tables contains a terabyte of random data such as "ahx Ui D 7gu3a7NrdMr 9y&S )iM AAt 8'9s 98m..e kj j uhbd f..."
1,5,6,9,12,15,18,20,23,25,30,33,35,36,39,41 = hi garry it's me
The short form of the problem is where you say "No offset can be used more than once." where you actually want "No offset can be used unless it is higher than all previously used offsets".
Consider an assassin and their controller using this scheme for designating targets. Garry is first, the controller sends
The security services intercept this and notice that garry is killed.They now know that 0-9 != g, 11-12 != a, 14-15 != r, 17-18 != r, 19-21 != y
They suspect that either andi or rory is the next target, the controller orders Andy killed and sends:
The security services can then infer that the person to be killed is matched by the regex: andi matches, rory doesn't.It's much better to treat your random characters as numbers to add to the your data mod 256 (in your ASCII 256 example), and also set rules like fixed message length and scheduled messages that can be 'no-op'.
1) Communication between non-targeted (unimportant) individuals hiding information from:
1.1) other individuals or non-governmental institutions
1.2) governments or GOs
2) Communication with targeted (important) individuals hiding information from:
2.1) other individuals or non-governmental institutions that target you
2.2) governments or GOs
The first one is the easier one as expected:
1.1) Individuals want to secretly share information without someone else notice. "Someone else" can be another person, family, friends, a teacher, collegues or their boss.
Important here is, that the person to hide the information from doesn't target you. This makes it VERY easy because the person doesn't necessarily expect any secrets to be exchanged.
Simple chat apps do here. Telegram and others support self destroying messages.
1.2) Individuals want to secretly share information without being (potentially) tracked by the government. They are part of the grey mass of "normal citizens".
As long as you or your partner are not actively watched by a government, things can still be relatively easy. Standard apps (eg WhatsApp, Telegram) might be even enough. Mass surveillance might be a problem though (in China, Iran or the US for example) so to be on the save side, better use non-standard software that is decentralised and uses hard encryption and something like Off-The-Record messaging. Good and mature candidates would be of course XMPP (aka Jabber) with OMEMO or the newer Matrix protocol.
2.2) Individuals want to hide information from someone who knows or suspects that they do it:
As soon as you or your communication partner is targeted, things get a lot harder. Now not only the information itself needs to be encrypted (good old rubber hose decryption works against the best encryption methods). Other individuals usually don't have sophisticated surveillance methods, so it should still be relatively easy. Important is, that meta-information (who communcated with whom at what time, etc) needs to be secret, too. As soon as the one who suspects you to secretly share information knows that you did, they will ask questions. Better they don't have anything at hand to do so.
Plausable denyability is the keyword. Off-the-record messaging provides this but is of no use if you keep the chat logs or be seen. Even the contact in your phone could be suspicious enough. Better use a dedicated system or memorise the contact information and only use it without saving it. Never ever communicate while the watching person could see it.
2.2) Governments or governmental organisations watch you:
Now this is the hard part. Hiding from a government that watches you and/or your communication is REALLY HARD. Don't be fooled by advertised end-to-end encryption and public law-suits of companies trying to defend their users privacy.
You have no idea what GOs are capable of which is why you need to implement measurements even against unknown attack vectors.
The best you can do is to hide your communication traces by following at least the following rules:
* Never use something that leaves a trace of personal information. Use pre-registered sim-cards or internet cafes in different cities. Always use public proxies, TOR, everything.
* Use asynchronous communication: Leave an encrypted blob somewhere in the void of the internet without any receiver. The receiver needs to be potentially everyone but of course nobody except the receiver can be able to read the message.
* Use disposable keys. Hide signatures but never forget to use them! A cryptographic secure signature is the only way for the receiver to be sure that it is really your message and nothing intercepted or faked. But the signature needs to be hidden inside the unreadable crypto-blob.
Phew… that was a long one. But I hope it gives you and the interested reader some insights.
Some links to kick-off the research:
If you choose the Bitcoin blockchain then you can send your encrypted data and no-one will know who decrypted it due to the P2P nature of the network. Every node receives every message.
Example.
AES encrypt your message with a key you both know.
Add it to the message field of a bitcoin tranasction.
The person at the other end decrypts any transaction they find with a message until they find one which does decrypt with that key.
For more securtity you can hide the message in the content of the transaction. i.e. the public keys you pay to.
Or the public keys you pay from. You can break a txn into multiple components, each of which is formed as a function of a deterministic wallet. By having multiple change addresses you'd have more message space.
> Every node receives every message.
You could even send it with a very low mining fee, and theoretically the message would disappear. But it would require gaming of the system, because many nodes wouldn't pass-on txns that don't have a minimum txn fee.
This functionality is one of the key reasons that blocksize space needs to be controlled on a block-chain.
> Every node receives every message.
Neither one of these strike me as desirable characteristics of a secure messaging system. I can see the advantage in a third party not being able to tell who received a message, but in a perfect world as the sender I'd like to know that only my intended recipient received it, which is the opposite of what's going to happen with the block chain.
Also, to encrypt with AES you need to pick a key length, and since your message is going to everyone in the world, you need to pick a key that is both impractical to break using today's technology, but using all future technology for as long as your secret remains relevant. If AES is ever broken, then all bets are off.
If you have a chance to exchange keys of unlimited length ahead of time, then you could use a one time pad and message over the block chain. This would be secure, but then if you have a OTP, almost any message channel you pick is going to be secure. Someone else in this conversation recommended using newspaper ads.
This is useful when you want to send a mesage but you don't want anyone to know who you were sending too. It's a form of obfuscation.
The risk with communication is to not have your message read by the right people.
The risk with communication is for your message not to properly reflect your true intent.
1. We need to stop obsessing about privacy.
2. We need to fight censorship.
3. We need to improve our semantic model.
As the SCOTUS wrote in McIntyre v. Ohio Elections Commission, “Anonymity is a shield from the tyranny of the majority.”
Bullshit.
Some leak metadata, some have countermeasures like not using own's phone number (SecurLine and Threema) or using fixed bitrate for audio calls (Signal, Wire, SecurLine).
If you want privacy and trust choose a solution in that you can audit the source code and that it is verified by a third party auditor.
For OTR-style messages I'd find a fully open-source messenger that uses an atoxl-like protocol - i.e. OMEMO (Conversations/ChatSecure) or Riot/Matrix
Anyway, the most secure method of communication would be to leave all electronic devices somewhere far away and ideally locked in a solid metal box, then meeting in person somewhere where surveillance is hard or impossible. In the ideal case this will obfuscate all metadata including sender and receiver, unless someone happens to see you travelling to or away from the meeting place.