Horcrux Encrypted Messaging
notion.so
notion.so
* The 0day argument (that using multiple apps reduces exposure) is a poor one. If we're talking about 0days that allow message decryption from a MITM, this is true--but if we're talking about RCE with (on mobile OSes) a local sandbox escape (e.g. https://threatpost.com/whatsapp-zero-day-exploited-in-target...), then installing more apps increases the attack surface and thus the risk.
* Another argument for multiple services seems to be some implied DOS resistance. But of course exactly the opposite is true: if you split your message and deliver it via multiple channels, any one of those channels can be taken offline and thus thwart message delivery.
* The real argument for multiple services seems to be based on an assumed threat model of an attacker who primarily relies on lawful intercept orders, not on technical capabilities (e.g., a warrant, not cryptanalysis). Adding multiple services may do little or nothing for the latter threat, since many messaging services rely on the same underlying protocols (e.g. the Signal Protocol) or the same crypto primitives. This is important for my next point:
* If the threat model is about lawful intercepts, and you actually trust modern crypto, this entire scheme makes no sense. Just share a public key for a common, well-vetted algorithm. Encrypting messages using an air-gapped device makes sense.
* Further, if we trust crypto, this scheme's sole value is effectively in contact (or public key) discovery: assuming you can't meet face-to-face, the point of this scheme is really to allow multiple services to help you discover a contact's public key (assuming we replace the unnecessary OTP approach with public key exchanges). But many (most?) of these services rely on the telephone system for identity--so there's still a fairly trivial single point of failure, commonly controlled by the government.
* To beat a dead horse: if we don't trust modern crypto, it's likely an adversary can access all components of the message+OTP anyway (even without lawful intercept capabilities), so this scheme adds no value.
Summary:
This proposal would benefit by a more clearly stated threat model. As-is, it's hard to come up with a coherent threat model where this proposal adds value.
E.g. attacker may have no idea where the OTP key is sent, nor on what messaging platform, and would need to crack earlier messages to potentially find out what the communicators were using for all other parts of the horcrux cohort. That's a chicken and egg problem for the attacker. The information on exactly where and what the other horcruxes are could be residing entirely elsewhere in a very encrypted way, or even discussed in person.
[†] I'm interested in the hyperbolic claims about OTP in and of itself bringing 'perfect secrecy' via networked communication. Aren't the mechanisms to transmit OTP keys (i.e. the transport mechanisms over the network) prone to weaker security than the OTP mechanism itself? But again, I think that's what this idea helps mitigate.
I'm not sure I buy your argument for the value this may provide, though.
* The question you pose for an attacker--which platform and which device/identity was used to send a message of interest--already exists, in a more general form, for any attacker. Our threat model presumes the attacker has solved it, or else we wouldn't need e2ee to begin with.
* If you're going to discuss something in person, instead of discussing how to use a small number of different channels or identities, just share cryptographic keys!
It's my strong sense that the author is mostly ignorant of encryption itself (hence the misuse of OTP) and instead is trying to solve for the problem of lawful intercept (and hence the digression about supply chain security). This is a somewhat reasonable concern, but I don't think the proposal does much to help with it.
As I noted above, barring assumptions of extremely pervasive full stack compromise (or full compromise of common cryptographic primitives, an air-gapped dedicated device for encrypting messages with preshared keys provides all the security of this scheme, reduces risk (e.g. of 0days), and is far more usable.
Is there some other way I can explain it better, maybe a specific section on a Threat Model (there's a vulnerabilities section to include things not in the threat model).
In terms of explaining, try to describe specific threats (including what the attacker can and cannot do, ideally with a real-world example).
E.g. can your attacker:
* Observe ciphertext? Do they have global network MTIM? (Passive or active?)
* Break e2ee? For example, do they have the ability to derive messages from merely passively observing ciphertext?
* Compel service providers to share any data the provider has?
* Compel providers to serve malicious code to their users?
Etc.
This proposal is missing any formal threat model, so it’s hard to evaluate what it’s intended to do. I cannot immediately come up with a threat model where this makes sense, unfortunately.
Yes! Exactly, that's the brilliant part of this. There is symmetric trust (distrust really) of every channel. We equally distrust all channels a bit, and expect them to be exploitable by different non-overlapping parties (see Venn diagram). In old times you couldn't do this since there weren't so many ways to communicate, and they were all insecure except one very very expensive one.
Nowadays, there are multiple channels people use which are all mostly secure using modern crypto, except for some very specific vulnerabilities and state-sponsored attacks, but usually only from 1 or otherwise very expensive per attack. That's the innovation that Horcruxes exploits! Do you see?
There is a section on Threat Model, also if you just think about it you can imagine the threat models yourself, looking at what it does and the use cases. I've added those explicitly into that section.
The problem is you're proposing a scheme that's completely insecure if all channels are being watched by the same entity. The fact you're not employing public key encryption to mitigate this issue is really weird.
"expect them to be exploitable by different non-overlapping parties (see Venn diagram)."
Don't. NSA knew about the Sony hacks because they had hacked the systems of North Korea's cyber army. There's no telling if they're inside e.g. WeChat's servers.
Cryptographic security is on so different level it's hard to emphasize it. Perhaps a comparison to computational effort would suffice:
Let's say a zero-day exploit to compromise one server costs 1,000,000 USD. Let's say brute forcing an 80-bit key also costs 1,000,000 USD. Let's say you're using two servers to deliver the alone unbreakable horcrux halves. It's costing exactly 2,000,000 USD to recover the message
This is the equivalent to brute forcing an 81-bit key. My point is, it's much cheaper to break the channels than it is to break the encryption keys that start from around 128 bits and go up to 256 bits.
"In old times you couldn't do this since there weren't so many ways to communicate, and they were all insecure except one very very expensive one."
In the old times there was no encryption whatsoever in Yahoo Messenger, MSN messenger etc. In the old times there was no E2EE so you only had to hack the servers to get access to massive amounts of user data (this still holds true for some shit services, e.g. Telegram).
"--except for some very specific vulnerabilities and state-sponsored attacks"
State sponsored attacks are about hacking endpoints, like Besos' WhatsApp. And Horcrux doesn't solve this in any way. Even if your magic wand is an airgapped device. See
https://ieeexplore.ieee.org/document/7122176
and
https://www.computer.org/csdl/magazine/co/2015/07/mco2015070...
I'd encourage the author to read about how to create a good formal threat model, like https://docs.microsoft.com/en-us/learn/modules/tm-introducti....
That said, to pick this apart a bit:
> Also consider the threat in case a Messenger is compelled by the its local government to leak keys on the client (say through an app update) or server by warrant, or there is a rogue employee at Messenger company who compromises.
Of course an e2ee messenger like Signal cannot leak keys via server compromise.
> Often a high security environment will compile its own version of Signal's open source client, however it will be days or weeks old and have published vulnerabilities.
[citation needed]
> Horcruxes would allow the high security user to send 1 horcrux on the custom compiled Signal version, and another horcrux on the public app store version (in addition to others), thus increasing the cost significantly of hacking all horcruxes.
What are those vulnerabilities? If they're RCEs or similar, I fail to see how this helps. If they're vulnerabilities in the Signal protocol--well, as I said, [citation needed].
> Horcruxes sent on separate devices/OSs/channels increase costs linearly for 0-day vulnerabilities on apps and OS's.
No, they decrease costs linearly for 0days.
> Specifically, we assume that one nation state, for one messaging channel, a nation-state observer:
[snip]
> Can compel providers in their nation to serve malicious code to their users
So as I noted before, the only threat model for which this system appears to make any sense is one where attackers can serve malicious updates to off-the-shelf messaging systems. I'm going to talk about that threat model alone. (If there are others, I'm happy to discuss them!)
While this is a serious concern (and is the reason that code signing, binary transparency, and similar exist--likely far more practical solutions to this problem), fundamentally this scheme merely begs the question: if I can't trust code that has access to the message plaintext, how am I going to implement this system? (Certainly the thing that does the XOR and splitting and QR code whatnot may be simpler code than a full-featured e2ee messaging app, so maybe easier to audit. But pen and paper is even easier to audit!)
It sounds like at heart what we need is pen-and-paper cryptography where we then share the OTP over one channel and the ciphertext over another. And that is a reasonable approach if you truly cannot trust your computing stack. (Of course, if you're going to go that far, you might as well just meet face-to-face and exchange a large one-time pad. Then you wouldn't need to muck about with multiple "horcruxes" anyway!)
I think you're still missing one of the points: if you use a separate app, OS, and device platform (as shown in the diagram) then it would increase cost of 0-days linearly, since you'd need to get a 0-day for each horcrux. Does that make sense now?
I'd appreciate you not be dismissive in tone, please. I have had multiple security experts look at this, so if you think it's dumb then it's probably that you missed a part and not that it's dumb.
I get you, you're thinking, it's safe as long as one of the channels is not tapped by the same entity. But the problem is this: You're relying on the assumption at least one of the channels is safe. The point of public key cryptography is to protect communication even if none of them are safe. The best the adversary can do in those scenarios is MITM attack, which can be detected over an authenticated channel.
"It's not perfect, but it would make any attacker's job harder, right?"
It's much easier and cheaper to hack WeChat's non-E2EE messaging app service to steal the OTP keys that decrypt the messages, than it is to break e.g. Curve25519.
"That's a chicken and egg problem for the attacker."
It's not. All the attacker needs to do is look at the metadata like TCP headers, to see what servers the device talks to. Also note that the author does not propose any remedy to this problem, especially not a single mention of Tor.
"The information on exactly where and what the other horcruxes are could be residing entirely elsewhere in a very encrypted way, or even discussed in person."
It's a bit much to assume peers are willing to play secret agent, perform periodic rendezvous to exchange OTP material etc. Also, the problem with SSS is, pieces are created on demand, in that sense using multiple OTPs is better.
"Aren't the mechanisms to transmit OTP keys -- prone to weaker security than the OTP mechanism itself?"
Yes, practically always. The only way to do it more securely is in via sneakernet, in person. This would apply even if you'd do quantum key distribution (e.g. the BB84 requires the Carter-Wegman MAC's key to be pre-shared to authenticate transmission's basis and thus that no OTP interception took place). And that's not something you want to keep doing, thus PSKs are much more usable and thus more secure a choice.
Let's remember Shamir's scheme also allows recovery of the message as long as the threshold of minimum amount of shares is exceeded. But otherwise I agree with your thoughtful assessment.
Witty, sure, but I would not trust it with sensitive data at all if it is relying on political relations ("politics") only.
> Many [vulnerabilities] in Whatsapp/Telegram/Signal
Please provide citations for currently known vulnerabilities of each of these, then.
Telegram does not even support "secret chat" (E2EE) on their desktop and web version of the software[1]. No need for vulnerabilities here.
They have had 0-days before, and they will have 0-days in the future. Jeff Bezos was hacked by Saudi Arabia using a WhatsApp 0-day. It's a property of complex software. Companies in Israel and elsewhere are paid millions to find these 0-days.
Note the system totally fails and is zero day-able if you have all of the data streams merged on a non magic wand device. The separation of data seems really important to the system as a whole.
Horcruxes provide a unique solution to the problem of dragnets and increase costs of hacking your device even for governments.
https://wikileaks.org/ciav7p1/cms/files/NOD%20Cryptographic%...
> Certificate validation must not be performed against any standard SSL root CAs.
> implement an inner cryptostream within the SSL tunnel transfer
People often state that you should not roll your own crypto. Definitely, you look foolish for making a mistake doing your own thing. However, adding your own layer on top of a standard one seems safe and likely to slow an adversary down considerably. Adding a layer below to encrypt data before the standard algorithm gets it has some risks (e.g. could leak in some complex way like a timing attack) but it also protects against a compromise in the implementation of the standard algorithm.
Adding the Horcrux layer of multiple channels does seem to increase security at the cost of creating a new unvalidated magic wand that then becomes the attack surface - and another significant cost in that it is not user friendly and involves considerable effort per message. There are ways of implementing greater security at high cost, e.g. point-to-point communications off network. The question is if the extra effort confers any benefit. Sometimes just the fact that two parties are communicating is valuable knowledge and this Horcrux mechanism actually makes that easier to detect as it occurs across multiple systems.
> Sometimes just the fact that two parties are communicating is valuable knowledge and this Horcrux mechanism actually makes that easier to detect as it occurs across multiple systems.
Steganography can alleviate that red flag.
Sure, but the problem it solves is not the problem that needs addressing. Ciphertext and key delivery can already be done safely with E2EE apps like Signal. Metadata can be eliminated with e.g. Tor Onion Services.
Your apps relies on QR-codes to exchange data, the same channel can be used to authenticate Signal endpoints and/or exchange PSKs, no need for SSS. Goal for information theoretic security is fine but considering nobody is doing CT-only attacks against modern algorithms anyway, the easiest attack vector will be MITM attack or remote key exfiltration. E.g. Snowden has been very vocal in the past about NSAs of the world hacking endpoints, but has quieted a bit down wrt the matter, perhaps he realized that was too high bar for average users who still benefit from incremental security from Signal etc.
I'm not very certain what value this adds to the landscape. Is it possible the developers can elaborate here?
However, using a symmetric algorithm like AES could give you better performance since that would reduce the bandwidth overhead from O(h * n) where n is the size of the message and h is the number of horcruxes to O(n + k * h) where k is the size of the key.
Note that I am maintaining ZERO infrastructure here (important! also since it can help prevent DOS!), so it doesn't cost me anything to send these. A lot of these messaging infrastructures are free to users too. So does it really matter that it's O(h * n)? h will always be not that big too, (n as well!) so it's not that much data. It is not much data, and costs me nothing, and costs the user nothing. Does it matter?
I like that OTP has perfect secrecy and is super easy to code and audit the code (NSA hasn't snuck in any weird matrices, no weird goto return bug, buying a bigger quantum computer doesn't break it, etc).
You could also use Horcruxes to set up public key encryption or a key exchange, then do the rest of the communication on a new channel directly using public key encryption.
Sending your key in plaintext over a separate channel isn’t really perfect secrecy but okay... it’s interesting, but laden with assumptions.
This: "We will send the ciphertext through Signal and the one-time pad through WeChat."
You're sending the OTP in plaintext. This is the age-old key distribution problem, and that's not magically solved by using a separate channel.
They're both totally random 0's and 1's. Only putting them together (using simple XOR) makes them a message.
The separate channels is important since each is mostly E2EE secure except for the whole government spying problems, but usually not all of them cheaply on each service. We live in unique times now where this wasn't as relevant or possible before.
Does that make sense?
People who are anonymous can generally have anonymous conversations. Once anyone becomes interested in those conversations, they are not anonymous and none of their existing strategies are applicable.
State actors have the resources to store messages now and correlate them later. If either is plain text, the other will fall.
Maybe I'm totally wrong because it's a different enough industry to be able to use it, but what happens in practice however is another thing. Remember Jo Rowling is a billionaire, hehe. Also, it's a completely unique word that she proudly invented. She said before creating it she checked and Google had zero results on the word.
This doesn't help but XORcrux would also work maybe
As with all things, the simplest UX will probably win.
Lastly, if you use a single client like a phone for sending/assembling all of your horcruxes, that’s probably the place that an adversary would target.
Maybe not Signal, but there are multiple secure encrypted email clients which DO have programmatic access including ProtonMail, DeltaChat, and others which are under different jurisdictions around the world.
Also you can compile and run your own custom version of the open source Signal Client which does have programmatic access :)
>Lastly, if you use a single client like a phone for sending/assembling all of your horcruxes, that’s probably the place that an adversary would target.
That vulnerability is listed and described in the doc. It still has security, just a different threat model, just not as much security as using multiple devices.
Note that under your one Signal app one device, you have no way to prevent this attack at all. Horcruxes now open up new possibilities.
"Often the 0-days are targeting the most common platforms, so using a lesser used platform increases the attack cost linearly or superlinearly."
There's only so many platforms. The exploit would either be directed against the app itself or the OS or some other popular software package like SSH server running on the endpoint.
The threat model of Horcrux doesn't differ from Signal: both are effectively networked TCBs. This will hold unless you explicitly spec it to run on other systems like airgapped, or split TCB configurations.
"Horcruxes now open up new possibilities."
What the world needs is less vague marketing language, and more concrete examples.
> What the world needs is less vague marketing language, and more concrete examples.
Please chill out with the attacks, this is an idea I'm not selling anything. There's a multi-page doc describing it in detail, not vague at all.
Threat Models enhancement over Signal described in the doc:
## Threat Model
One set of threats this protects agains is any for which people would use Signal for: encrypted security. Also consider the threat in case a Messenger is compelled by the its local government to leak keys on the client (say through an app update) or server by warrant, or there is a rogue employee at Messenger company who compromises.
Often a high security environment will compile its own version of Signal's open source client, however it will be days or weeks old and have published vulnerabilities. Horcruxes would allow the high security user to send 1 horcrux on the custom compiled Signal version, and another horcrux on the public app store version (in addition to others), thus increasing the cost significantly of hacking all horcruxes.
I'm not attacking you, just the concept. The goal is not to hurt you, but to protect others. Please don't take it personally!
"What is TCB?"
https://en.wikipedia.org/wiki/Trusted_computing_base
"One set of threats this protects agains is any for which people would use Signal for: encrypted security."
Well, yes, confidentiality is the desired property of encrypted messengers.
"Also consider the threat in case a Messenger is compelled by the its local government to leak keys on the client (say through an app update) or server by warrant"
I'm not sure what the EARN IT / LAED bill's status is, but for now what holds is US vs Bernstein that established code as speech, and thus protected with 1st amendment, which includes backdoors (effectively compelled speech, also protected under the 1st). Also, Signal has pledged to move abroad if the bills pass. Given that the clients are reproducible and FOSS, I'm going to take any claim that the US government can just force a die-hard cypherpunk like Moxie to add a backdoor and keep that quiet with all his contacts at the ACLU and thee EFF, with a truck-load of salt.
"rogue employee at Messenger company who compromises."
The git tree is a rather permanent log for who merges a backdoor into the code. Also, there's most likely some form of code review especially wrt security critical code.
"Often a high security environment will compile its own version of Signal's open source client"
Citation needed.
Also, why wouldn't the independently compiled client also update itself automatically via Signal's servers? It's not like the APK version (https://signal.org/android/apk/) doesn't also update itself.
"Horcruxes would allow the high security user to send 1 horcrux on the custom compiled Signal version, and another horcrux on the public app store version"
The thing is, Signal can only be compromised by hacking the endpoint, as can Horcrux. If you're relying on the secrecy of the CT delivery mechanisms, you're essentially attempting security through obscurity that only adds log2(n) bits of security where n is the number of possible delivery paths.
The idea of trust Signal no matter what is funny though.
If you can't trust networked TCB there's not much you can do anyway. Adding one or more networked TCBs that also need to be compromised isn't going to turn into anything magical.
It's about the architecture, and if you need architecture of "no sensitive key/pt material on networked device(s)", you're out of options quite fast. It's either airgaps (shown to be weak as I linked the IEEE etc. articles above), or split TCBs (AFAIK my research on that is the only public work available).
That said, I reinterpret this idea slightly and think it’s brilliant — to Shamir split a message between different channels is a really good idea. To split them in such a way that different nation-state actors will each encounter significant expense is pretty brilliant.
Ultimately, (and I think this is acknowledged), for this to be usable you’re going to need a device that you don’t think is compromised to read and send; In the crypto world, the canonical device would be a formatted flashed older phone that you never turn on data for; it would then use the camera to scan and incorporate the QR codes sent through each channel and recombine them.
If that’s the best usability Horcruxes provide, they are going to be used only for ultra-high-value short communication — private keys, passwords, GPS locations of very high value.
TL;DR The proposal provides some improved messaging security but at high usability cost. I think it’s probably better than not using it if you use it as an app on your “main” phone, but it doesn’t give full benefits in that mode.
That's where the concerns start. There's no data about which services are compromised by which entities, no effective threat model, no dissection about the expected capabilities of the attackers. No recommendations for through where to pass the shares. It's not at all clear why'd they recommend WeChat that's not E2EE at all. It's also expanding the TCB by encouraging installation of insecure apps (like WeChat). It's also relying on the assumption it's always the case at least one channel isn't compromised, which is really weird, it would be much better to do airgap-to-airgap public key encryption instead, at least on the inside. That way the networked endpoint(s) receiving the shares is not the weak point of the system. Finally, as was mentioned, the app will leak metadata about the communication to every service used to deliver the shares.
"In the crypto world, the canonical device would be a formatted flashed older phone that you never turn on data for"
Well that assumes the Baseband processor does not talk to cell towers. Airgapping a mobile device isn't very easy so a cheap netbook might do better. Or, a more modern phone like Librem with mechanical kill switches for cell/wifi would be much better.
The problem is also, is the QR-code safe, what if you unknowingly scan an exploit that then exfiltrates data off the airgapped device inside the next QR-code containing a share.
It's a nice thought experiment but there's simply not enough benefits to beat the problems, and at most I can see this increase the attacker's cost slightly, instead of automated remote exploitation of single device, they now need to exploit a few devices receiving shares over (possibly E2EE) apps.
Yes, entropy and true randomness will be an issue. I can imagine manufacturing a Magic Wand (all in the US) which would be a custom piece of HW with an entropy chip (maybe using cosmic rays?)
Yes you're right and I mention that in the Usability section.
It's definitely an interesting idea, but the security claims are rather overstated. If "Horcrux" has a vulnerability, then no, you don't necessarily have to hack each of the transport services to abuse that vulnerability. Depending on what kind of vulnerability it is, you might be able to send someone a message that their client parses and runs your malicious code, or perhaps it leads to plaintext recovery or malleability when you intercept or tamper with only one service.
Another thing to note, somehow missing in the table of (magical) claims where Horcrux comes out on top in every comparison, is that metadata is a problem that you're greatly exacerbating with this. Now not only the USA knows who talks to who, but also Russia and China (in the example given with VK and WeChat). I'd be happy for my chats to run encrypted through Russia since they have very little else on me and distributing who knows what is a good way to prevent someone from knowing everything, but it's still a thing to note.
Edit: And reading a bit more in detail... this seems worrying:
> We will send the ciphertext through Signal and the one-time pad through WeChat
So if a service assumes that a three-byte message is "yes", they can change that into "no " (note the space) by just xoring against one of the two messages ('ciphertext' or 'one-time pad') right? You don't need to capture both.
The claim "no passwords, encryption keys, and no complicated key management. There is no trust of any complicated public key algorithm, key lengths, or code" makes that there is also no way to verify authenticity of anything. You just have to hope that China, Russia, and the USA all independently decided not to mess with you today; it takes only one, not all three/N.
Proof of concept:
Send (hex) c64d2d through service A and (hex) bf285e through service B. The recipient xors them together and gets (ascii) "yes", the original message.
Now what if service A decides to tamper with it? They xor c64d2d with "yes" and get bf285e. By no coincidence, that's what will be sent through service B. They can xor anything against that, such as "no " (6e6f20), which would result in d1477e. When the recipient receives d1477e from one channel and bf285e from the other, they xor it together and show the message: no.
Good point about how now multiple nation states know who you're talking to, whereas if you only use Signal then it's probably only US gov. I'll add that to the Vulnerabilities section! Note that steganography can help with that, or you can use a messaging channel which doesn't transparently tell governments who you're talking to (not Signal!)
For remote key/plaintext exfiltration, it's enough the plaintext message or private key is in the memory of the application for some time. The exfiltration attack can then use privileged process to periodically read the memory of the Magic Wand application. There's nothing an app on a networked TCB can do against that. You need either an airgap or preferably a split TCB to protect yourself against endpoint exploitation.
1) the security of the individual endpoints with access to each share. Let's say your magic wand is airgapped and nothing gets in via the share transmission media (QR-code, thumbdrive, whatnot). What if your Huawei, iPhone and device N are compromised via network because they're all connected to network at all times. The adversary can then just steal all necessary shares and they don't even need to access your magic wand, they can just XOR the shares from the three receiving endpoints and recover the message.
2) Airgap exfiltration security. Let's say the iPhone is secure enough and the adversary can't hack it. But how are you ensuring the QR-code scanner app of the Magic Wand can not be exploited with a carefully crafted QR-code? If the Magic Wand is compromised, it can leak plaintext messages the next time you scan the QR-codes of outgoing shares.
Signal, of course if they get your keys by force, can do the same thing, just on a single client. So there isn't any more security.
Finally, if you have 3, 4, 5, horcruxes, then they would still all need to cooperate to get the messages in order to do this perfect XOR (and remember they need to hack through the E2EE on each service too by getting your keys).
Encryption aims to provide not just confidentiality but also integrity and authenticity. Three guesses what the integrity means.
"I haven't heard about anybody making things tamper-proof from a government that has got your keys."
Ok seriously reconsider taking a course or two on cryptography before venturing any further. The malleability of Vernam ciphers like stream ciphers and OTP -- even when the attacker is not in possession of the key -- is a well known thing.
"if you have 3, 4, 5, horcruxes, then they would still all need to cooperate to get the messages in order to do this perfect XOR"
Nope. It's enough they change one of the ciphertext parts if they can guess the plaintext for whatever reason. This is known as a known plaintext attack or KPA. You should address it as part of your scheme, look into one-time MACs and Carter-Wegman MACs.
What? Keys "by force"? So if they come to my house and threaten me? I doubt that any security scheme holds up under that, yours nor theirs.
> Finally, if you have 3, 4, 5, horcruxes, then they would still all need to cooperate to get the messages in order to do this perfect XOR
I won't spend another 30 minutes making another POC but I'm fairly sure that this is not true.
Have you tried it?
If I'm not mistaken: the third, fourth, and fifth OTP are xored together with the first and second, and are therefore the same as xoring messages 2..5 together into one value and xoring that with the first message. The result of {plaintext} xor {any of them} will match the value of {xor the others together}. Therefore any of them can decide to do the attack and they don't even need to know how many other messages/channels/OTPs/horcruxes there are.
Oh I see what you mean about modifying. Good point. That's not in the threat model, I haven't heard of people doing that, but if it is a worry and you want to add it to the threat model, it's not hard to add a hash to the messages that will be a commitment scheme to ensure that you have all horcruxes and they haven't been tampered with. That's pretty easy.
Oh dear god. No, hashes aren't to provide authenticity and integrity for messages under hostile conditions, look into Message Authentication Codes (effectively keyed hashes) like HMAC-SHA256, or use modern hash function (SHA3-256 or BLAKE2) in H(key+message), or since you're going for information theoretic security, look into unconditionally secure MACs like one-time MAC and Carter-Wegman MAC. Also, make sure to compare the purported tag to the evaluated one with a constant time function. This is so low level I'm not at all confident at your ability to implement this stuff so please take a course in cryptography before implementing anything and if you do, make sure to put a huge banner "This is a hobby project intended to learn about cryptography, do not use it in production". This is to protect you and others.
Please see https://en.wikipedia.org/wiki/Commitment_scheme
It's a completely different thing. Authentication isn't about committing to something that's revealed later. Authentication is about detecting any changes in the plaintext content -- that would indicate the new message is from different author.
Heh, that's funny, the documented threat model was looking at observing text, not changing it. I haven't heard about anybody making things tamper-proof from a government that has got your keys.
With Signal, of course if NSA got your keys by force, can do the same thing, just on a single client. So there isn't any less security than Signal.
Finally, if you have 3, 4, 5, horcruxes, then they would still all need to cooperate to get the messages in order to do this perfect XOR (and remember they need to hack through the E2EE on each service too).
It doesn't really matter what your threat model is if people see "encrypted messaging" and think it's to secure chat messages....
Putting an asterisk somewhere that indicates you exclude the single biggest source of issues for an encryption scheme is like throwing a brick through Sony's window with the text on it "BY ACCEPTING THIS BRICK THROUGH YOUR WINDOW, YOU ACCEPT IT AS IS AND AGREE TO MY DISCLAIMER OF ALL WARRANTIES, EXPRESS OR IMPLIED, AS WELL AS DISCLAIMERS OF ALL LIABILITY, DIRECT, INDIRECT, CONSEQUENTIAL OR INCIDENTAL, THAT MAY ARISE FROM THE INSTALLATION OF THIS BRICK INTO YOUR BUILDING." (http://bash.org/?577451)
Anyhow, defending a broken scheme rather than just honestly saying "I had not considered that; I'll introduce X to fix this issue." also kind of breaks any credibility down for me.
The whole point of using these existing schemes is to inherit at least the security properties of those channels, and then augmenting them and mitigating some threats.
You can mitigate that with some upfront choices. For example, use a blackberry and blackberry messaging as one device, which wouldn't be available on other devices?
Export it to markdown, and dump it on a github page or something. At least that way we can use space/PgUp etc to navigate.
Actually the feedback about not being able to use space / PgDn is good feedback for the Notion team. How do we relay feedback to them? :)
I think the notion folks should be well aware of the UI issues, since they're long standing. They simply don't care for people that don't navigate with an Apple (TM) touchpad.
anyways, don't repost as this one got traction (time of posting is a factor also re: google doc one) and the comment discussion is all here, don't need another version of same thing
The author, JK Rowling, is currently on the single biggest hate campaign I've seen a celebrity run against trans rights.
It's negatively affecting the connotations of being associated with the 'Potterverse,' and support for Potter these days is widely considered inconsiderate, especially in the ever growing queer community.
Simply using a name like this was enough to turn me off, and certainly I would not want any friends to have a similarly triggering experience, so I therefore can't recommend it's use, either.
While Potter actually used to be a portal of expression for these types of people, it is now associated with repression and ignorance.
It sucks that any time I see media related / referencing Potter I honestly am immediately disgusted, but this is clearly what Rowling wants. She has had many chances to step down and apologize to her fan base, but she insists on invalidating us.
I grew up with those books, they meant a lot to me, and actually produced a crisis of faith to me with regards to separating art from the artist.
Michael Jackson was, pretty definitely, a child molester. I listened to his music for years after until I finally decided I couldn't do it, as a survivor of sexual assault myself, it makes it difficult to be caught casually listening to him.
The Potter books are good, but there are a lot of other great books out there (and inspiration for names!) that wouldn't immediately turn off any and all potential trans customers like myself.
I will note that it could be amazingly positive PR for you guys if you chose to rename the app for this program, I know I myself would sent it to a few of my queer tech blogging friends.
Unfortunately, to even be a fan of Potter any more is to be a fan in spite of, or choosing to ignore Rowling's continuing, relentless campaign to invalidate us as people, and has drawn tangible battle lines between fan communities.
Do you have an idea for another name for it that will communicate the idea as well? Maybe you can activate your queer tech blogging friends so that we can come up with a new name? (and then I can resubmit under the new name, since Notion will change and kill this link once I change the name).
What else can be split up into pieces and you have to get all of them?
I'd love to just offer a little bit of help, brainstorm for a bit, and I think it's fantastic that you're aware of the issue and wanting to take the steps forward. Knowing is half the battle. ;)
I appreciate the response, regardless of anything - I know it might seem like an extreme response without context, but Potter truly has been an extremely hot button issue lately.
It was relevant and important enough to the author to contact me, and they are apparently interested in having this discussion. They didn't need to engage in this discussion, but they felt it important. Just because it's not important to you, doesn't mean it's not important to a lot of others here.
I would certainly avoid blanket statements like 'people are not interested in ___' - I'm not sure if you read the author's reply before yours, but I think what you clearly meant is that you don't care.
Which is your right, but please don't put thoughts or words in other people's mouths, especially when there is dissenting evidence of your statements only a comment above.
I'm glad you can feel it's not relevant. Unless you're trans, or a direct ally, you have the benefit of it not affecting you. Great.
But I'm not the only trans person on this forum. This shit matters to us - matters to our allies, including, evidently, the author of the software - and it's our right, and sometime our obligation, to speak up. Get over it. :P
You can feel free not to engage, which would have been preferred to your insinuation that nobody here wants to have that conversation - which is obviously and blantanly untrue, and born out of the privilege to not have it affect you.
The first point of my comment was to make you not feel like people don't care about your comment but indicate that this is just not the place for it, hence downvotes. You can take that as the positive message I tried to send... or not. The second part (that "I'm also not sure it's helpful..." part), I should just have left out, it was diving into the topic that I wanted to stay out of, and I suppose that's what most of your reply comes from. I guess the last subsentence of my comment was trying to steer it back, but I should just have left it at the first sentence.
I'll not reply further in this thread because I don't think it's constructive for the actual topic that this thread is about. If you want to talk to me and actually understand what I wrote rather than the invented meaning, feel free to use the contact info in my profile. I tried to use yours to explain, but there was none.
> Unless you're trans, or a direct ally
This is not a war. Please realize that the vast majority of us are on the same team.