Nostr Web Client

AES is just the cypherstream generator, the password is hashed, usually, using something like scrypt or more often nowadays, argon or argon 2. also, instead of AES, a lower compute cost cipherstream generator is chacha20-poly1305. you need to have the implementation in javascript though, which inherently weakens these key expansion hash functions like argon.

i assume when it says "XOR" it means the password is just XORed with it? who has 32 character passwords to completely cover it? or do they just hash once? in actual fact, the most important part of the security is the password expansion hash function. you can actually just use XOR with that, there is not any extra security by using yet another hash function on top, it's just gonna be slower, so you could really just hash it many times with the fastest hash function you can use, blake2b is the fastest hash function i know of.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 3w ago

what i mean is, if you have a native binary argon2, just set some decent amount of hash grinding count and memory usage on it and that's plenty for securing it. the AES hash or chacha/poly hash is no better than what argon uses, which is, iirc, chacha12/poly1305.

anyhow, there is no reversing even a single hash, the point of these is to add some compute time to brute force it, so actually, if there is a strong cryptographically secure hash available in the javascript runtime, that can be used repeatedly on the nsec, starting with the password, and you can make it expand it by hashing the first 32 bytes to make the second and so on, until it uses several kilobytes, and define some number of times it does that again with the expanded hash. that's what scrypt and argon do, anyway. scrypt uses sha256

Reply to this note

Please Login to reply.

Discussion

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 3w ago

yeah, i was right. there is a native SHA256 available in web browsers. so you can just make it do either some thousands of hash on the hash of the hash of the password, or you can also make it generate a stream and then hash the stream (just concatenated hash , with the hash of the hash joined and do that until it uses up some kilobytes, and then repeat that, depending on how memory hard or long each brute force attempt would be done. since it is almost as fast as a binary native hash function you can make it pretty strong, and still normally have the user's nsec unlocked in a second or so. each attempt on the password will cost that much time so it reduces the opportunity of an attacker who may have temporary access or access only when you are on some wifi network or so.