Hacker News Reader

> Matthew Green was _insistent_ about making an altcoin

"Let me reiterate, I would 10,000x rather have put Zerocash in Bitcoin." - https://twitter.com/matthew_d_green/status/78154154453702656...

> He was especially concerned about difficulties monetizing any other path.

"Rewards doesn't even start the discussion. I'd have done it for free just to see it used." - https://twitter.com/matthew_d_green/status/78153489377171865...

admittedly he does bring up monetization: "And even when you got the code, nobody ever answered the problem of how you pay miners and devs." https://twitter.com/matthew_d_green/status/78154634460341043...

>sidechain right here.

"Last I checked - a few months back - it was just a bunch of ideas. No code on main." "And more importantly, no schedule on when it was going to go live. You can't build something that doesn't exist." - https://twitter.com/matthew_d_green/status/78154605479791821...

"A cynical part of me came to think the whole thing was just a put-on designed to squash competing coins." - https://twitter.com/matthew_d_green/status/78154720002742681...

OrpheanBeholderon Zcash begins

I went and dug up where I had read Green talk about this and it turns out it was in a conversation with you.

It seems you and him disagree, he says ZCash couldn't/wouldn't have happened in Bitcoin and you say it could.

Is your blog post about this still coming?

https://twitter.com/matthew_d_green/status/78153309118155571... https://twitter.com/matthew_d_green/status/78154154453702656... https://twitter.com/matthew_d_green/status/78154374789720064... https://twitter.com/matthew_d_green/status/78153489377171865... https://twitter.com/matthew_d_green/status/78154782708016742...

OrpheanBeholderon Zcash begins

Monero wasn't developed by a group of highly respected cryptographers and the privacy it offers is plausible deniability not zero knowledge.

OrpheanBeholderon Zcash begins

> Is this the one that forked off BitCoin due to differences centered around how it didn't make its investors/founders enough money

You must be thinking of something else. Matthew Green has said he would have much rather got this implemented in BitCoin.

ZCash forked off of BitCoin because BitCoin core wouldn't accept it. The proposed solution was a "side chain" to BitCoin. Side chains have been being talked about since around 2009, and that's all that is happened: talking. There is no code and no agreement on how they should work.

The fork happened when it became apparent that this would never make it into Bitcoin in any form.

OrpheanBeholderon Zcash begins

According to Matthew Green, they tried for years to get this (or one of the earlier versions) into Bitcoin and Bitcoin weren't having it. Their options were to make an entirely new coin, with the problems you point out, or to let the crypto they had developed die.

OrpheanBeholderon A Study of Tor Users and Wikipedians

> (a) Previously unknown TOR endpoints get found out because they invariably are the source of vandalism and/or spam.

The English Wikipedia uses the MediaWiki TorBlock extension to automatically block Tor exits from editing, it has since June 2008, and before then they were mostly all automatically blocked by various bots so I don't understand how vandalism would be happening from them. Also, the Tor Project publishes a DNSBL and makes relays with the exit flag available through the ONIONOO API (which TorBlock uses). There are no "unknown endpoints", they are all publicly known.

> I have never seen a good edit from a TOR endpoint. Ever.

This is likely true since they are all automatically blocked before they can edit.

> (c) I have never seen accounts created via TOR or that edited through TOR that weren't demonstrably block evasion, vandalism or (most often) spamming.

You can't create accounts via Tor or edit while logged in via Tor -- not even Administrators can (although I think you can get a special exemption by jumping through enough hoops).

OrpheanBeholderon OpenSSL Security Advisory - 26 Sep 2016

Okay, let's have a sensible conversation about your completely idle suggestion to create a new library in some other language, that would have to maintain compatibility with the OpenSSL API otherwise no one will use it, or rewrite everything that currently uses OpenSSL.

To me your "LibreSSL is no such thing" came across as dismissing the efforts of LibreSSL, even though it's not vunerable to this latest one, because it doesn't use Erlang.

