e79

[removed]

SSSS is Shamir’s Secret Sharing Scheme.

Sort of. Different apps may use different finite fields. The math should be the same as long as you’re computing everything modulo the same integer. It is also possible that some apps may encode shares differently. For example, I’ve seen some apps base64-encode each share where others keep them as integers.

While SSSS provides information theoretic security, there are a couple of security gotchas. One example is that it leaks the length of a secret unless padding is used. In practice this isn’t usually an issue, since many applications (like this one) use SSSS for sharing fixed-size symmetric keys.

A more concerning gotcha is that this scheme doesn’t produce verified shares (i.e., shares lack integrity). An adversarial or forgetful share holder can submit a bad share and within this scheme, you’d have no way of being able to prove that they did this. All any of the participants would know is that the resulting secret is wrong, whatever that means for the application (e.g., the AES key doesn’t successfully decrypt a ciphertext).

Priority access services like 911 are handled very differently. For example, I can’t place any normal outbound calls with my T-Mobile sim, but calling 311 in NYC works fine.

On the other hand, fuzzing is only as “correct” as your coverage, properties/assertions, corpus synthesis, etc.

It doesn’t surprise me at all that bugs were found in SMT Checker. I recently wrote a blog post on how Solidity’s model checker works, and stumbled across several bugs while attempting to write simple example contracts. I didn’t even need a fuzzer :).

That area of the codebase is far from complete, which is why it is considered experimental and hidden behind a flag that you have to manually enable.

This dismisses theorem proving as too difficult to use for existing systems. My experience with old, complex systems is that they’re often old, complex and not very well understood anymore. Theorem proving is all about producing a specification and asking software to help you certify its correctness. I get that it’s often very hard in practice, but wouldn’t this process be incredibly beneficial then for existing systems? The endeavor would likely motivate the creation of an up-to-date spec and prove or disprove its correctness all at the same time. Whether the existing implementation matches the spec is another challenge, but this could at least uncover serious design flaws in high assurance software.

Out of curiosity, are there known pros and cons to each approach? I’ve been experimenting with Z3’s CHC engine and Coq for modeling programs. I don’t know enough about both yet to fully understand how they compare.

I'm not so sure about that. Comparing the vulnerable source code to the original (which you can find here https://github.com/ethereum/dapp-bin/blob/master/wallet/wall...) tells a totally different story. It looks like the vulnerable version tried to condense everything into a single contract (think class), when it had originally been split up into multiple contracts (think classes). The result was that functions that were originally initializers were no longer callable only once. Someone's refactor of the original code seems to be what lead to this issue. The vulnerable functions even started with "init" but were not actually initializers.

Unless the original author also introduced the bug, I don't think it's fair to blame the original contract.

Great article.

I recently wrote a tool to help find bugs like this:

https://ericrafaloff.com/introducing-the-solidity-function-p...

Manual code review would have likely helped. A tool like this maybe?

https://ericrafaloff.com/introducing-the-solidity-function-p...

The vulnerability was extremely simple, as suggested by the three keyword-long patch. I've written about this and other Solidity/EVM bugs from a technical perspective, if anybody is curious:

- https://ericrafaloff.com/parity-multi-sig-contract-vulnerabi...

- https://ericrafaloff.com/analyzing-the-erc20-short-address-a...

I think at least a big part of the solution to these security problems is two-fold:

- More secure conventions. All of the gotchas in Solidity make for a bad time. Even non-security bugs create a bad developer experience. Opting into private functions by default

- More code review. Engineers need to be diligent or hire security professionals who are (I'm one).

Yes, although my understanding is that the transition will be gradual. PoW rewards will gradually decrease while PoS rewards gradually increase, facilitating the tranisitioon without all miners jumping ship. Miners who are invested in Ethereum may choose to convert their mining profits into stake.

One thing that emojis cannot convey is unconscious body language. There are many subtle communications that can bear influence in empathy, love, trust (or distrust-- i.e. catching someone in a lie). Unconscious body language isn't required, but you can't ignore the fact that it is missing.

It has already surpassed $10,000. What started off as a joke very well could make the creator hundreds of thousands of dollars. Don't believe me? These tokens are now trading publicly on exchanges. They're no longer useless, as you can trade them! You could say their project failed as a result :)

If this makes zero sense to you, this kind of stuff is happening because there is such an excess of Ether in the market. Some of it is managed by real investors, as cryptocurrency has become a popular part of a balanced portfolio. Some of it is managed by young non-investors that threw money into ETH or BTC a few years ago.

It's pretty ridiculous IMO. But that isn't stopping it from happening. People have already made an unthinkable amount of money.

I would hope the economy eventually matures, and I too worry about a bubble because of some of the extremely high expectations people have. The "hodl" and "to the moon" mentality that is popular will have some refusing to cash out of their investments until it's too late.

