CiPHPerCoder

9 ms·

31.
by CiPHPerCoder 2y ago
Andy Jassy decided that it was time to Return To Office. I was hired in 2019 as a fully remote employee. This means my options in 2023 were a) move to Seattle or b) walk. I chose to walk. The leadership of the Cryptography org fought tooth
32.
by CiPHPerCoder 2y ago
Thanks for clarifying, and confirming at least one of my suspicions. All I can say here is, "Yikes." If you (or, well, anyone) ever need an honest third party to audit a cryptography design--whether it's because you suspect b
33.
by CiPHPerCoder 2y ago
> I wonder if OP works in healthcare No, I work in applied cryptography. When I joined Amazon, the team I was hired on was called AWS Crypto Tools (which owned the AWS Encryption SDK, among other developer tools), while another team was
34.
by CiPHPerCoder 2y ago
> The main threat to encrypting health information is actually dishonest cryptographers. Wow, okay, you have me hooked. > instead of searching for user Michael Knight in a database of cancer patients, you hash the name, use a bloom fi
35.
by CiPHPerCoder 2y ago
> That said, it would be helpful for us i² [i squared] folks to have some of the more basic terms explained. Although "encryption at rest" is somewhat understandable, it would be pleasant to have it explained. That's helpf
36.
by CiPHPerCoder 2y ago
> Are you the author of the paragonie website? The coincidence was startling. If so, I greatly thank you for the resource. Thanks. Yes, I'm one of the authors.
37.
by CiPHPerCoder 2y ago
> I’d say the author is being so restrictive in the scope of threats that it isn’t very useful. Loss of control of the hard disks may have many different ways it can manifest in the real world, but from a cryptography and software develo
38.
by CiPHPerCoder 2y ago
> As someone who has issues remembering where they left their house keys at times, I want this on a bloody coffee cup/t-shirt. I've heard this quote a lot over the years, but the first person who said it was probably Lea Kiss
39.
by CiPHPerCoder 2y ago
It sounds to me like you read a different article than I wrote. The point of my article was not "Encryption-At-Rest Is Bad" as you seem to have taken it to mean. Rather, the point is that other techniques, when you sit down and
40.
by CiPHPerCoder 2y ago
Was it similar to this? https://github.com/facebookarchive/php-graph-sdk/pull/552#is...
41.
by CiPHPerCoder 2y ago
> Not sure what the state the art is in searchable encryption for db indexes, but just trying to do stuff that requires a scan becomes untenable due to having to read and decrypt on the client to find it or aggregate it. There are a lot
42.
Loss of Key Control Security in NIST SP 800-108(scottarc.blog)
1 points by CiPHPerCoder 2y ago|0 comments
43.
Encryption at Rest: Whose Threat Model Is It Anyway?(scottarc.blog)
2 points by CiPHPerCoder 2y ago|0 comments
44.
by CiPHPerCoder 2y ago
> In terms of JWT vs other ways of doing this, is there any evidence that JWTs are more vulnerable that other approaches? Clearly there are vulnerabilities is other approaches as well. Contrast JWTs with PASETO implementations when you m
45.
by CiPHPerCoder 2y ago
https://github.com/firebase/php-jwt/issues/351
46.
by CiPHPerCoder 2y ago
The vulnerability is usually in verifiers rather than signers. See, for example: https://github.com/firebase/php-jwt/issues/351
47.
by CiPHPerCoder 2y ago
> The article misses the point of JWT: it's dead simple to implement. Implementing it securely , however, is far from dead simple. https://scottarc.blog/2023/09/06/how-to-write-a-secure-jwt-l...
48.
by CiPHPerCoder 2y ago
> Packagist is mostly a graveyard of libraries that people have coded up for their exact niche use-case 8 years ago (with no updates since), with little flexiblity beyond that (like you would see for libraries in other ecosystems). Could
49.
by CiPHPerCoder 2y ago
This why I postulated "a new kind of cyber insurance" rather than what the industry has already cooked up. The implication is: This new insurance would be legally obligated to actually fund stuff.
50.
by CiPHPerCoder 2y ago
I've filed a bug in my backlog to add a doodle of a cool bear somewhere in the post.
51.
by CiPHPerCoder 2y ago
> One insurance company pays, they all benefit. Companies would simply wait for someone else to pay. There would need to be some kind of government agency forcing all of them to pay in. Sure, with some caveats: You can scope it down to o
52.
by CiPHPerCoder 2y ago
> What I don’t understand is why you are proposing a model (insurance) that doesn’t work in practice, and is susceptible to high levels of corruption. Why this would work differently in the case of open source. The legal/regulation
53.
by CiPHPerCoder 2y ago
> Just because it can by beaten doesn’t mean making it harder isn’t useful. Fair. > This person/team used a VPN. Masking your location is a big red flag for just dev work like this. These things could be exposed in UI. I disagree
54.
by CiPHPerCoder 2y ago
I've argued in a blog post [1] that we need to delineate between "open source developer" and "supplier". If we don't do that, calling thankless unpaid volunteers and hobbyists a "supply chain" is kind
55.
Open Source, Supply Chains, and Bears(scottarc.blog)
18 points by CiPHPerCoder 2y ago|14 comments
56.
by CiPHPerCoder 3y ago
Even funnier if you manage to click "Declassify" :)
57.
by CiPHPerCoder 3y ago
Hi. Blog post author here. There's multiple factors behind this. For one, the IETF already has a JOSE working group. This working group doesn't see it necessary to have a competing standard, and will stonewall any effort within th
58.
How to Write a Secure JWT Library If You Must(scottarc.blog)
3 points by CiPHPerCoder 3y ago|0 comments
59.
Innovations in the AWS Database Encryption SDK(scottarc.blog)
2 points by CiPHPerCoder 3y ago|0 comments
60.
Lucid Multi-Key Deputies Require Commitment(scottarc.blog)
2 points by CiPHPerCoder 4y ago|0 comments

More ›