Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
jfindley
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
36 ms
·
301.
▲
by
jfindley
12y ago
The number of bcrypt rounds is extremely low, too[1]. While the Go bcrypt lib will actually accept a cost of 5, that seems an unreasonably low value to me. Coupled with absolutely no encryption of the messages in memory, I think "anon
302.
▲
by
jfindley
12y ago
XFS is great, now. It had some problems with metadata performance at scale a few years ago (affected early versions of RHEL/CentOS 6, and may be one of the reasons it was not the default in those versions), but it's now the best
303.
▲
by
jfindley
12y ago
Interestingly, the NSW iVote seems to share some ideas with helios. They both appear to use ElGamel encryption, which is a [partially] homomorphic algo. I don't know anything close to enough about ElGamel to comment on their implement
304.
▲
by
jfindley
12y ago
Compared to a VPS there's some security benefits. You can't meaningfully encrypt the disk of a VPS - as the decryption key can easily be read out of memory by the host. A physical server offers slightly more protection than this
305.
▲
by
jfindley
12y ago
I'll see if I can re-work the documentation a bit to make this clearer - I think in the hope of making it easy to understand I oversimplified a bit too much. Each secret has a unique key generated for it on the machine uploading the se
306.
▲
by
jfindley
12y ago
You could easily store the client configs in etcd then just deploy the client with whatever bootstrapping you use if you wanted to go down that route. As long as the client knows what it's called and where the server is, it doesn'
307.
▲
Show HN: Secure key distribution (in Go)
(getskds.io)
6 points
by
jfindley
12y ago
|
5 comments
308.
▲
by
jfindley
12y ago
Well. Homomorphic encryption is still very much an emerging tech. For most applications it's still too slow. There's all sorts of cool things we can build when it gets a bit more mature, but for now it's not unreasonable th
309.
▲
by
jfindley
12y ago
If you start talking about co-located or self hosted services, the mitigation strategies are very different. Assuming you can find yourself a transit provider that supports BGP flowspec updates (many don't, sadly), you can do this fair
310.
▲
by
jfindley
12y ago
From my experience, this is confusing the issue - the OP was talking about using their DDoS filtering service, not their CDN. This is done by Prolexic - who despite being acquired by Akamai, still seems to function fairly independently. I&
311.
▲
by
jfindley
12y ago
Not disagreeing with what you say, but browser fingerprinting is a great deal less accurate than cookie-based tracking, so the ad networks would certainly like to retain a cookie on the client machine, if they can.
312.
▲
by
jfindley
12y ago
There are two issues with this statement. Firstly - you compare securing against the NSA to securing against "hackers". This massively underestimates the reach and resources of the NSA (or any nation-state actor). You can, to a p
313.
▲
by
jfindley
12y ago
The HTTPS implementation looks dangerous at first sight - it looks like an attacker could very easily just strip the X-Templar-Upgrade out from the request, and then end up with everything being un-encrypted - without the client throwing an
314.
▲
by
jfindley
12y ago
Yes, but that's a reason not to use /dev/random, not a reason to install snake-oil products. The random(4) manpage is unfortunately exceptionally misleading, and has sadly led to a small but non-zero numbers of products that
315.
▲
by
jfindley
12y ago
Pulling unsold inventory would be in some ways far harder to do for the consumer computing industry than many other industries more commonly known for recalls (auto, pharma, etc) - these laptops won't just be sold at the large outlets
316.
▲
by
jfindley
12y ago
One of fedora's key values is to be leading the way on stuff like this, so it's not surprising that other major distros aren't quite caught up just yet[0] (although I think for this particular one, debian won't be far be
317.
▲
by
jfindley
12y ago
I do really like the BLAKE2b hash, but I've been concerned about actually using it in practice (although recently I had an application which it would have suited very well). I'm worried that, having failed to win the SHA-3 contest
318.
▲
by
jfindley
12y ago
And sadly there's a patent covering point-verifying, so the workaround for this includes paying licence fees to Certicom if you're in the US. As far as I'm aware there's still no real progress on getting better curves (e
319.
▲
by
jfindley
12y ago
There's no reason that handling your own keys has to be something that you, personally, have to bother with. Just because you don't interact with the key handling doesn't mean it can't happen in a safe and secure enviro
320.
▲
by
jfindley
12y ago
Can you be more specific? There's lots of different tools available - there might be some better options available than what you're using. And while tools that change things (e.g. setting booleans, changing context rules, etc) are
321.
▲
by
jfindley
12y ago
Yeah, it's going to be an uphill struggle on any distro that it isn't already well integrated into - there's a lot of effort that goes into making SELinux in fedora/RHEL/etc JustWork(tm). Duplicating this on a dist
322.
▲
by
jfindley
12y ago
This is a good point, and I fully endorse the sentiment, but please remember that for basically all modern distros shipping SELinux as default (not counting android), the default is for users to be unconfined. This means that in a lot of ca
323.
▲
by
jfindley
12y ago
That's much, much less true than it used to be. These days there's great tools for managing and modifying selinux policy, and much better reporting of what was denied, when and why, and how to fix it. The "Selinux is too har
324.
▲
by
jfindley
12y ago
It would be nice to have support for ECDSA certificates. I've not found a CA yet who'll provide one of these, despite the fact that many clients to already support them. Unfortunately, after a brief look through client.py I can&
325.
▲
by
jfindley
12y ago
Nonetheless - for actually writing code using TLS, it's massively better than navigating the wilds of libssl. Having a full standalone implementation would be even better, but this is still great as-is.
326.
▲
by
jfindley
12y ago
As our web applications get ever more complex, and as a side result less secure (on the premise that complex sites are harder to secure than simple ones, and more likely to use features like this which further complicate security), I think
327.
▲
by
jfindley
12y ago
I'm sure there's some sites, but even if the percentage is in the low single digits (i.e. a smallish but still very significant percentage), I still think that browsers is probably the right place for this to be fixed. Getting eve
328.
▲
by
jfindley
12y ago
I personally also find ruby to have uniquely poor naming - lots of similar methods with overlapping functionality, no consistent style, etc. That's not to say it's a bad language per se, but as someone who works in lots of differe
329.
▲
by
jfindley
12y ago
As another commenter noted it's not a complete durability solution. However it is useful in a number of places - and not just to do with durability. AIO is also very extensively used, and bmap is pretty important. It's really imp
330.
▲
by
jfindley
12y ago
I'm far from being a hardware expert, but I thought it was curious that they used CBC rather than something like XTS. Is there a reason that CBC is more appropriate when used at the hardware (as opposed to filesystem) level, or is thi
More ›