atoponce

The source code is open source. Please point to the lines of code where the backdoor exists.

You can't get right/left balance metrics with a single pod. Several old metrics are now applied to both feet, so you can compare right to left. EG, if you notice your right leg spring stiffness increasing, but not your left, you know the right leg is getting stronger, which might prompt you to increase the strength in your left leg. That sort of stuff.

But yeah. The goal is to get existing Next Gen Stryd customers to purchase a second Next Gen pod as well as a membership. But for older Stryd pod owners like myself, $250 for two Next Gen pods and a membership is a pretty sweet deal.

Biometrics aren't the second factor when using WebAuthn, the hardware security key is. But anyone with access to the security key can use the second factor. Biometrics would tie the key to you preventing them from being used by others. The best we have right now for unlocking the security key are PINs, AFAIK.

2FA is rife with problems. FIDO2/WebAuthn isn't tied to biometrics and can be inconvenient. TOTP can get out of sync and can be phished. Email can also be phished. Voice and SMS are vulnerable to SIM swaps. Now we're seeing that passkeys are horribly opaque without proper management and at risk of getting lost.

Le sigh.

I was very disappointed in that Kickstarter. Yubikey ran a 54% off discount May 4th last year and not knowing when I would get my v2 SoloKeys, I purchased two. I had them within the week and have since integrated them into all my accounts.

I debated backing out of the Kickstarter as the Yubikeys were working so well for me, but decided to stick with it and see what the SoloKey experience would be like. Yeah, disappointing. I ordered USB-A and USB-C keys. The USB-A key doesn't make a good connection with the USB port. It needs to be carefully held to register with the OS, otherwise it doesn't get power.

Very structured with lots of very visible patterns in your JavaScript demo site. Some screenshots: https://imgur.com/a/2zQh4bA

His slides to his talk have been posted. I'll like the video to the talk when it's up.

https://tobtu.com/blackhat2022/

It's not my repo, so I don't know. I don't see any specific criteria, so if you see a project missing that should be added, send a pull request.

https://articles.59.ca/doku.php?id=pgpfan:tpp

Some rebuttals to that critique outline that the author doesn't fully understand the arguments Thomas Ptacek laid out, and may have a simplified understanding of PGP:

https://lobste.rs/s/tyaze3 and https://redd.it/negkdl

I see. You're defining resynchronization of the register during decryption as recovery, not parity checks for recovering corrupted data. Fair enough.

What exactly is an OpenPGP recovery property? Can you point it out in the RFC?

The patents in question are https://patents.google.com/patent/US7949129B2/ and https://patents.google.com/patent/US8321675B2/

On the other hand, virtualization _already_ lets you run whatever arm64 BSD, Linux, or Windows that you want. The trackpad and everything else will work flawlessly thanks to guest additions.

The OpenBSD kernel doesn't support loadable kernel modules, so virtual machine guest additions are not an option for a virtualized OpenBSD.

No problem. I dig the project. Very cool.

I would recommend the default be 6 words, and let people choose down to 4, but not lower. At last that way, users know what a "secure default" looks like. Granted, it breaks the four-word "correct horse battery staple" XKCD format, but Randall was in some error with that comic anyway.

Further, sufficiently seeded cryptographically secure RNGs are indistinguishable from true random white noise, so from a practical perspective, there is no point to require "true random".

I audit web-based password generators as a hobby, and this one does well.

What it does well on:

The source code is open source licensed. Passwords are generated in the client, not on the server. The generator is random. The generator is cryptographically secure. The generator is unbiased. Mobile devices are supported. There are no JavaScript trackers loaded on the page. The site is not calling out to external resources without SRI.

Unfortunately, by only choosing 4 random words, the security margin of the passphrase is 52 bits (13 bits per word). This is practical for a hobbyist password cracker to exhaust in an offline attack. The security would be better if 6 random words were chosen instead.

Audit: https://docs.google.com/spreadsheets/d/1ucaqJ4U3X3nNEbAAa06i...

Niceware ships 65,536 unique words. 3 words chosen randomly is 1 "password" of 281,474,976,710,656 possibilities.

https://diracdeltas.github.io/niceware

If that password was hashed with a single pass of vanilla MD5, the Jeremi Gonsey's cluster of 8 Nvidia GTX 1080i GPUs [2] would be running at 307,200,000,000 hashes per second.

https://gist.github.com/epixoip/ace60d09981be09544fdd3500505...

In order to exhaust half of the keyspace, so odds would be in the favor of the password cracker finding the original hash, they would need to search only 140,737,488,355,328 hashes.

