We use a very similar system at work when placing files on removable media. Normally, any files you move from a work PC to a flashdrive are encrypted and cannot be decrypted unless the drive is put into another work PC running the same security software. However there's a feature of the software that still lets you move files to off-network PCs that works just like this. Your files are encrypted like usual but you can use your own password and there's now an html file included that contains all of the necessary crypto libraries. You open the html file on the other PC, type in the password, and it decrypts it for you and can re-encrypt it if you'd like.

Thank you for the insightful comments.

Not looking for users TBH. :-)

re: bug in the vendor implementation of cryptography. Doesn't this apply to everything you encrypt?

I think the parent comment is talking about a defense-in-depth approach: if crypto is your only defense against a worst-level outcome, you don't have any grace if your adversary can exploit a crypto weakness. With perimeter defenses you have a little more leeway in responding to eg leaked keys or other problems. Also presumably you know who might have retrieved the encrypted data, and therefore who might be doing offline attacks against the data.

There are totally use cases where having encrypted data at publicly retrievable, even well-known URIs makes sense, but there are other use cases where you want some level of network security as well.

Anytime.

Re your question: of course. There are some things to consider:

1. These files do seem to have some persistence on either the sender’s, the recipient‘s or a shared machine. With long persistence in several places, the risk of unwanted access is being elevated. (Cloud instances and identity providers get popped, machines get viruses, etc) 2. As mentioned by a sibling comment, the encryption is your only layer of protection. 3. Browser’s are probably one of the top three targets of vulnerability researchers at the moment. They were at the number one spot 2-3 years ago.

When a vulnerability is found in the implementation, the missing controls become a problem. Your quote about 0days is certainly correct. At some point it won’t be an 0day anymore though, and it’s hard to convince people to rummage through their hard drive to delete some files.

> Someone adversarial to me could bribe a number of people to get answers to 10 different password hints.

OP's hints are probably more generous than they need to be. (Indeed, knowing that password is name + flower + name + two-word-thing, plus the fact that there is no limit to the speed you could brute-force this, means that someone could probably make a custom dictionary and break this in a couple days.)

But you can easily have hints and make it harder. In Evernote I store a few passwords to things, and the hints are more opaque ("grey" refers to my old grey cat, for instance) but they're also all prepended with a 15-character master password that changes in subtle ways depending on the service they're used for. This isn't in the hint, it's just in my head.

>knowing that password is name + flower + name + two-word-thing, plus the fact that there is no limit to the speed you could brute-force this, means that someone could probably make a custom dictionary and break this in a couple days

Off topic, but in principle a sufficiently expensive key derivation could guard against this, right? Is there a reason why it isn't done? I wouldn't mind waiting a few minutes for my identity document to decrypt if I hardly ever access it. In that case the usability benefit of a fast key derivation algorithm seems minor.

It wouldn't even be hard to expose this functionality via a user interface -- say when a user is setting up a Portable Secret, let them click to select a security level between "low security" and "high security", where each security level corresponds to an estimated number of minutes it will take the secret to decrypt on a modern PC. Seems like it would make intuitive sense to grandma.

And with regard to the software vulnerabilities topic discussed above, as long as we're waiting a few minutes, we might as well make use of multiple key derivation algorithms in case one or more of them is shown to be weak.

I have things like this in my head too and I wonder if I’ll forget when I get elderly.

or bonked on the head. it's a scary thought.

I've thought of that too, perhaps I write them down in a sealed envelope and tell my spouse or kid, only open in an emergency. I feel it's pretty certain these non-software engineers in my family have less security notions than I do, so I have reserved some passwords that are in my head.

I signed up for the gmail "I died, here is my account" option.

I don't know if I should do that gmail thing or not...afraid it'll mess up or I'll forget about it.

Can the spouse resist opening an envelope? I don't know. Maybe I just hide it in our files and hope she finds it if I die, but not before.

Do you trust Evernote? I think the employee are able to read private notes

Yes, they can. Evernote, the company, really pushes their "everything is encrypted" mantra, but you have to really push them to get them to admit that it's only encrypted in transit. On their server storage, the data is encrypted using their key, so if someone stole a drive or a disk image they wouldn't be able to read it, but any number of people at Evernote would have full access to anyone's data.

That's why my hints are opaque and exclude the long, mutable master password.

If someone did actually find a vulnerability, I would assume they are pretty good at what they do, but wouldn't they just wait for adoption and let this bounty inflate higher before draining it?