beefhash

For non-simulation purposes, however, using a fast-key-erasure[2] ChaCha20 or AES-256-CTR RNG has served me well enough, and doesn't leave me worrying if maybe someone could abuse the RNG for whatever purposes (e.g. cheating in a game by using RNG manipulation).

[1] https://www.pcg-random.org/

[2] https://blog.cr.yp.to/20170723-random.html

It is now possible[1] to perform chosen-prefix attacks against the SHA-1 algorithm for less than USD$50K. For this reason, we will be disabling the "ssh-rsa" public key signature algorithm by default in a near-future release.

This only happens via Tor and oft-abused VPN providers. "Showing ID" has two benefits:

1. It helps mitigate a lot of unsophisticated spam attacks, taking off server load and annoyance off users.

2. It helps to some extent with mitigating criminal affairs because any potential criminal that falls in the gap between "doesn't realize IP addresses may leak location information" and "knows how to use compromised hosts as proxy" can be picked off by the authorities once they're noticed.

Anonymity is gone and it's not coming back. We have to adapt and we don't get a choice. At least there's some minor upsides to it.

> An example of a hash function is SHA1, which is used in Git. It maps arbitrary-sized inputs to 160-bit outputs (which can be represented as 40 hexadecimal characters). We can try out the SHA1 hash on an input using the sha1sum command:

Can we please stop presenting SHA1 as a valid choice for a hash function anytime now? Especially in a security context? This passage is probably just a holdover from the 2008 version of this page, but it's still frustrating to see.

"A few programs exit with the following non-portable error codes. Do not use them."

[1] https://man.openbsd.org/sysexits

For tagging, the formatting would need to be redone to be mdoc, which breaks both the OSes mentioned above and would be an immensely arduous task at this point. Probably not going to happen.

Note GNU and and the Linux man-pages project are mostly outliers; everyone else that lives in BSD/illumos land has long since moved on to mdoc since like the 80s. See also https://www.usenix.org/system/files/login/articles/141-dzons...

Good friendships have been formed over this approach though.

1. Applying a censor to voice depending on server/user DM configuration. I know they've got some kind of OCR that tries to identify and block offensive words contained in images, such as the N word, when people are not friends and at least one side hasn't changed the “safe direct messaging” option down to “I live on the edge”. 2. Store records at least temporarily for law enforcement.

And the obvious other things are keeping for post-processing and derive user interests for advertising, or batching and forwarding the information to intelligence agencies.

It's hard to tell, realy.

As far as I can tell, BLAKE2 has effectively all the properties BLAKE3 has (arbitrary output length, keyed hash mode), so the upgrade for communications boils down to negotiating/determining which of the two hash functions to use over the wire (with all the downsides that come with agility of cryptographic primitives); for stored hashes, they have to be recomputed and replaced (or you could store a flag is BLAKE2/is BLAKE3 and update them as you touch hashes, kind of similar to how password hashes are swapped at login time).

Note that BLAKE3 existing doesn't break BLAKE2. It's perfectly fine to just keep trucking BLAKE2, it's just that BLAKE3 has better performance characteristics that make it very attractive.

While programming, just try to think of a scenario where having a mapping between some kind of arbitrary data (and maybe a key) and a fixed-size, uniformly random-looking output could be useful. Opportunities to sprinkle some hashes on things come up quite often when you look for them.

I don't think I'd enjoy a GNU userland/glibc/Linux monoculture, quite honestly. I'm glad POSIX exists to have a slightly less moving target.

That would also bring about an abrupt end of license wars of permissive vs. copyleft, I suppose.

Yeah, I didn't realize that. Tried to edit it in, but too late.

> Also the library lives on the server side ; not client ; and given the license is not AGPL there is no need to state that they're using it either.

And I didn't notice that. I thought it was JavaScript, but it was Go all along. Doubly my bad.

> (Edit: original comment was accusing me of copyright infringement for some reason)

I was (wrongly) assuming webauthn.io was in violation of the license of the library because I thought it was a client-side library.

EDIT: Disregard the rest of what I wrote here previously, I didn't realize it was Duo Labs's own website.

The web is as much of a remote code execution vehicle as it is an application platform that could theoretically do a lot of things without the remote code execution in the form of wasm/JavaScript. TLS solves the issue of people eavesdropping passively and MITM actively to do real-world harm by stealing credentials or injecting malware: It was a solution to an actual problem. Don't get me wrong, I am very much advocating for requiring TLS EV certificates if you serve JavaScript or WebAssembly once we've finished purging the plaintext web. It's a necessary evil to get more accountability for code and subsequently ease prosecution for hosting and distributing malware.

People downloading and executing other people's code is also a problem in need of a solution because of the very much non-trivial risk of malware these days. App stores have worked on mobile (at least it's improved the mobile threat landscape compared to traditional desktop computing). The idea of an app store can be made to work for desktop computers as well to reap the same security benefits of having a central, reviewing gatekeeper that is subsidized by everyone publishing there to pay a cost.

The proper solution would be to have mobile-like sandboxing capabilities on Windows, macOS and Linux, but that's still far. Mandatory code signing with personal identification is just a stopgap measure.

> A paywall harms free software developers who can't afford hundreds of dollars a year for certificates, which is not a problem for me, but would be for many folks.

I don't deny that this is a problem for many folks. But this assumes (executable) free software is desirable. It isn't. End-user software should be must be made at a loss (time) or for profit. This just makes the loss much more economically explicit. In the long run, this could give back value to software in the perception of users, which I consider to be a good thing.

I understand that you're in a risky line of “business” with emulation, where one wrong step can get you some lovely letters from lawyers. However, for the sake of argument: Is there any reason you couldn't get someone else to lend you their name so that they act under their real name for you? Surely that'd be an option for risk-averse people.

> In my own case, this has effectively prevented me from releasing compiled binaries of my own software going forward. If code signing is a requirement to distribute free software, then we need a Let’s Encrypt-style alternative for code signing—yesterday.

The whole point of a code signing requirement is to add a paywall so that only two kinds of people will have access to it: Bad actors sophisticated enough to steal a code signing certificate from someone who has purchased them.

It's a net gain for security. Software freedom, considering increasingly prevalent SaaS and closed-source apps on mobile devices, is already lost. So if we've already lost software freedom—as far as I can tell, more or less irrevocably—then we might as well at least reap the security benefit for the common person while we're there.

(They were done away with in RFC 7990, see section 7.3.)