At 307.2 gigahashes per second, this would take approximately 458 seconds, or just under 8 hours using the Niceware list.

However, jumping to 4 random words grows that time by a factor of 65,536, which means reaching 50% exhaustion would take approximately 1 full year. Moving to 5 randomly generated Niceware words, and it's impractical to attempt cracking the MD5 hash.

Cherry-picking 3 words is a little dishonest for the discussion surrounding password security. The right "best answer" for password generation is to use a password manager, no argument there. And I don't know of any password generators that generate passphrases by default, Niceware, Diceware, or otherwise.

But if a user wants a passphrase instead, I don't know of a security expert who would recommend 3 words.

From my testing with Python's base64, hashlib, and passlib.hash modules, SHA-256 prehashing and base64 encoding is only approximately one one-hundredths the total execution time of bcrypt_sha256 for a 4 KB "password". This is why slurping in the password during the initial state isn't noticeably adding to the overall execution time of password prehashing with bcrypt, and it is analogous to why PBKDF2, scrypt, and Argon2 all show constant time in execution regardless of password length- slurping in the password during initialization is a fraction of the execution time.

The sha256/512crypt algorithms, as well as md5crypt, hash the input based on each character in the password. This is why the execution time increases. bcrypt does not do this.

bcrypt is constant-time, not because it truncates at 72 characters. It's constant-time, because it slurps the password and salt once into the state (initial setup), then spends the rest of the time manipulating that state based on the cost (expand key).

Yes, you could pre-hash with sha256crypt or sha512crypt, and that completely works around the password-length performance issue. You pre-hash with bcrypt to get around a maximum length restriction, not to get around a performance bottleneck.

Seems like this can radically narrow the focus of a dictionary attack.

It's leaking information, and we don't like this, but it's not fatal. 96% will have passwords less than 16 characters (see https://blog.cynosureprime.com/2017/08/320-million-hashes-ex...). This is within the first "step" in the sha512crypt hashing process, and longer passwords may have enough entropy, so learning their length is not providing any practical advantage in cracking the password, should the database be compromised.

The larger concern is CPU load. There are load jumps between 1-15, and 16-23 characters, and 24-80, etc. Even though 96% of users will fall in the 1-16 range, if you put a minimum length requirement of perhaps 12 characters, you may see that you need to decrease your sha512crypt cost to handle your tested load, because more of your users are passing 16 characters in length (yay) than normal (although most will like do exactly 12 characters).

Does that make sense?

Isn't the reason this is true that bcrypt just truncates the input at 72 characters? And if that's correct, aren't there basically a few options, any of which basically invalidate the argument?

Let's run a scenario to show by bcrypt from strictly a CPU load perspective is better than sha256/512crypt.

1. Enforce a password length limit. Fixes the unbounded growth of the shacrypt CPU time while simultaneously ensuring bcrypt is not ignoring input.

Assume that I know how many authentications per second are happening on my busy authentication server, and I can reliably guarantee 0.25 seconds per request without creating an outage. On my hardware, that's a bcrypt cost of 12. If I pre-hash every password with SHA-256, then base64 encode the hash, and send that to bcrypt, I can guarantee every user any arbitrary length of password, and know that it will not take more than 0.25 seconds.

For sha256crypt, a cost of 250,000 rounds is similar in performance for an 8-character password, executing in about 0.250158 seconds. However, and 36-character Diceware passphrase takes about 0.353884 seconds, and grows from there (70 characters at 0.503353 seconds, etc). Obviously, I can't allow everyone to have 36-character Diceware passphrases with a sha256crypt cost of 250,000 rounds. It would create load problems on my hardware.

I have three options that I see ahead of me if I wanted to stick with sha256crypt:

1. I could decrease the sha256crypt rounds, so those who want longer passwords won't create a CPU outage due to load.

2. Enforce maximum password length limit of 35 characters, to prevent the execution time from taking too long.

3. Make some exceptions in the code, so those with 1-10 characters have a higher sha256crypt cost than those with 11-24, which is still higher than those with 25-36, etc.

If I just stick bcrypt on the server with a cost of 12, I don't have handle these exceptions.

2. Pre-hash the input to bcrypt by passing it through SHA512. Makes bcrypt now grow in the exact same way as shacrypt.

No it doesn't. In the graphs on my post, the bcrypt timings are based on https://passlib.readthedocs.io/en/stable/lib/passlib.hash.bc.... bcrypt only grows when the cost is increased. Its execution times are in no way affected by password length.

3. Don't enforce a password limit, but truncate the password. Fixes the CPU time.

