Oddbean new post about | logout
 Thanks for fixing it so quickly. 
its an annoying part of nostr, but I cant login to most other web apps because they crash my computer with decryption requests 
 I feel ya 
 doing a ECDH derivation seems like a low hanging fruit for native code inside extensions though, has anyone considered this? or even pushing out the entire thing to native code?

why is it, anyway, that javascript engines still don't have a native sha256 hash function? or an AES (rijndael) hash function? this seems like a really simple problem yet because they still treat browsers as dumb presentation engines while constantly overloading it with GUI logic nobody bothered to provide a fast path for this 
 It's less related to this than that 1. some people like to approve every request 2. some signers don't properly implement "approve always", and 3. nip 46 signers are remote and it can be hard to deal with the latency on both client and signer side 
 My complaint is that almost all apps presume the user will always sign everything, and they usually crash or are buggy when the user does not give the app access to everything 
 this is because most front end app devs have ZERO understanding of cryptography, not even the distinction between actual encryption and signing

the media has not helped this at all, by calling signatures "asymmetric encryption" bullshit. the encryption requires you to do a little computation but signatures are not encryption they are authentication, really big difference 
 That's a corollary for sure 
 signing is a more expensive operation by like factor of 4 or more than deriving a decryption secret and making a cipher block stream

not wanting to see messages that have been encrypted to you is quite retarded, i mean, i don't even know how to express how retarded it is to not want to spend the cheapest amount of crypto compute on seeing what people send you

signing stuff, that's a different issue because implicitly you are also sending that out, there should be a clear delineation between actions that are secret and actions that become public or at least move to private across the connection

i admonish you guys to do some more study on cryptography and signals intelligence, please 
 look, put it this way, if someone has already breached your system, they can see all yoru encrypted messages and you are whining because the signer asks you to derive a shared secret???? 
 sorry but this is beyond retarded

performing an action that has zero effect outside your computer should not need any permission  
 deriving shared secrets out of a message from your nsec should not require permission at all. at all.

if someone is already inside your browser or computer that's a whole separate problem to signing stuff and sending it out, i really hope you get the distinction 
 Shared secrets gives you something durable that clients can quietly exfiltrate to spy on users later. Not a good idea IMO, but others disagree 
 if they can get at the shared secret they probably can get at the nsec, how far separated are those two things? 
 hint: you can't derive the shared secret without the secret. it's one step. one.

security of the nsec and derived secrets is almost unity

the actual data it decrypts, that's your computer it's on, it's not being SENT ANYIWHERE ffs guys, please, get some fucking realism in your threat models

if you can't trust the computer, why you use the computer?

oh yeah, because it isn't a leaky sponge like you are trying to make it out to be, yet somehow it is secure in other ways

no, fuck you. decrypted messages are adjacent to the fucking nsec