codysc

Distance learning is manageable for my kids as they're a little older and I can work from home. But families with younger kids where both parents have to go out to work and can't possibly afford childcare are getting hammered.

As always, the poor get the worse of the effects, and children are really compounding that right now.

Comment · 6 years ago

I don't think I exactly understand your points.

Using an example of IV reuse in AES-GCM:

The weaknesses resulting from this wouldn't be discoverable with a test like corrupting the password from the first example. If the developer wasn't aware that IV reuse introduced that weakness then they would be using strong primitives but in a way that dramatically undermines the actual encryption.

Not to put words in your mouth, but I assume your answer would be to say that this would be a matter of correctness. If yes, then where I'm coming from is that the majority of devs don't have the skillset to be correct and sometimes wouldn't dive deep enough to discover these kinds of pitfalls.

Comment · 6 years ago

Yes, the goal was/is to start with a very high level example then get more into crypto specific concerns.

The audience is for devs without any real experience/knowledge of using crypto that might go into it too casually.

Comment · 6 years ago

>Perhaps surprisingly, implementing cryptographic primitives & protocols requires little cryptographic knowledge.

That's a dangerous statement on it's own. Making proper use of primitives is not at all a simple concept. Developers can absolutely undermine their systems with poor choices/mistakes.

Self promotion: I wrote a blog up on a very high level screw up with type conversions to show just the very surface of how to screw up using solid crypto primitives. Time allowing I want to do more entries on topics within the crypto realm itself. IV reuse, etc.

https://pritact.com/blog/posts/crypto-mistakes-part-1.html

Comment · 6 years ago

You're not alone. This has always felt scammy. It's a little more gray-area than some of the traditional vapor-ware which was more about driving competition out of business by large players, but still something I try to avoid.

Comment · 6 years ago

I don't see PBKDF2 as a full footgun, but maybe as the minimally still-acceptable method. When I was building my system for E2E messaging (pritact.com) I started out with PBKDF2 but kept mentally revisiting the iteration count before biting the bullet and switching to Argon2.

Actually it looks like Argon2 is being discussed as of just a couple hours ago https://community.bitwarden.com/t/switch-to-argon2/350/24

Comment · 6 years ago

Free is a big part of the problem. The existence of free tools in a space, that are paid for with data gathering, crowds out the market for paid competitors that operate in a more privacy friendly manner.

Comment · 6 years ago

Re: Terms

I read through a good amount and I think they make sense. The short version helps, but that always worries me from a legal standpoint. If we summarize something in a legally ambiguous way have we undermined the original intent?

There are some inconsistencies with how you present the data that I think would help to smooth out. On your summary table. You start with the description being more of a goal for that section, than sporadically start switching to the "short version" of what your terms are.

For me I was hoping that it would be the short-version so I essentially get a comprehensive cliff-notes kind of view.

Also some minor issues with bolding some headers 4. Project Termination 4. Survival

As well as inconsistently formatting the short version. (I prefer the all bold version to help clearly show where the short part ends)

Privacy policies are much easier for me to wrap my head around. What you store, How you store it, and what you do with it.

This clause was a good idea that I will "borrow":

If our corporate structure or status changes (e.g., if we restructure, are acquired, or go bankrupt), we will notify all users so that you may choose to anonymize or delete your private data before we pass on any data to a successor or affiliate.

My version is here https://www.pritact.com/privacy-policy.html which I think follows along a lot with yours in spirit, but just has less ground to cover because of the nature of my platform.

Comment · 6 years ago

This makes a lot of sense. Providing some kind of categorized/easily digestible format for the policy to fit into. When I was writing mine I tried to be very clear, but my startup is specifically focused on privacy, so I didn't really have much to disclose.

Comment · 6 years ago

Yes, that kinda HSMish model of non-extractable keys is a very nice touch. I really wish they would add Argon2 though. PBKDF2 is still a valid choice but there are a lot of HW optimized solvers out there for it.