This is a bad design, and falls back to the security vulnerabilities of DES-Crypt and LM hashes.

Passing 4096 bytes to bcrypt is the same as passing 72 bytes to bcrypt because it ignores the last 4024 bytes right?

Unless you bcrypt(base64(sha-256(password))), which is a common approach.

How is the timing here relevant to attacking shacrypt?

By observing the time on the CPU it takes for the password hashing algorithm to complete, you can learn the length of the password. It's a side-channel timing attack.

But, as mentioned in the post, it's a negligible concern. In the case of md5crypt, the algorithm processes the password in 16-byte blocks. For standard 8-bit ASCII, this is 1-16 characters. Knowing that the bulk of user passwords are 7-10 characters, we aren't really learning anything anyway. We're not assuming here the adversary has the salted password hash. We're strictly talking about observing running processes on the machine.

The run time does not depend on the length of any secrets here.

For md5crypt, sha256crypt, and sha512crypt, it does. sha256crypt will hash a 10 character random password faster than a 35-character Diceware passphrase. That's the whole point of the post.

Article opens by claiming "DES-Crypt has a core flaw in that, not only was the algorithm reversible ..."

That's not true in any meaningful sense

That's exactly right, and when I published the article, I recognized that I needed to change it, but didn't get to it. I've fixed it. Thanks.

and points to the fact that the author hasn't any clue what they're talking about.

Ouch.

The MOTD I got in my IRC client:

https://ae7.st/pb/?6cb6e86dc5d27158#SKb8x+tKyazabJWuFaGjURqe...

Whelp, goodbye Slack, hello Mattermost.

all existing HWRNG are relatively low bandwidth

The Intel on-die DRNG generator has a cited bandwidth of about 3 Gbps [1]. On my Raspberry Pi 3, it has an on-die generator via BCM-2835. Single threaded testing with dd(1) shows about 1.5 Mbps bandwidth.

Off-chip, using $25 RTL-SDR dongles, you can get about 2.8 Mbps of bandwidth. In fact, if you look at the Wikipedia article comparing HWRNGs [2], you can see that there are a lot of implementations with suprisingly high bandwidth. Some you'll empty your wallet with, others not so much.

The point is, there are plenty of HWRNGs out there with high bandwidth. Whether or not you trust them though, is a completely different matter.

1. https://software.intel.com/en-us/articles/intel-digital-rand...

2. https://en.wikipedia.org/wiki/Comparison_of_hardware_random_...

RLY? How on earth can a read from /dev/random be non blocking if it does not have sufficient entropy?

In short, to answer your question, I am not aware of any /dev/random that will not block if not sufficiently seeded with enough entropy. Linux is the only kernel where /dev/random always blocks when the input pool entropy estimate is low. This is highly criticized in most security communities.

Mac OS X and iOS have implemented the FreeBSD CSPRNG, of which /dev/random is a symlink to /dev/urandom. The CSPRNG blocks on boot until it's sufficiently seeded with hardware timing events. Once seeded, it never blocks again.

On NetBSD, /dev/random sometimes blocks, although not as notoriously as Linux. However, it will fully block on boot until sufficiently seeded, after which it no longer blocks.

OpenBSD also provides no functional difference between /dev/random and /dev/urandom. Both will block until sufficiently seeded.

As far as I know, on every Unix-like operating system, data is saved from the generator to disk on shutdown, and on boot, that data is read into the CSPRNG as an unpredictable seed. With every GNU/Linux operating system I can think of, this happens as part of the install, so on first boot, the kernel is already sufficiently seeded with random data.

On FreeBSD, this seed is saved to "/var/db/entropy-file". On GNU/Linux, either "/var/lib/systemd/random-seed" or "/var/lib/urandom/random-seed" depending on whether or not you're using systemd. I'm not sure of NetBSD saves a seed to disk or not, as it's been many years since I've last run NetBSD seriously.

This is really cool. The fact that I can, basically, carry around a TRNG in my pocket is like, the ultimate nerd. Other than reseeding /dev/urandom, I don't really have any personal need for it, but the discussions that can be generated from it could be very interesting.

This is also a concern of mine. What will this mean for rooting devices? Will it still be root, or will it be "root" as it an iOS jailbreak?

The only SipHash security you get is seed hiding. Once you got it, it's insecure.

Isn't that the case for every cryptographic primitive? I mean, that's sort of the point of private keys, yes? Once you have the key, you can decrypt AES ciphertext, create signatures with RSA, and forge valid MAC tags.

Not sure what point you're making here.