OrpheanBeholderon OpenSSL Security Advisory - 26 Sep 2016

Are you volunteering? Good luck and be sure not to repeat the various vulnerabilities that weren't related to memory safety.

OrpheanBeholderon OpenSSL Security Advisory

No one is claiming that LibreSSL has fixed all the OpenSSL bugs, the parent certainly didn't. LibreSSL has historically been vulnerable to less of the bugs than OpenSSL and, for a long time, none of the sev:high bugs.

OrpheanBeholderon Roughtime: a protocol for secure, auditable time synchronisation

Some TLS implementations return a randomised date for the handshake anyway, which is why constraints works the way it does. TLS 1.3 killing it is just gravy.

If you're worried about a caching proxy you can set the constraint to a URL that returns something dynamic. Although it would be interesting to see what % of the top TLS-enabled webservers don't return something recent for HEAD / HTTP/1.1

OrpheanBeholderon Roughtime: a protocol for secure, auditable time synchronisation

> There have been efforts to augment NTP with authentication, but they still assume a world where each client trusts one or more time servers absolutely.

OpenNTPD has "constraints" where it makes HTTP requests (using TLS) to webservers and checks that the time provided by the NTP server is within a certain threshold of the time returned in the HTTP Date header.

Much simpler and doesn't require dedicated servers.

OrpheanBeholderon OpenBSD 6.0: why and how

ajacoutot@ and jasper@ work for m:tier.

OrpheanBeholderon Is Apple's Cloud Key Vault a Crypto Backdoor?

However, contrary to most articles titled with a question, this article is answering the question rather than posing it.

OrpheanBeholderon OpenBSD binpatches and package updates

The OpenBSD project doesn't have the resources to provide this so m:tier employs a couple of OpenBSD developers to provide this option for people who want it. Not sure what is embarrassing about this.

OrpheanBeholderon OpenSSH 7.3 released

Get the host fingerprints over TLS then?

https://www.openbsd.org/anoncvs.html

OrpheanBeholderon OpenSSH 7.3 released

> A bit ironic openssh.com doesn't have HTTPS

You can however access the release notes (or any other file/page from the website for that matter) over SSH using CVS

    $ cvs -d anoncvs@anoncvs.ca.openbsd.org:/cvs get www/openssh/txt/release-7.3

OrpheanBeholderon Tarsnap outage report: 2016-07-24 10:15:19--11:40:04

It was posted to the tarsnap-announce mailing list: http://mail.tarsnap.com/tarsnap-announce/msg00035.html

OrpheanBeholderon OpenBSD 6.0, to be released September 1

LLVM doesn't support all the architectures that OpenBSD supports.

OrpheanBeholderon Facebook Messenger begins testing end-to-end encryption using Signal Protocol

OWS quite often use anarchist figures and quotes in their example images for blog posts, this is nothing new.

OrpheanBeholderon Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump

Some of these don't make sense. The point of bcrypt, scrypt, and pbkdf2 is the difficulty of them is configurable.

Digging into the comments on that gist, it says that the bcrypt benchmark used a workfactor of 5 (= 32 rounds). The lowest possible bcrypt workfactor is 4 (= 16 rounds).

For comparison, the default for the login hashes on OpenBSD is 8 (= 256 rounds) for standard accounts and 9 (= 512 rounds) for the root account, and OpenBSD's bcrypt_pbkdf(3) function uses a workfactor of 6 (= 64 rounds) and that's intended to be called with multiple rounds itself eg. in signify(1) it uses 42 rounds (a bit over the equivalent of bcrypt with a workfactor of 11) and ssh-keygen(1) defaults to 16 (roughly equivalent to bcrypt with a workfactor of 10 (= 1024 rounds).

The point I'm trying to make here is that bcrypt benchmark uses a ridiculously low workfactor, and it looks like the scrypt and pbkdf2 ones did to.