Ask HN: What's the most secure communications method today?
Assuming that I can exchange keys of some sort (physical, digital) with the other contact.
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.
But 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.
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.
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.
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 )
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.
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
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 :)
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:
https://en.wikipedia.org/wiki/Off-the-Record_Messaging
https://en.wikipedia.org/wiki/OMEMO
https://staltz.com/an-off-grid-social-network.html
https://en.wikipedia.org/wiki/Matrix_(communication_protocol...
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.”
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
10, 13, 16, 19, 22 = garry
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
^[^g][^r][^r].$
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'.