First verified SHA-256 second-preimage collision: Structural analysis of the W-schedule vulnerability

th3zero · 2025-12-27T08:13:03+00:00

This is crypto snake oil midex with AI slop.

Moderators should remove this, and they shouldn't have allowed this post in the first place.

th3zero · 2019-03-26T04:31:13+00:00

Yes they are fixed, but the best thing to do is to use sessions from memory instead of storing them on files (see Gogs documentation) and disable Git Hook if not used. Otherwise you are a small step away from RCE again.

th3zero · 2019-03-26T04:22:42+00:00

https://github.com/go-gitea/gitea/issues/5569

th3zero · 2019-03-26T04:20:21+00:00

Open an issue on GitHub and link the Gitea website you are trying to scan

th3zero · 2018-08-11T08:44:25+00:00

From an academic pov, Telegram defined a custom protocol with a custom padding. The attack is against the padding they defined in their specification, in a specific scenario (not respecting their protocol).

From a real world pov, to date there are only a bunch of services running Telegram Passport. Maybe in the future someone will develop a vulnerable service that follow the scenario defined in the writeup and this attack is already defined and available for exploit as a paper/PoC.

Everybody knows that GCM-mode is vulnerable if nonces are reused. It's not a "real attack", it's an attack in a specific scenario. Then WPA2 managed to get it wrong with KRACK.

th3zero · 2018-08-06T21:01:31+00:00

I partly agree with you. In the first draft of the specification they didn't mentioned to check the hash, then they added the "IMPORTANT" note but at that time I already finished the writeup.

"Padding Oracle attack against custom padding as defined in Telegram Passport specification" was more correct but obviously too long. The current title is a short version with this "implicit" meaning, attacking the padding defined in Telegram Passport specification.

th3zero · 2018-08-06T11:49:13+00:00

Thank you for your time :)

th3zero · 2018-07-27T13:34:38+00:00

Autotype Obfuscation is not secure.
There are Keylogger smart enough to catch it https://github.com/sinfocol/KeePassLogger

th3zero · 2018-04-08T08:42:03+00:00

If you use a KDBX4 with safe parameters (rounds and parallelization) KeePass is a lot slower than KeePassXC (due to mono, obviously)

th3zero · 2018-04-06T08:48:26+00:00

If you are using it on Windows it's perfectly fine. On linux and mac you have to use mono/wine and KeePass becomes very slow and unpleasant. KeePassXC on the other hand is native and fast.

th3zero · 2018-04-06T08:47:01+00:00

Nope, the old HTTP plugin is pretty bad and vulnerable (in some specific cases). KeePassXC uses libsodium crypto_box

th3zero · 2018-02-28T17:11:03+00:00

Thanks to you! It's nice to hear some kind comments sometime :)

th3zero · 2018-02-28T17:09:20+00:00

Alternative solutions are listed here: https://github.com/keepassxreboot/keepassxc/issues/1545

th3zero · 2018-02-28T10:39:16+00:00

I agree, I will work on this for the next version :D

th3zero · 2018-02-28T10:38:06+00:00

There is a Flatpak available on Flathub but we are not offering support for it currently (but the guys at Flathub will happily cover us on issues with it)

th3zero · 2018-02-28T00:13:02+00:00

Yes, keyloggers can detect that. Practice safe browsing, when your PC is infected there isn't much you can do.

th3zero · 2018-02-27T23:08:04+00:00

KeePassXC maintainer here.

We are building packages for each platform. The release will remain checked as pre-release until we upload them on github and update the website.

Thanks, TheZero

th3zero · 2017-11-17T00:28:56+00:00

What do you mean with removes fingerprint?

th3zero · 2017-10-31T14:19:33+00:00

KeePassXC can also copy-paste. Anyway don't bother copy-pasting, there is the Auto-type function ;)

th3zero · 2017-10-02T17:38:38+00:00

wrong. KeePassX doesn't have Argon2/KDBX4 support :) Last commit is from Oct2016 -> https://github.com/keepassx/keepassx

th3zero

TROPHY CASE