> Choosing a strong-enough password is key (pun intended).
> Eventually I’ll fill in this paragraph. For now all you get is the obligatory XKCD: correct-horse-battery-staple
Might as well have a password generator in the tool itself.
151–160 of 385 posts
> Choosing a strong-enough password is key (pun intended).
> Eventually I’ll fill in this paragraph. For now all you get is the obligatory XKCD: correct-horse-battery-staple
Might as well have a password generator in the tool itself.
Earlier quoted context omitted.
Do you mind expanding? Specifically, what do you mean by de-golfed (I'm only vaguely aware of what 'kids' mean by code-golf these days, and I'm kinda lost on de-golfing). What would you like to fit into a QR code? A PortableSecret (e.g. html file)?
Not just QR code, may be small enough secrets fit in a URL (2KB I think is the limit)! See also the now defunct sharelock.io by Auth0: https://news.ycombinator.com/item?id=9109924 For creating and later validating magic-links (using Web APIs), I encode the IV, Salt, Cipher all in the URL as a single base64 token: https://github.com/celzero/otp/blob/cddaaa03f12f765fa8da9178... (Btw, reading through your code makes me…
(I was using AES-CBC before, that's why the padding is there)
This seems like a really good proof of concept to let browser vendors know they could create a super useful utility in their browsers. I mean, it's very cool all on it's own, and great job in building it! I'm just hopeful that someone is taking notes.
Earlier quoted context omitted.
Contrary to what Wikipedia says, I don't think agility is considered a desirable property by most cryptographers: you still have the "attacker stored encrypted material" problem, and now you have to worry about downgrade attacks. Many of the most interesting/effective attacks on SSL/TLS have been downgrade attacks that stem directly from the protocol's (historically) agile design.
I disagree with your speculation as to what most cryptographers think. Are you basing this on any data you can share? Please also see the other thread about how this secret storage system is different from a communication protocol. Namely, communication protocols have a two step attack: first attacker must MITM and record ciphertext, then they must wait. This secret storage method is different (one step attack): atta…
No, just conversations. I'll admit it's just speculation.
Maybe I should qualify: there's "cryptographic agility" in the protocol sense (a single version of a protocol can accept a wide range of primitives, with the idea being that users can upgrade their primitives as old ones become insecure), and there's "cryptographic agility" in a more abstract design sense: wire formats, etc. should be devolved from the primitives in such a way that the protocol can be switched to secure primitives without requiring unrelated changes, and in a way that doesn't surface any differences to the user.
To my understanding, the first sense of "cryptographic agility" is widely discouraged: we've yet to figure out a really reliable way to provide backwards compatibility without enabling malicious downgrades. The second sense is not something I've heard people use the phrase "cryptographic agility" for, but that's possibly just ignorance on my part. If that is indeed another form of agility, I believe that's widely considered to be good design (and this design is "agile" in that sense, since existing messages do not compromise the security of an upgraded scheme).
> Crack me if you can This reminds me of LifeLock CEO's Todd Davis public challenge [1] when he revealed his Social Security number prominently on his site and billboards with overconfidence that his identity cannot be stolen but, unfortunately, he's been a victim of identity theft at least 13 times. 1. https://www.wired.com/2010/05/lifelock-identity-theft/
He also ended up leaving the company after it was learned he was guilty of a previous felony for identity fraud.
To me this feels like a merger of the ideas in projects like magic-wormhole, Wormhole.app, and the (defunct) Mozilla Send. But then it adds a kind of sharchive twist using the browser as a runtime.
The original paper I saw called it Password Authenticated Key Exchange. https://www.cs.columbia.edu/~smb/papers/neke.pdf
But I think the general form is now called something like this: https://en.wikipedia.org/wiki/Password-authenticated_key_agr...
Anyway I’m posting all this not to show my erudition (I’m really stupid about cryptography) but that there’s lots of precedent for this kind of tool and maybe with a few tweaks can even be made standards-compliant. (RFC 8188 seems to contemplate some ideas like this, but the file isn’t “self-expanding”.)
Some obvious issues: sitting on a thumb drive, the file is vulnerable to unlimited attacks. And since the decryptor is in “plaintext” it could be MITMed in a way, since the decryption code can be tampered with, and a browser environment with localhost access can be tricked into doing lots of things, including sending decrypted contents to the attacker. In a SaaS there’s no MITM given transport security, and you can notice you’re getting attacked, or expire links after a number of tries / some amount of time.
But so what; the whole point here is to provide really good security with a different channel.
I've been thinking about something similar, it really should be much easier to send encrypted messages. I'm not sure if this is a problem, but one thing that is unclear to me is how/if this protects against an adversary that can modify the html file. If the adversary can modify the HTML file in transit they can just add some code that sends the password to the adversary's server when the real recipient opens the file…
While it's very real in theory, I am not concerned in practice.
If I am the target of a sophisticated attacker, there are easier and more effective ways to pwn me.
A few other comments reference the same, e.g.: https://news.ycombinator.com/item?id=34085245
Earlier quoted context omitted.
All words appear in some wordlist. This is the kind of password I use to protect my actual secrets. So if someone is able to crack it, I'd like to know. The bounty is for a 'realistic' use case.
If you want to avoid wordlist vulnerabilities, try this: Choose a lyric from a favorite song. Concatenate the first letter of each word in the lyric. Example: “Rock the Casbah Sharif don't like it” Becomes: rtcsdli Add capitalization or numbers/special characters according to your own pref. For example, maybe your decide to alternate lower and upper case and always end with a bang: rTcSdLi! Although you have to use t…
Nice idea. password protected zip files are portable too.
https://security.stackexchange.com/questions/35818/are-passw...
See here if interested: https://github.com/mihaigalos/pass