pull down to refresh
0 sats \ 7 replies \ @om 16 Dec 2023 \ parent \ on: [important] foreign asset control compliance meta
OK I will stop shilling cashu (and switch to shilling near-zero-fee Liquid clones) if you explain this to me:
I suspect you're thinking of signatures: indeed, signing random shit with your private key just like that isn't a good idea. But suppose you publish a Nostr pubkey and I encrypt a DM with it (no signatures). How is this unsecure? Aren't gpg users always doing gpg --encrypt --recipient anyway?
But suppose you publish a Nostr pubkey and I encrypt a DM with it (no signatures). How is this unsecure?
I'm not familiar with what cryptography nostr uses here.
But in general it's not a good idea to encrypt data with just any pubkey. It could (doesn't have to) be insecure in a sense of your DM might be decipherable for 3rd parties. It can't be insecure in a sense of threatening the secret key of the recipient, of course.
I'm not familiar with what cryptography Nostr uses here. But like @ekzyis mentioned: there are famous examples with RSA where weaknesses emerge when using the same key for encryptions and signatures.
reply
I'm not familiar with what cryptography Nostr uses here
We're currently trying to move away from NIP04 which uses symmetric encryption with AES-256-CBC (absolute trash compared to industry standard) to NIP44. NIP44 just got audited.
But like @ekzyis mentioned: there are famous examples with RSA where weaknesses emerge when using the same key for encryptions and signatures.
Thanks :)
if you explain this to me:That's not how encryption or secure encryption schemes work. You can't just use any pubkey and think, you can now encrypt anything with it and still pretend like it's secure. You just rolled your own crypto.
Have you asked yourself how encryption schemes are defined?
Since according to my understanding, encryption schemes always include a definition how the keys MUST be generated - even only idealistic ones that are only useful for theory, since they just say that they key must be random.
I mean: Do you really think I can use a RSA key in bitcoin which uses ECC?
How is this unsecure? Aren't gpg users always doing gpg --encrypt --recipient anyway?
I recommend looking up how PGP actually works.
I suspect you're thinking of signatures: indeed, signing random shit with your private key just like that isn't a good idea.
Nice assumption, lol, but I agree that this wouldn't be a good idea.
So please do some research before you try to shill anything and stop wasting our time.
It's also not too late to delete your comments and change your nym from @om to something else since I will remember your nym, lol
reply
I mean: Do you really think I can use a RSA key in bitcoin which uses ECC?
Who said anything about RSA?
I recommend looking up how PGP actually works.
This document is so old is doesn't have ECC. But gpg does in fact support ECC.
It's also not too late to delete your comments and change your nym from @om to something else since I will remember your nym, lol
Apparently in your fantasies you have won some cake but I'm still in the dark as to what the attacker is supposed to attack, exactly.
reply
The whole hierarchical deterministic wallet thing, as well as lnurl-auth, are based on the idea that PBKDF is random enough. The only thing that is actually random is the seed.
You have claimed insecurity but I still don't get who's the attacker and what information the attacker learns that he shouldn't have.
reply
random != random
reply
isnan(random) is True
reply