>Why would you expect an email provider to also provide a calendar?
Because calendar has become a key part of a productivity suite and Email is the keystone. We use Protonmail right now to avoid Google or Fastmail or someone serving up all our emails in a warrant. We keep sensitive stuff off Protonmail of course but every bit helps LE build their case against us.
Protonmail should have calendaring, wiki, and on and on. An encrypted replacement for Exchange eventually. We disable all audiovideo hardware for core members but I can see even secure voice being useful for our contractors to use.
Our company is not legal (details in profile). We chose Protonmail to start because our biggest concern was getting our emails served to the government on request down-the-line. We pay a significant monthly charge to use their services and feel it is worth every penny.
A lot of people in our industry and others have this same model. It is not that the NSA is after you. It's local law enforcement. In our case, SEC and FBI. For average users, local LE will not have 0 days or anything special. Protonmail is out of reach for a lot of LE and that is important.
The best choice for us when we're fully operational is to run a Protonmail-like setup, self-hosted. Deal with mail issues and spam. It is a pain!
Our app has a somewhat Tinder-like feel, though it's paid (escorts). I don't want to go overboard plugging, so see my profile for details. For fun, here's how we score on the article's items:
1. No scammers. We require providers to be vetted in some way (references). Clients are going to need to provide screening to see providers.
2-A. We use our custom login system. Verifying your social media account is just a read-once thing we do; we don't ever have access to post. In fact, it is unlikely we'd even get approved for an API key on most platforms.
2-B. For launch we're pretty exclusionary :(. Focusing on cishet couplings, female provider. We're going to address that as soon as possible. Queer sex workers face additional challenges for sure.
3. Data safety. Due to our company's legal status (extrajurisdictional), we have to deeply hide all data. Our servers don't have persistent storage, RAM only. (At boot, it's a manual restore from something like Tarsnap.) Only a few people have root or raw DB access. This does not include most devops people - they go through a change approval process. Real access is limited to core members heavily vested in the company with a need-to-know. More at [1], please ignore the clickbait title.
Another key point: connectivity is heavily restricted. App servers only have inbound socket from their hidden service, plus outbound to the DB layer hidden service. DB layer only has that inbound socket. DB requests are rate limited globally plus per user.
4. We'll wipe your data shortly after deactivation if there are no abuse reports on your account. In which case we keep a photo ID and birthdate so you can't sign up again and get a clean record. This is needed to protect user's safety. But at least a photo is not so readily searchable. Maybe Facebook can do it, but if we were to somehow
I have to admit, combining prostitution, securities fraud, and blockchain technology in one single project is impressively ambitious even by normal startup standards.
Calling it securities fraud is rather unfair if you ask me. Why do you say fraud? Sure, we do not follow the SEC rules. In fact, the SEC opinion on ICOs is what galvanized us to go all out and insist on offering real equity to investors. It's far better than the nonsense ICOs come up with to tokenize themselves.
People like the Tezos group, asking for donations... it is disgusting that investors go for that. Demand equity. We always choose morality over legality. Following SEC rules technically, while ripping off investors ... I'd rather be in the clear ethically.
The blockchain part is for payments, so not that big of a deal. Though to raise money, we'd be better off finding a blockchain angle to the platform! Truthfully though, our app is not breaking new tech ground, apart from privacy and security (see the link in my original post).
We are ambitious though! I think we'll be the first blockchain-funded unicorn. Escorting is fragmented and high friction, and we're going to fix it. Our VP of Product is an active sex worker and very tuned in to the real issues facing workers and clients.
Escorting might not be viewed as fundamental a right as driving, but yes, same idea. We put morality over legality.
Extrajurisdictional does not just mean criminal. It means that we operate in a way that no specific jurisdiction can apply itself to us. It isn't a wild card to just do whatever we want. We fully intend to pay taxes where possible. We want to be as transparent as possible to avoid money laundering. We have a strict no drugs policy. Strict age requirements, and, as far as possible, no coercion/trafficking/pimping. (If we see one device managing multiple accounts, we'll investigate/ban.)
We may write up more when we have things stably working after a while. But we are very cautious mentioning any specific tools, as that gives attackers a head-start. We won't mention OS, stack, DB, etc.
But think something like secure boot, serve up a basic image, download full image from provisioning servers, turn on DB, restore from backups.
Only a few people have access to the keys, plus a set of third parties (think lawyers) that have a shard of an SSS setup. Changing the boot key can be done now and then.
But we think it is feasible to drop the disks entirely for the main servers. So the disk encryption is an issue for the systems holding our CI and imaging platforms.
I do not mind having Bitcoin keep going up. But as a business owner that relies heavily on cryptocurrencies, I would really love it if things were more stable. We are building a business on privacy, anonymity, and cryptocurrency as a backbone. We're extrajurisdictional, so banking to USD or other fiat is very tricky. Tether is a great idea, but the current company looks very unstable. If there's a crash, they seem unlikely to be solvent.
Our company would pay a premium to get into a solid, pegged-to-USD coin. At least 5% if not more. Or even a coin that's pegged to an ETF. Of course we cannot satisfy KYC laws so it'd need to be a freely traded token, really.
I really hate the "hodlrs" and the complete lack of focus on how this is supposed to work for real businesses that use it as a means to an end, and not an end by itself.
I see this a lot talking about the 2x chain. People sometimes discuss it in terms of what's better for the BTC price. Why is that a goal at all? Other than the obvious reason of making current users richer?
If you want to transact in USD shouldn’t you use USD rather than a different currency (BTC)? And if you want to use a block chain to transact in USD shouldn’t you use something designed for that like Ripple?
That'd be swell. As an EJC, transacting in USD is more difficult, hence we must use cryptocurrencies.
Is Ripple pegged to USD? I do not want anything complicated, just a coin or token that has a 1:1 ratio with USD. Charge me 5% or 10% to buy them or 5% on cash out.
I believe this is because we are still very low on the adoption curve. Once it gains mass adoption and it is used more as a form of payment, the price will stabilize.
2x was made by businesses for businesses. It is supposed to solve the high fees and long confirmation times (at least on the short term) which are crippling businesses.
I do not really care about Bitcoin politics, but I will say as a user and business, the fees and confirm times are ridiculous and need a fix now, not in "18 months" when LN comes out (and then who knows how long until high adoption of LN).
Except they are shady as hell and have not published anything to establish that they are solvent. It is fine to use right now to hedge against small changes. If something crashes hard then people try to get out of Tether, it will fall apart.
No one has shown proof of being able to withdraw from Tether.
That's why a Tether that is done properly would be very valuable indeed.
This is why we need SSL certs for .onions. DigiCert was doing this, but they told me it is on hold. Maybe when V3 hidden services are out?
With an SSL cert, you get a cert for your .onion PLUS your clearnet domain. Then users can access the .onion and see your real enterprise's name.
This should be doable even for extrajurisdictional companies like mine. The key is that your clearnet site should be a TCP-level proxy to the hidden service. That way the SSL keys are never on an easily-discoverable system so only IP addresses can be logged, not any contents. Slight plug: Here's the tech design for our system: https://medium.com/@PinkApp/pink-app-trading-latency-for-ano... (ignore the clickbait title). This should work just fine for .onions too, even with the clearnet entry point. For a DarkNet Market, most small buyers are probably safe visiting over clearnet.
The point is to remain user-friendly while hiding the actual webservers, databases, and anything else that LE might want to take. An onion-routing proxy is easily setup and torn down and moved around quickly, making it a harder target for persistent surveillance.
How are .onion service providers supposed to communicate out to their users whether or not their site uses a certificate?
And, presuming they are able to do this, why not just use that communication channel to communicate the correct .onion URL to the user in the first place (thus removing the need for a certificate authority)?
EDIT: Perhaps it would make sense to create a separate URL type for Tor services whose keys are signed by a certificate authority? So the URL would become e.g. secure.smspriv6fynj23u6.onion, and the Tor browser would reject sites prefixed with “secure.“ that don’t have their key signed by a certificate authority. This way, an attacker must register with a certificate authority in order to phish a “secure.“ Tor site.
> Perhaps it would make sense to create a separate URL type for Tor services whose keys are signed by a certificate authority?
The onion IS a proof of key. If you use the whole onion address (which is a hash of the public key) then Tor requires that the hidden service be able to prove they own the private key. It's like a builtin CA.
The problem to me is that knowing someone has a key isn't as interesting as knowing that the person is a trusted source. And being anonymous takes some of the responsibility away.
It makes more sense to me that someone just use an HTTPS clearnet site and users who want to protect their own IP address can access it from Tor (it works just fine).
Protecting the site owners identity and then wanting to prove their identity to stop phishing attempts seems at odds to me.
But DigiCert says they are no longer issuing them. Probably because the .onion is an 80-bit truncation of a SHA1 hash so it doesn't meet baseline reqs?
I don't know what DigiCert's motivation was for suspending issuance of .onion certificates, but the CA/Browser Forum had given a special dispensation (by ballot) for issuance of EV certs despite the criticism about cryptographic strength mismatch. This dispensation didn't extend to DV, but it's never been revoked, so DigiCert would still apparently be able to continue its EV issuance if it wanted to! (But it looks like they've even let the facebookcorewwwi.onion certificate expire.)
I've recently become an observer at the CA/Browser Forum and plan to bring up the subject of DV certificates for next-generation onion services imminently, just as soon as I'm done with my relaxing vacation!
Are you talking only about EV certs? Because DV certs don't really display your enterprise name, at least not in an easily accessible location for users to see.
2^80 is not very weak. That's the level of brute forcing a SHA-1 collision. It's low for a new system, but not very weak.
I agree with your 20%/10% comments, but I do not know why you call ZCash an investment. Zcash should discourage people from investing, like Monero does. Be a privacy coin, do not try to get in on the moon and lambo hypetrains if you want to be taken seriously.
There is no good justification for 20% right now. ZEC market cap is half a billion today. Do they really need that extra 50 mln now versus over time? Feels greedy.
But with so much taken by them that way, does that not reduce their desire to get a backdoor?
At any rate, all of this ceremony and your measures seem, as you say, hocus pocus if you're not building from known source! Forget hardware attacks! How can they not have the basics of a secure toolchain?!?
Did some participants at least publish the source they used and hashes of the toolchain and environment?
At my startup (details in profile) we will end up depending on crypto (among other things) to stay out of prison. Monero is hard to use, privacy wise - EABE and EWE attacks are our concerns. At least with ZCash the model is fairly easy to understand with shielded transactions. Much easier than figuring out ringsize and traceability there. But the Monero community seems better with no 20% take, no central company, none of this trusted nonsense. And no odd comments by both founders that require lots of mental gymnastics to make sense of. Not that any of this should matter. ZCash should be trusted on its own merits regardless of the inventors. Monero has anonymous inventors which could be the NSA for all we know.
Alas I am in no position to analyze ZCash math vs RingCT but my feeling is the latter is more understandable and thus might be more secure even if it has much weaker safety promises.
> 2^80 is not very weak. That's the level of brute forcing a SHA-1 collision. It's low for a new system, but not very weak.
Note that the 2^80 figure from Peter's blog post is really unsubstantiated. There's another curve in libsnark (which we don't use) that has 80-bits of security. I suspect what happened is whoever Peter was consulting with just repeated this number to him. We've spoken to many cryptographers who are experts on these curves, and none of them think that figure is reasonable. I actually don't believe there are _any_ cryptographers that have publicly made such a claim about the security.
2^96 was the original conservative estimate when the NFS attack was discovered, but subsequent analysis showed concrete security closer to 2^110 (and that's ignoring the unrealistic memory costs of the specific attack.)
> How can they not have the basics of a secure toolchain?!?
We provided participants with a reproducibly built and stripped down version of Alpine Linux, employed grsec, wrote all of our crypto software in pure Rust, etc. All of our software is reproducibly built, hashed and signed. There is nothing (software-wise) that cannot be caught in post-hoc review. All of it is open-source: https://github.com/zcash/mpc
Several academic papers regarding our protocol have been published since then. We wrote a full security proof of the crypto. We hired NCC group to audit the ceremony as well: https://z.cash/blog/ceremony-audit-results.html
More auditing can always be done but this is a continuing process. The primary goal is to make it difficult for someone to undetectably compromise the ceremony.
"I’ve had some experts tell me they thought the security level was 2^80 operations (very weak), while others (including Zooko himself) thought it was [more like 2^96](https://moderncrypto.org/mail-archive/curves/2016/000742.htm...). I’m not sure which figure is right, but the fact that there’s disagreement is a bad sign."
I made it very clear that it is an unsubstantiated figure, and linked to Zooko's analysis. To both yourself and the person you're replying too, please don't put words in my mouth.
> We provided participants with a reproducibly built and stripped down version of Alpine Linux, employed grsec, wrote all of our crypto software in pure Rust, etc. All of our software is reproducibly built, hashed and signed. There is nothing (software-wise) that cannot be caught in post-hoc review. All of it is open-source: https://github.com/zcash/mpc
I agree. But that's not what I said; what I said is that post-hoc review hasn't been done, even a year after the fact.
> To both yourself and the person you're replying too, please don't put words in my mouth.
What words did I put in your mouth? I cited the 2^80 figure in your blog post and a reasonable theory for why you would bring up such a figure. "Regurgitated" came across as snide so I apologize for that.
Note that you used this unsubstantiated figure to say "the fact that there’s disagreement is a bad sign." If there isn't actually any disagreement and the figure is unsubstantiated, why is it not baseless FUD? (BTW I notified you of this error in your blog post some time ago but never heard back.)
> what I said is that post-hoc review hasn't been done, even a year after the fact.
I know, I wasn't replying to you. As I said, I believe more auditing is needed. I also don't believe some kind of one-and-done audit of the software/deterministic builds would satisfy either of us.
> "Regurgitated" came across as snide so I apologize for that.
That's the thing, it didn't just come across as snide, it made it sound like I repeated the number uncritically, when in fact I made it clear to the reader where it came from and that there was disagreement.
> If there isn't actually any disagreement and the figure is unsubstantiated, why is it not baseless FUD?
The fact that competent experts could be unfamiliar with Zcash's crypto to the degree that they could disagree on basic facts like that is a sign of concern, precisely because it's yet another strong sign that the crypto is quite new. If this were "tried and tested" crypto, there wouldn't be any disagreement. Note that Zooko himself was unsure of the exact strength due to a recently found attack - tried and tested crypto wouldn't have recently found attacks.
> BTW I notified you of this error in your blog post some time ago but never heard back.
Where did you notify me? For that matter, who are you anyway? I probably know you by name from elsewhere; I don't by handle.
> I also don't believe some kind of one-and-done audit of the software/deterministic builds would satisfy either of us.
Well, I was just discussing the trusted setup with Matthew Green, and I think there's some fundamental disagreement on what kinds of vulnerabilities exist and what the risks of them are. So I really need to write a blog post on it.
I'm Sean from Zcash, I coordinated the MPC and wrote the software. I messaged you on twitter or emailed you or something about this last year.
> it made it sound like I repeated the number uncritically
I didn't say you regurgitated it. I said the person you talked to did, presumably after looking at libsnark or an unrelated paper.
> The fact that competent experts could be unfamiliar with Zcash's crypto to the degree that they could disagree on basic facts like that is a sign of concern, precisely because it's yet another strong sign that the crypto is quite new.
I claim the person you talked to was looking at the wrong curve construction. 2^80 is quite a torch to carry into an argument and no experts that we know have ever suggested a security level less than 2^96. The only "disagreements" about security were far more subtle and reasonable than what your blog post suggested.
This is one situation in which I think that using grsec is absolutely the wrong choice. Grsec mitigates a lot of kernel bugs, but it also adds bugs. More importantly, it isn't particularly well audited, and it is unlikely to have many eyeballs on it at all in the future, given it's not-really-open-source status.
In our case, the use of grsec was one of the simplest counter-measures that achieved an almost purely additive security improvement. That's even when accepting the risk that grsec has security bugs in it.
If the participant did everything right, one of the only remaining ways that the secrets could be exfiltrated from the machine was by exploiting a theoretical vulnerability in xorriso, the software we use to read/write DVDs for airgapped communication in the ceremony. Even then, it was likely to leave an evidence trail on the DVDs for post-hoc review.
As an extra precaution, we needed to impose strict policies on the xorriso process. Grsec was trivial to employ using off-the-shelf Alpine Linux tools, and didn't require any dependencies which would increase the cost of auditing afterward. Grsec was also not likely to introduce bugs we couldn't catch in post-hoc review due to the evidence trail left on the DVDs.
The hope was to force an adversary to exploit both xorriso and grsec in practice. One important question is: was grsec likely to introduce a category of bugs that would not otherwise exist in Linux already? I think the answer to that question is no. Funny enough, just a day or two before the ceremony the Dirty COW vulnerability was patched in the Linux kernel, and we just managed to update our OS before the scheduled ceremony.
What I said was those builds hadn't been properly audited; just being reproducible isn't enough unless people actually reproduce them, and additionally, audit the dependencies that go into those builds.
> Alas I am in no position to analyze ZCash math vs RingCT but my feeling is the latter is more understandable and thus might be more secure even if it has much weaker safety promises.
Depends on what type of security you want. If you're talking about security against inflation, then RingCT is definitely safer than Zcash.
But if you're talking about privacy security, then Zcash is more secure than RingCT; the trusted setup can only be used to create fake Zcash, not deanonymize transactions.
>the trusted setup can only be used to create fake Zcash, not deanonymize transactions.
"I think we can successfully make Zcash too traceable for criminals like WannaCry, but still completely private & fungible"
"I _don't_ mean weakening security (https://z.cash/support/faq.html#backdoor …). I mean that a secure protocol layer is compatible with good law enforcement." -zooko
Not sure how your statements carry water in the face of that comment.
But detecting cheating and withdrawing requires you to have client software online and monitoring. Which individuals can not do and thus will outsource it to their payment handling company which will probably be the same as the LN hub.
Because calendar has become a key part of a productivity suite and Email is the keystone. We use Protonmail right now to avoid Google or Fastmail or someone serving up all our emails in a warrant. We keep sensitive stuff off Protonmail of course but every bit helps LE build their case against us.
Protonmail should have calendaring, wiki, and on and on. An encrypted replacement for Exchange eventually. We disable all audiovideo hardware for core members but I can see even secure voice being useful for our contractors to use.
reply