Most don't understand the technology as well. I've spoken with investors who claim to be "all in" on Ethereum but can't tell you what the Ethereum Foundation is or how proof of stake works. As an investor, I would hope to have a strong understanding of where the future of my investment is headed. Not the case for many.

We're seeing some pretty interesting stuff going on. I wasn't in tech during the dot com bubble, but I've been told by others that were that this kind of mania seems very familiar.

I suspect that in reality, this would be far more complicated than your comment gives credit for.

How do you determine what coins have been through a mixer? By looking at tx inputs and going back all the way to when those coins were mined into existence? What if an innocent wallet happens to receive "dirty" coins even when the wallet holder themselves has done nothing wrong? Who would be in the charge of enforcing this? The network? The exchanges? If this is done at the exchange-level, what's stopping someone from simply cashing out via Amazon gift cards or the like through a non-traditional exchange service?

The list goes on. This is not a simple problem. I personally don't believe private or public regulation is the answer.

Writes to boot sector? Care to elaborate? Sources?

Does each session run in an isolated container? Because I wonder, what's stopping an attacker from exhausting system resources, messing with other users stuff, etc.?

[Removed rant in which I was trying to explain my frustration about investors having ill effects on the usability of such protocols by driving up associated fees. Unless you can mine coins, you are stuck dealing with a volatile market as an entry point, which blows. But nobody cares about that. So never mind]

You should also make sure providers like Google don't fall back to less secure account recovery methods. I blogged about this here, after I realized that I was still vulnerable even while using real 2FA:

https://ericrafaloff.com/google-account-security-and-number-...

Looking at this more closely, this takes arbitrary buffers of data and uses syscalls such as mlock to prevent paging memory to disk, as well as cleans up at the end by zero'ing out the buffers for you.

Has this been audited in any way? Is there a garuntee that the Go runtime won't, say, keep a duplicate of the buffer you copy() from in memory somewhere that can be paged?

Additionally, a technical description of how this works in the README would be nice for those that aren't familiar with how the memory gets locked.

Neat project. Curious to see how this develops.

The thing with infosec is that no matter if you're a consultant pen tester or an in-house member of a blue team, a high proficiency in technical writing is required. And few certs demonstrate that the person is a good technical writer. It's not enough to know the answers to multiple choice questions. It's not even enough to know how to exploit things. If you don't understand something well and can discuss it in technical detail to a number of different audiences, I don't believe you'll get very far in the industry.

There are a couple of exceptions, of course. OSCP is a good certificate to have. To pass the exam, you are required to not only demonstrate proficiency in several areas (i.e SQL injection, buffer overflows), but you must also write and submit a technical report to a review team. The technical report must address vulnerability overview, impact, risk rating, reproduction steps, and more. Of course the exam isn't perfect, but it's probably the biggest test of real technical understanding and ability I've ever seen.

This demonstrates the power of Go generators. We're seeing what are typically language features such as generics and debugging being implemented before runtime using code generation. The result is more functionality without an overall increase in runtime size or decrease in runtime performance.

It's unusual and it's opinionated, but it works.

Right. Not looking for specifics. My curiosity would be satisfied by something like "we've reached out to Baidu and they've done X and Y. Meanwhile, traffic has decreased so we've unblocked the affected repos."

Just a bit more transparency on the situation.

Yes but they don't explain what the mitigation is.

I wonder how GitHub mitigated the attack so successfully. I can't find any baidu scripts using the injected code anymore (in fact the original tracking scripts on baidu's own domain return nothing), and GitHub is now serving the two repos that were originally targeted.

What happened? Whatever it is, I'm glad they were able to mitigate the attacks.

From something I posted on our site:

From my experience, unless a change in a Google product degrades functionality for a large portion of end users they aren't going to publicly acknowledge it. They don't seem to have the same policies regarding transparency that other companies like FetLife do (we acknowledge when we mess up and break stuff!).

When ReCAPTCHA went down last year I looked and could not find any acknowledgement of the issue from a Google employee. This was while FetLife and other large websites tweeted about it and posted in Google's product forum. All we had to go with was speculation and helping each other out with recommendations for temporary solutions.

Likewise, this change in Gmail may never be officially acknowledged. It may be related to the arrival of Google's new Inbox product or it may be related to some sort of spam filtering they deployed into production. It doesn't appear to be specific to adult websites. Other large community websites are affected too. The result is that affected websites using plain text emails are now forced to switch over to HTML-based email. I could see a conspiracy theory in there about Google pushing HTML-based email for a nicer looking Gmail/Inbox experience. No matter what, I think it's very unlikely we'll ever know what change caused this or why.

Someone e-mailed me to let me know that a discussion forum they post on has run into the same issue. Seems like we are not the only one...

Yes. (Site is NSFW, by the way)

Anybody else feel like the article keeps reminding us that she is a female? Feels a bit like it's presented as an unusual detail, when in reality sexual harassment comes from both males and females.