Hehe right on point....glad I managed to take a screenshot :P

How does this happen....

The algorithm is to good

OpenSSH 8.2 is out. This release removes support for the ssh-rsa key algorithm. The better alternatives include:

1. RSA SHA-2 signature algorithms rsa-sha2-256/512. These algorithms have the advantage of using the same key type as "ssh-rsa" but use the safe SHA-2 hash algorithms (now used by default if the client and server support them).

2. The ssh-ed25519 signature algorithm.

3. ECDSA algorithms: ecdsa-sha2-nistp256/384/521.

In this release, support for FIDO/U2F hardware tokens. Also noteworthy, a future release of OpenSSH will enable UpdateHostKeys by default to allow the client to automatically migrate to better algorithms.

I am trying to "invent" secure client-side authentication where all data are stored in browser encrypted and only accessible with the correct password. My question is, what is your opinion about my idea. If you think it is not secure or there is possible backdoor, let me know.

// INPUT:
- test string (hidden, random, random length)
- password
- password again
// THEN:
- hash test string with sha-512
- encrypt test string with password
- save hash of test string
// AUTH:
- decrypt test string
- hash decrypted string with sha-512
- compare hashes
- create password hash sha-512 (and delete password from memory, so you cannot get it somehow - possible hole here because hash is reversible with brute force)

// DATA PROCESSING
- encrypt/decrypt with password hash as secret (AES-256)

Thanks!

EDIT: Maybe some salt for test string would be nice

Am I cool @SHA-256?

Something that irks me is the misinformation that the DOGE proof of work is less complex and more energy saving than the BTC proof of work.

BTC: SHA-256
DOGE: SCRYPT (SHA-256 + Some additional steps and higher memory consumption)

I tried hash for the first time yesterday at a friend's house.
...
SHA-256 was the best, tbh.

Crypto. I've seen some horrible RC4 thrown around and heard of 3DES also being used, but luckily didn't lay my eyes upon it.
Now to my current crypto adventure.
Rule no.1: Never roll your own crypto.
They said.
So let's encrypt a file for upload. OK, there doesn't seem to be a clear standard, but ya'know combine asymmetric cipher to crypt the key with a symmetric. Should be easy. Take RSA and whatnot from some libraries. But let's obfuscate it a bit so nobody can reuse it. - Until today I thought the crypto was alright, but then there was something off. On two layers there were added hashes, timestamps or length fields, which enlarges the data to encrypt. Now it doesn't add up any more: Through padding and hash verification RSA from OpenSSL throws an error, because the data is too long (about 240 bytes possible, but 264 pumped in). Probably the lib used just didn't notify, silently truncating stuff or resorting to other means. Still investigation needed. - but apart from that: why the fuck add own hash verification, with weak non-cryptographic hashes(!) if the chosen RSA variant already has that with SHA-256. Why this sick generation of key material with some md5 artistic stunts - is there no cryptographically safe random source on Windows? Why directly pump some structs (with no padding and magic numbers) into the file? Just so it's a bit more fucked up?
Thanks, that worked.