
Horcrux Encrypted Messaging - ljlolel
https://www.notion.so/Horcrux-Encrypted-Messaging-78af0a3f326244ebb0aedff7c298953d
======
md_
A few points:

* 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...](https://threatpost.com/whatsapp-zero-day-exploited-in-targeted-spyware-attacks/144696/)), 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.

~~~
mindfulhack
Hyperbolic claims aside†, I think this is a practical way to dramatically
increase the security of OTP key transmission over networked communication.
It's not perfect, but it would make any attacker's job harder, right?

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.

~~~
md_
Right, you're spot on about the OTP. The pad is itself transmitted over the
same channel(s) as the message, so there's no value in using an OTP per se. I
think the author was just going for a way to split a message in a way that one
needs all parts of the split message (or key) to decrypt it.

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.

~~~
ljlolel
OTP is not sent over the same channel.

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).

~~~
md_
OTP is sent over _one_ of the two channels (or _m_ of _n_ ). The lint is that
the pad has effectively the same security as the message itself.

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.

~~~
ljlolel
>OTP is sent over one of the two channels (or m of n). The lint is that the
pad has effectively the same security as the message itself.

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.

~~~
maqp
" _We equally distrust all channels a bit_ "

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](https://ieeexplore.ieee.org/document/7122176)

and

[https://www.computer.org/csdl/magazine/co/2015/07/mco2015070...](https://www.computer.org/csdl/magazine/co/2015/07/mco2015070059/13rRUNvgyZk)

------
johnisgood
> The encryption can be broken in the future if the rival states become
> allies, or otherwise become willing to share data with each other.

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.

[1] [https://tsf.telegram.org/manuals/e2ee-
simple](https://tsf.telegram.org/manuals/e2ee-simple)

~~~
ljlolel
Horcruxes are just a layer of security. If you want to further encrypt (or do
more steganography) on the messages then it is not hard to add that too
depending on your threat model and paranoia level.

Horcruxes provide a unique solution to the problem of dragnets and increase
costs of hacking your device even for governments.

~~~
vii
The idea of layering security is very powerful, acknowledged in this "Network
Operations Division Cryptographic Requirements" document

[https://wikileaks.org/ciav7p1/cms/files/NOD%20Cryptographic%...](https://wikileaks.org/ciav7p1/cms/files/NOD%20Cryptographic%20Requirements%20v1.1%20TOP%20SECRET.pdf)

> 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.

~~~
ljlolel
All good points, agreed with all.

> 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.

------
tuxxy
This lacks a clear threat model and even overstates many problems it claims to
resolve (e.g. vulnerabilities in Signal, et al).

I'm not very certain what value this adds to the landscape. Is it possible the
developers can elaborate here?

~~~
ljlolel
I added a section on Threat Models as examples

------
slaymaker1907
An interesting idea, I was thinking why not use public key encryption instead
of transmitting keys in plain text, but it doesn’t really make sense to do so.
Breaking the public key encryption only requires the plain text or the public
key (assuming it can be cracked) so horcrux would not help.

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.

~~~
ljlolel
Yes a few people suggested that.

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.

------
natcombs
> This encryption is perfect secrecy

Sending your key in plaintext over a separate channel isn’t really perfect
secrecy but okay... it’s interesting, but laden with assumptions.

~~~
m3kw9
What do you mean plain text? It’s scrambled using the OTP then sent. Each sent
on a separate channel. The only way to crack is to intercept both. Or if the
random generator is weak and can be predicted.

~~~
natcombs
> What do you mean plain text?

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.

~~~
ljlolel
I used those words, but if you understand how OTP/XOR works, they're both kind
of OTP.

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?

~~~
hinkley
No, it doesn’t.

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.

------
mindfulhack
Just another thought, although IANAL: while it's probably OK to use the word
'horcrux' in casual discussion, for an actual product, even if non-profit, it
may be unfeasible to use that word because it's part of the Harry Potter IP.

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.

~~~
ljlolel
Yea some queer bloggers are going to help me find a better name too since we
don't want the association with what JKR is talking about these days

This doesn't help but XORcrux would also work maybe

------
josh2600
It’s a cool idea but I think it’s hard to imagine how a user would perform
this type of messaging transparently. For example, signal doesn’t support bots
today or really any kind of unofficial API access so the idea of increasing
the number of messengers I need to manually interact with to send a message
seems like a big UX burden.

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.

~~~
ljlolel
Let's be more creative here Josh :)

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.

~~~
maqp
From the documentation:

" _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.

~~~
ljlolel
What is TCB?

> 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.

~~~
maqp
" _Please chill out with the attacks_ "

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](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/](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.

~~~
ljlolel
I think you're still missing many points of this.

The idea of trust Signal no matter what is funny though.

~~~
maqp
There's other stuff protecting you when it comes to Signal: FOSS code,
professional audits, reproducible builds etc.

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).

------
vessenes
There is some magical thinking in this proposal as relates to key creation and
transmission — I do not think it’s as easy as the author proposes to get
enough entropy for a one-time pad from QR codes, for instance. A giant QR code
gives only 406 bytes, and the ones phones trade are usually smaller. Also, it
is easy to scan a QR code automatically by its nature.

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.

~~~
maqp
" _To split them in such a way that different nation-state actors will each
encounter significant expense is pretty brilliant._ "

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.

------
lucb1e
(Edit: while reading further this went from "overstated claims" to
"potentially big security issue", see the edit below.)

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.

~~~
ljlolel
> Proof of Concept Heh, that's funny, the 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.

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).

~~~
lucb1e
> 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.

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.

~~~
ljlolel
"by force" I mean force Signal to ship code to the end user to upload the
private keys so they can give it to the government, as described in the
doc....

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.

~~~
maqp
" _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_"

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.

~~~
ljlolel
That's why I wrote "commitment scheme" of which there are many and which
secure one you use doesn't really matter.

~~~
maqp
" _That 's why I wrote "commitment scheme" of which there are many and which
secure one you use doesn't really matter._"

Please see
[https://en.wikipedia.org/wiki/Commitment_scheme](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.

------
blindm
Is this a member of Notion.so staff? How is it possible that you can blog with
Notion?

~~~
ljlolel
Notion free personal version let's you publish links publicly (just not be
SEO). It's awesome! Way nicer than google docs.

~~~
blindm
Cool!

------
m3kw9
The problem is the UX and can be cracked if the receiver is lazy and always
have both channel close by for convenience

~~~
ljlolel
That's true. You could end up with bad Opsec and then accidentally download
both Signal and Telegram on the same device, reducing (but not eliminating)
security. Thanks I'll add this to vulnerabilities.

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?

------
senectus1
Obscurity isn't security, its just administrative overhead + additional points
of failure.

------
black_puppydog
Meta/side-track: notion is a _horrible_ publishing platform. I can see its use
as a wiki/documentation solution (although I disagree with many of the UI
choices they make and would never personally choose it) but none of these
points actually hold when I'm just _reading_ a published page.

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.

~~~
ljlolel
Originally I had it as a Google Doc. That got 0 votes on HN. This is my second
attempt. Super easy upgrade to Notion. I agree could be better, but further
raising the bar to publishing might mean I never do it :(.

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? :)

~~~
black_puppydog
FWIW, I don't think the google.com vs notion.so domain was the distinguishing
factor here. Whether or not a submission gets votes is a pretty random process
in any case.

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.

~~~
ljlolel
i'll put it up on my personal blog jperla.com/blog and then re-post it. Seems
like this got abruptly banned from the front page for some reason as it hit 50
upvotes...

~~~
ChrisArchitect
what, not banned, just not trending up....

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

------
lostgame
I know it may sound pedantic to the uninitiated, but the name immediately
triggered me / made me uninterested - as it would to any trans person I know -
because it's using a name from Harry Potter. Something we have a hard time
just 'getting over' or 'ignoring', and certainly shouldn't be asked to.

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.

~~~
ljlolel
I hear you and I agree I'd rather not be triggering that. I tried asking a few
people and trying to come up with a different name and people didn't
understand it as easily. Horcruxes give you an idea of what it's doing
basically just from the name (you could even imagine a cryptographer inventing
this system just from hearing the name it is so obvious).

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?

~~~
lostgame
If this is a conversation you're willing to have (and kudos for that, and I'm
glad you're previously aware of the issue), it's something I'd love to help
discuss - I'm a software dev as well, so I understand how the concept of the
functionality is well suited for the metaphor - however, I'm _positive_
another solution could be found. :) And, again, it'll of course be great PR
and could draw some positive attention to the service. I've made a throwaway
email - psyche at theoic dot me - as obviously the nature of HN makes it
difficult to communicate here.

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.

~~~
ljlolel
email sent

~~~
lostgame
Oh, fantastic. I'll be sure to get back to you within an hour or two while
it's still fresh in our minds. :)

