The article mentions that it's not a wood-framed building, I think implying that it's a true layered (multi-wythe) brick construction:
My analysis doesn't even address brick problems associated with the switch from multi-wythe brick construction to brick veneer over wood framing. (Andres Hall is not a wood-framed building.) Although buildings with brick veneer over wood framing are usually better insulated than old multi-wythe brick buildings, they are frequently plagued by an entirely new category of water entry problems due to flashing errors, clogged air spaces, and missing weep holes. But that's a topic for another article.
> The acceptable particulate level in Colorado emissions testing is 35% opacity. That means the smoke and particulates that are coming out of the exhaust pipe can block up to 35% of light and pass the test. This is a lot of smoke.
This is the most shocking part of this... can you really pass with that much smoke coming out the tailpipe? That's absurd and I find it hard to believe. What's even the point of testing based on those regulations?
The 35% is a meaningless number without more details. It's not shocking at all if a 1km column of smoke blocks more than 35% of the light passing along it. So we need to know more about the test to decide if it's shocking or not - specifically the distance the light travels through the sample.
Integration time is also important. Short bursts of dense smoke can be equally polluting as a continuous stream of light smoke.
The basic argument is that the explosion in prison population is driven mostly by changing attitudes/behavior of the prosecuting DA's in the past few decades. They have simply chosen to go after felony charges more frequently than in the past. This is problematic because they are elected and there is no federal-level fix that can be applied.
Brit here. How often, and for how many posts do you typically vote in elections in the US? It seems like everyone down to the local Librarian is an elected official. Are these votes held one at a time, or is there one massive election for a couple of dozen posts all at the same time every year or something? What's the typical turnout for these elections? How is it decided which posts will be elected and which ones are appointments, and does this vary from place to place?
In comparison, we generally have two elections every 5 years. One for our MP in Westminster, and one for our local council and these are often held simultaneously. For many people, that's it. Some cities also have Mayoral elections, and there can be town or parish council elections as well but whether these exist or not is very local. I don't think we have any direct elections to administrative positions, unless you count Mayors. There might be some rare local exceptions to that but they're most likely purely ceremonial.
The elections are typically bundled, so in a particular November in some places you might be voting for president, senator, representative, governor (most states have gubernatorial elections halfway through presidential terms, though), state representative, state senator, district attorney, sheriff, school board, propositions (binding referenda on legislation or amendments to state constitutions), ... Turnout varies a lot, with much higher turnouts in presidential elections (but these additional voters may or may not vote on the other ballots).
In the federal govt AIUI there are no elections for executive offices other than the presidency, so only president, vice-president, senators and representatives are elected. But many state and local executives are elected, as determined by local legislation.
The "police and crime commissioner" scheme was an attempt to replicate the US model of policing in the UK. However, since they don't have the power to direct prosecutions or any real budget, it's a completely useless £100k-year post that gets 5-15% turnout in elections.
Since the keybase people are probably here reading, can I make a suggestion? Please change your logo from a shifty-looking character to something that inspires more confidence. I actually think the character in the logo is cool and I love your artwork but I just think the logo sends the wrong message. Google Chrome's private browsing mode does the same thing...
Identity management and encryption should strive to be associated with concepts of strength, integrity, legitimacy, trust, cleanliness and safety. There is nothing shady about it and we shouldn't need a guy in a trench coat to represent the idea that we should be able to confirm that our friends who are communicating with us are who they say they are and not imposters. Let's focus more on the trust part and less on the sleuthing in the dark part.
Sorry, just my $0.02... I only tell you because I want you to succeed.
What’s wrong with the fox? I like their logo. A lot of big, mainstream brands have fun-looking mascots. They may have to redesign and improve it as they grow, like everybody does, but I don’t see it necessary to replace it completely.
Yeah I like it too... as a character it's fun and silly and everything I like about being a developer. What I don't like about it is exactly as I said: too shifty looking. As you say, it's time to redesign and improve it. It doesn't have to go away and it could remain the company mascot if they wanted. I would hope it does. (also, I'm not sure it's a fox? is it?)
I actually feel a bit bad saying it and sad this is the top comment right now since it's a fairly minor point and way less important than what they are doing. I just think you have one chance to make a first impression about what your company stands for and the logo is a big part of that. In fact it's one of the parts that is most likely to end up representing your brand on other sites. Looking at their site, I think they care about that a lot and put a lot of effort into it so I hope this comes off in the best possible way.
Why hasn't someone qualified re-written that unix man page by now? I've been reading cryptographers trying to explain all of this for a while now. I feel like that would help put a lot of this to rest and save everyone time.
Honestly, anyone who cares & can understand will look at the implementation of the two and grok it. Those who don't will screw up the rest of it anyway, and that will create more than enough trouble even with some helpful guidance. Best to have them fail in pretty obvious ways.
I guess it is a matter of perspective. If you understand what you need for your cryptography, you'll know if you want /dev/random or not. The fact that it blocks is very, very well advertised and clear. The fact that the difference is that /dev/urandom won't block is also very, very clear. If you don't know which you want, I'd wager you don't understand your cryptographic protocol's needs terribly well, and are best off outsourcing that work to someone else.
Last time I tried using gpg on a VM it failed to work (literally would not do anything) because it blocked on /dev/random. Would you say that the gpg people should be outsourcing their work to someone else?
Things have improved a little on this front. It turn out gnupg was being a little gluttonous when it came to entropy:
"Daniel Kahn Gillmor observed that GnuPG reads 300 bytes from /dev/random when it generates a long-term key, which, he observed, is a lot given /dev/random's limited entropy . Werner explained that GnuPG has always done this. In particular, GnuPG maintains a 600-byte persistent seed file and every time a key is generated it stirs in an additional 300 bytes. Daniel pointed out an interesting blog post by DJB explaining that a proper CSPRNG should never need more than about 32 bytes of entropy. Peter Gutmann chimed in and noted that a 2048-bit RSA key needs about about 103 bits of entropy and a 4096-bit RSA key needs about 142 bits, but, in practice, 128-bits is enough. Based on this, Werner proposed a patch for Libgcrypt that reduces the amount of seeding to just 128-bits."[^1]
On a related not why are you generating keys on a remote vm? Its probably not fair to say that gpg "failed to work (literally would not do anything)." It was doing something, gnupg was waiting for more entropy. Needing immediate access to cryptographic keys that you just generated on a recently spun up remote VM is kind of a strange use case?
Thanks very much for the updates on entropy requirements.
Re: "Why are you generating keys on a remote VM" - prior to this, it hadn't occured to me I couldn't generate a gpg key on linode/digital ocean, VMs. I realize now that keys should be generated on local laptops (or such), and copied up.
Re: "Fair to say failed to work" - It just sat their for 90+ minutes - I spent a couple hours researching, and found a bug (highly voted on) that other people had run into the same issue. But, honestly - don't you think that gpg just hanging for 90+ minutes for something like generating a 2048 bit RSA key should be considered, "failing to work?" - I realize under the covers (now) what was happening - but 99% of the naive gpg using population would just give up in the same scenario instead of trying to debug it.
Yeah, the bug was really how it handled the case of waiting forever without telling you why. In GPG's defense, before it actually stars reading from /dev/random, it does give you all kinds of warnings that it needs sources of entropy before it can make any progress.
Hard to get that kind of thing right, but fundamentally it did stop you from making exactly the kind of terrible mistake that I was talking about. ;-)
I thought the entire purpose of this thread was pointing out that /dev/urandom is plenty fine for security purposes, and all blocking on /dev/random does is, well, block your program for no particularly good reason.
/dev/urandom is fine for a lot of contexts. If you were using it for key generation (which I believe is when it reads from /dev/random), particularly inside a VM, that might be when you have a case that you have a need for a small seed that can't controlled by the VM environment. You don't want two instances of the VM picking the same exact persistent keys.
As the article says, it's a screw up to not have each VM instance seeded separately. You need that to not muck the whole thing up. In the case of generating keys for permanent use, you want to fail in that case, at least until some entropy shows up, as it did.
If you have two VMs with identical /dev/urandom states, that's a grievous vulnerability that will impact far more than GPG. This doesn't seem like a good reason to use /dev/random, but rather a reason to fix whatever distro bug is preventing your (u)random from being seeded properly.
In addition, if two VMs have the same urandom state, that means they must have the same random state. So now you are hoping that somehow those states diverge? But given that they started the same, I'd be wary of making that assumption. There's no guarantee that whatever "entropy" unblocks random on one machine won't be identical to the second machine.
Yes, so the question is what is the preferred failure behaviour when there isn't even enough entropy in the system to be confident that you can select a single unpredictable key with any kind of confidence of uniqueness within an unbounded time window. That should mean that the system effectively has no source of entropy.
I think blocking and not returning until you have entropy is a reasonable failure behaviour for gpg in the key generation process.
It'd be nice to report something and maybe hint to the user that you are waiting for just a modicum of entropy to show up, but at least it isn't presenting a key that is entirely predictable (and worse still, the SAME as any other instance of that VM image!!!) to anyone with access to the original VM.
The bug the article is referring to is that a lot of security systems will block reading /dev/random when in fact /dev/urandom will provide a securely unpredictable sequence of data with no statistically likelihood of another system producing the same sequence. It's particularly bad for the case where timeliness is an important part of the protocol (which is largely a given for anything around say... a TCP connection). That's a silly design flaw.
I think I see what you are saying - that gpg blocking, and failing to create a key on a VM, is actually a desired behavior, and that the only real problem is gpg doesn't time out more quickly and say something like, "System not providing sufficient entropy for key generation".
But, if that's the case, then the entire thesis behind, "Use /dev/urandom" is incorrect. We can't rely on /dev/urandom, because it might not generate sufficiently random data. /dev/random may block, but at least it won't provide insecure sequences of data.
This is kind of annoying, because I was hoping that just using /dev/urandom was sufficient, but apparently there are times when /dev/random is the correct choice, right?
/dev/urandom will generate secure random data. That's what it does.
That was the point of the blog post: if you are using /dev/random as input in to a cryptographic protocol that will stretch that randomness over to many more bytes, WTF do you think /dev/urandom is already doing?
What /dev/urandom might fail to do, and this primarily applies to your specific case of a VM just as it is first launching and setting things up, is generate unpredictable data, and most terribly, it might generate duplicate data, for certain specific use cases where that would just be awful.
I would agree that you got the gist right though: /dev/urandom is usually the right choice, but when it is not, /dev/random is indeed needed. Most people misunderstand the dichotomy as "random" and "guaranteed random", which leads to very, very unfortunate outcomes. Other people misunderstand what they are doing cryptographically and somehow think that some cryptographic algorithm that uses a small key to encrypt vast amounts of data shouldn't have any concerns about insecure, non-random cyclic behaviour, but oddly take a jaundiced eye to /dev/urandom. It basically amounts to "I think you can securely generate a random data stream from a small source of entropy... as long as that belief isn't embodied in something called urandom".
Again, if you don't know the right choice, you should pass the baton to someone who does, because even if you make the right choice, odds favour you doing something terrible that compromises security.
There are very specific use cases, where the concern is not about entropy in the series (because duh!), but from having a small seed value that is intrinsically not cryptographically secure but unpredictable (not quite the same thing) even in a controlled setup like a the start up of a VM image.
I would agree with the article that the right way to fix the problem is to seed each instance of the image on startup, but that will also avoid you having a problem with it blocking.
That's a special case though, where you aren't in the middle of a cryptographic handshake, you don't have real time constraints, and the fix to the real problem will also mean there is no problem. Don't use it for a network service's source of randomness.
People seem to think this is a problem for the US (and I suppose it sort of is) but may not realize that it's not rosey for China either. The article ends by implying that they want to be doing this to get rid of much of their reserves, but I'm not sure it's that clear. The title here about China 'warning Washington' could be read either as a head's up or as a threat.
The problem for China is that by selling treasuries for USD and then using that USD to buy yuan, they are effectively taking that money out of circulation. This keeps the yuan from dropping and maintains the currency peg but it also removes all of the liquidity in the market. This is not really a great situation. It also makes US manufacturing more competitive.
In the past few days, they have been talking about playing with the reserve-requirement ratio of banks to encourage them to dump money into the market to maintain liquidity. If you tell banks that they can 'officially' lend out more by lowering the required amount of money they must have on hand, they will and then real money has been created.
I feel like they're really just trying to keep the whole thing on the road.
> don't the Chinese want a devalued Yuan? It helps their economy, right?
It helps some and hurts others. It helps when you are exporting and hurts when you are importing. But it gets complicated:
Among the 'importers' are consumers. Devaluing the yuan raises prices for imported goods and services, and goods containing imported components. In a way, devaluation taxes consumers to help exporting businesses (but it's more complex: some consumers work for or otherwise do business with exporters, while some are connected similarly to importers).
Also among the importers are businesses who import components of the products they make, including goods, software, and services. Those importers just saw an across-the-board increase in their costs.
And there is import and export of debt. Those who owe money in another currency, usually US dollars, just saw an across-the-board increase in how much they owe. Those who are creditors in another currency just got an across-the-board bonus; however I suspect that most Chinese institutions would lend in their own currency. It also helps those importing assets; for example investors are more likely to put their money in China when they can buy yuan-denominated assets more cheaply.
In a free-floating currency and open market, exchange rates also affect domestic interest rates because the exchange rates affect demand by foreign investors. I'm not sure how China's market works in that regard.
In the end it's the government picking winners and losers, but if their economy or key sectors depend more heavily on exports than imports, certainly they could see a net gain.
They devalued the yuan a bit, and probably want to keep it where it is now.
China runs partly on low interest rates on deposits. That means savers are effectively subsidising loans to businesses. Chinese savers are already looking for other places to park their savings (stocks, real estate, offshore), and China doesn't want to add more inflation as another reason to withdraw from banks.
I guess they figure that buying and selling US bonds is a way to control their target exchange rate (which they probably want to keep fairly stable) without messing other variables up too much, because the global market for bonds can soak it up.
Yeah it's confusing... You're right that a devalued Yuan helps their exporters. Of course, too much is a bad thing too. They want to keep their currency within a narrow range relative to the USD. They were recently making a move to do that which sparked all of those 'currency war' headlines:
They did that as a 'one-off thing' but it seems like everyone interpreted it to mean their economy was actually really in bad shape so investors started to get out before their assets dropped more. Then the stock market went to hell and now they're surprised that everyone is spooked:
Yeah the general rule with currencies is that as long as they're not too volatile, they can go up or down without huge implications to the economy.
The other thing to realize with the Chinese stock market is that even though it dropped something like 50% in 2 months, it's basically flat since January. If you look back to 1 year ago, it's still up 40%. You don't get 250% growth in 6 months without an accompanying correction cycle. The biggest problem with China right now is that it's high on potential, but nobody knows what the right value should be. So it will continue to be volatile like this until there's a better idea of if Chinese companies are creating real economic value or not and to what degree.
You need to take news reporting with a grain of salt, just because all news papers say something doesn't mean that something is true.
There is some truth in lower Yuan helps export, and the Chinese government probably kept that in mind. But I think their main priority is to maintain the status quo, and keep things stable, for the past 15 years or so.
I believe when they decided to devalue their currency it impacted their stock market and unfortunately all central banks are now beholden to their individual equity markets and therefore "had" to take action.
The title about 'warning Washington' is almost certainly a heads up and not a threat. The Treasury needs to understand market dynamics to have smooth auctions for new treasuries, which is in everyone's interest. Prime dealers (the big banks that deal in treasuries) give the Treasury a heads up about these things, so would be natural for China to do so.