6 ms·

MiniLock – File encryption software that does more with less

139 points by poolpool 12y ago

deleted 12y ago
[deleted]
- jacobkg 12y ago
  Generally, one would use a Hybrid Encryption scheme: http://en.wikipedia.org/wiki/Hybrid_cryptosystem http://en.wikipedia.org/wiki/Hybrid_cryptosystem The file would be encrypted using a symmetric encryption scheme (like AES), and then the key for decrypting it would be encrypted to each recipient. Adding an extra recipient then just involves encrypting the 128 or 256 bit key, which should be negligible increase in size.
- Someone 12y ago
  I would use a secret key to encrypt the file, then encrypt the decryption key with each of the keys of those recipients, and add each (user ID, encrypted decryption key) to the file. Reading the linked page, that's exactly what they do (with a nonce to thwart various (differential, known plaintext, etc.) attacks) The header itself is a stringified JSON object which contains information necessary for the recipients to decrypt the file. The JSON object has the following format: { senderID: Sender's miniLock ID, fileInfo: { (One copy of the below object for every recipient.) Unique nonce for decrypting this object (Base64): { fileKey: Key for file decryption (Base64), fileName: The file's original filename (String), fileNonce: Nonce for file decryption (Base64), } (Encrypted with shared secret derived from the sender’s private key and recipient's public key. Stored as Base64 string.) } } Note that in the above header, fileName is padded with the 0x00 byte until it reaches 256 bytes in length. This is done in order to prevent the discovery of the fileName length purely by analyzing an encrypted miniLock file’s header.
  - tveita 12y ago
    Exercise: This padding scheme will not hide the length of the file name as intended. Why?
    - lolbrainwallets 12y ago
      AAAAAAAAAAAAAAAAA...
wyager 12y ago
Existing research strongly suggests that deriving asymmetric keys from human-provided seeds (i.e. passphrases) and nothing else is strongly inadvisable. This is because it is possible to attack large numbers of passphrases at once, and it is possible to harvest large numbers of targets from public databases of public keys. Additionally, entropy estimation tools generally are not good at accounting for the fact that human behavior results in non-obvious biases and patterns in passphrase selection. To see an example of this model failing on a large scale, look at the number of Bitcoin "brain wallets" that have been hacked, despite having apparently strong keys.
- capnrefsmmat 12y ago
  > This is because it is possible to attack large numbers of passphrases at once Do you mean some kind of rainbow table attack, where you go through a dictionary and derive keypairs for every likely password? Then you could match any public key to the precomputed private key. I'm not familiar enough with ECC to know if this is feasible, but it seems like an obvious weakness of the system.
  - wyager 12y ago
    Yeah, the fact that breaking this cryptosystem is essentially equivalent to attacking unsalted passwords means that an attacker can save a lot of work. Also, this simplifies setting up the attack in general. For example, attacking a bunch of keys based on random data + passwords is way harder than attacking keys based on just passwords, because for the former you must also have the random data (which presumably is not posted online in massive troves).
- Scaevolus 12y ago
  I've been working on generating memorable passphrases with provable entropy: http://rmmh.github.io/abbrase/ http://rmmh.github.io/abbrase/ They work well for me, but some people dislike the abbreviation aspect. I'm investigating how to make a grammar-based engine (rather than bigram-based) for smaller data files and better phrases.
  - 12y ago
simik 12y ago
Small UX nitpick. You can't select the miniLock ID by double-clicking it. I think it was one of the reasons bitcoin used Base58 encoding.
- dchest 12y ago
  Indeed, Base58 encoding would be preferable. I filed an issue https://github.com/kaepora/miniLock/issues/3 https://github.com/kaepora/miniLock/issues/3
- 178 12y ago
  Afaik the main reason for base58 is making it impossible to mistake an 'I' for an 'l', etc. Beeing able to always double-click is a nice added bonus, though.
lolbrainwallets 12y ago
This is a bad cryptosystem which will result in people being fucked. Take it offline. A serious known weakness of zxcvbn is that it will grossly overestimate the entropy of things like quotes, lines from songs, lines from movies, etc. "the quick brown fox jumps over the lazy dog" has 111 bits of entropy according to zxcvbn.
- rando289 12y ago
  It is in a "a feedback period", exactly so they can get the feedback like you just gave. So get off your high horse about taking things down.
  - CHY872 12y ago
    Not really. The feedback period is for things like UX etc - this essentially makes the software (as usual for these homebrew efforts) much less secure than you think it is. When the primary reason that this software is at all secure is that it enforces a minimum entropy, if there's a bug in that then no one should use the software.
    - rando289 12y ago
      I don't see any evidence of the feedback being "for things like UX" I also don't think the word homebrew is appropriate. Afaik homebrew means, 1 making beer at home. 2 apple package manager. 3. Term generally for endeavours connected to corporate products/projects but themselves small and independent.
- ff7c11 12y ago
  Yeah use of zxcvbn is a problem. Minilock's key strength checking goes[0]: key.length > 32 && zxcvbn(key).entropy > 100 Firstly minilock allows the following: zxcvbn(". . . . . . . . . . . . . . . . ").entropy = 161.421 [1] Secondly this only really works for English. While they are used to being forced to use English passwords, we can't expect that speakers of other languages would like English passphrases. It also has heuristics making assumptions of how people choose passwords (e.g. l33tifying) which may be less valid for longer phrases than short passwords. zxcvbn uses all English word lists and keyboard layout and automatically gives you a Unicode bonus[2] if you use unexpected characters. If I write a sentence in Chinese, I have a high entropy. Here minilock actually penalises Chinese by adding the key.length > 32 requirement as 32 Chinese characters is equivalent to a much longer English passphrase. I suggest lowering the key length requirement in this case. However, if my passphrase were in Arabic and my attacker knew it was likely to be in the Arabic alphabet, I'm not really entitled to the aforementioned Unicode bonus as the entropy drops to be similar to English (I think). That said, the design decisions of zxcvbn do make sense for Dropbox and zxcvbn is not the crucial part of the minilock program (the crypto is). Users will always find a way to game the system and find the lowest possible entropy passphrase. [0] https://github.com/kaepora/miniLock/blob/80aff2cdbcebf669faedcd12f61dafa5d1bc34cd/src/js/miniLock.js#L177 https://github.com/kaepora/miniLock/blob/80aff2cdbcebf669fae... [1] https://github.com/dropbox/zxcvbn/issues/39 https://github.com/dropbox/zxcvbn/issues/39 [2] https://github.com/dropbox/zxcvbn/blob/0a8b5b65a1864437eaac5b8828571c835cce28f0/scoring.coffee#L250 https://github.com/dropbox/zxcvbn/blob/0a8b5b65a1864437eaac5...
kijin 12y ago
Perhaps I'm missing something obvious, but I don't understand. What's so great about not having to store the key pair on disk? After all, this is a file encryption software. Its job is to store data on disk. In fact, it already adds a bunch of headers to every encrypted file. Why not just grab 128 random bits from /dev/urandom, make it the private key, encrypt it with the passphrase as all the other programs do, and stick the encrypted key in the header? It will only add a few dozen bytes to the header, which is peanuts.
- ff7c11 12y ago
  I think so you can use it from any computer anywhere with just the passphrase to derive the key and don't need to carry and secure a file.
  - akerl_ 12y ago
    If you're entering your passphrase on systems you don't control, it's already game over for that passphrase.
    - woah 12y ago
      This comment is a perfect example of why encryption is mostly not used at all. (Which is far worse than any given vuln). There's kind of a perverse all-or-nothing attitude where the goal is to poke at any possible flaw in a system as proof that it is completely worthless. What's wrong with there being different tradeoffs between security and convenience? The insistence on all-or-nothing solutions has resulted in the powers that be knowing almost everything about almost everyone in our society, because almost no one wants to deal with the trouble of "completely secure" encryption.
- nine_k 12y ago
  If there are no media with your secret key, it can't be stolen. Of course, if your computer is cracked into, or your adversaries are using rubber-hose cryptanalysis, all bets are off. But this scenario is usually less probable than having your physical wallet or keychain stolen.
gdi2290 12y ago
dat weissman score
deathanatos 12y ago
But wait… if the entire key is derived from the passphrase, if two people both choose the passphrase "password", would they not then get the same public and private keys? Can I not brute force people's private keys by taking millions of common passwords¹ and generating public keys from them, and then seeing which ones match my friends? Am I wrong? Doesn't this seem much easier to brute force than a RSA key? (Presuming the private key hasn't been compromised; if it has, it's likely protected by a password, and then these two are about equal.) ¹accepting that some will get rejected because of "uses the zxcvbn library in order to impose a strict limit on the amount of detected entropy present in entered passphrases. miniLock will not allow passphrases that fall below the threshold of 100 bits of entropy"
- diafygi 12y ago
  Yes, and it clearly stated in the demo[1]. The key feature that this approach is trying to accomplish is allowing the user to not have to store anything beyond a password. Keeping track of a keyfile is HARD for a lay-user, so miniLock is trying to do the best it can securing files with only a password. [1] - https://github.com/kaepora/miniLock/blob/master/src/index.html#L37 https://github.com/kaepora/miniLock/blob/master/src/index.ht...
  - akerl_ 12y ago
    Except that since there's no salt or other measures involved, there isn't even a trivial protection against rainbow tables letting me create one table and crack all the passwords. It's using ECC as a fun buzzword but tossing all the actual realworld benefits of key-pair crypto out the window by having a single user-provided string map to a single keypair.
    - diafygi 12y ago
      Alright, what do you propose? As I said, dealing with keyfiles is HARD for the lay-user.
      - sillysaurus3 12y ago
eliteraspberrie 12y ago
I am not a cryptographer, but I'll offer some advice, if I may: don't let people choose a passphrase, generate one for them. People are very bad at creating good passphrases, but decent at memorizing a good one. I say that because I don't trust the zxcvbn library. It underestimates the entropy of "aaaaa" as 7 bits [log(26 * 5)], not the correct value of 23 bits [log(26) * 5], for example. In this instance, it's to your advantage, but it doesn't inspire confidence in its other calculations.
- lolbrainwallets 12y ago
  zxcvbn has problems but your example is backwards. "aaaaa" gets (as it should) low entropy because it is a single repeated character. It is more likely to be used than "rqntd". The major limitations are that it is worthless for estimating entropy of passphrase (which is what it's being used for here) and words not in its dictionary (non english).
  - eliteraspberrie 12y ago
    My mistake, zxcvbn uses that formula only for repetitions.
- deleted 12y ago
  [deleted]
Toad_King 12y ago
The overview literally just sounds like encrypted archive files. How is this different from putting a password on a .7z or .rar file?
- SomeCallMeTim 12y ago
  They aren't sending the PASSWORD in the clear, they're sending (effectively) a public key. Bob sends public key to Alice. Alice uses public key to encrypt file and sends to Bob. ONLY Bob can decrypt the file (using his PRIVATE key). If you sent a password, then anyone who intercepted it AND the encrypted archive would be able to decrypt it.
  - MrUnknown 12y ago
    seems that how they generate the keys, it's basically the same. The same password would generate the same keys. Anyone who uses the same password would be able to decrypt data sent to anyone else using the same password. Am I understanding this correctly?
    - DiThi 12y ago
      If I send you an encrypted file with minilock, you won't know my password, and I won't know yours, but you'll be the only one that can read it, and also you'll be sure I've sent it and not anyone else. Public key crypto has more advantages and users should understand the basics. This introduction may be more clear (4:30) https://www.youtube.com/watch?v=vMiBwMHcSn0 https://www.youtube.com/watch?v=vMiBwMHcSn0 Also I would only use their 7-random-words feature for passwords.
achivetta 12y ago
I think the hesitations about passphrase being subject to brute force, rainbow table, etc. are warranted, but I have another concern: If my passphrase gets compromised, I have to retire the keypair. That's true of a key file with current asymmetric systems; but, presently if the passphrase of my GPG private key is compromised (e.g. by a hardware key logger), I only have to change the passphrase and ensure the old keyfiles are destroyed. With MiniLock, if my passphrase is compromised the entire key material is compromised and I need to revoke the public key. But how do I revoke it? Do I tweet a message with the private key saying the public key is revoked? Will there be a centralized place to publish revocation messages? Efficient key revocation will be absolutely critical to this system and that's hard if the key distribution mechanism is tweets or some other ad hoc mechanism. This is one thing that PGP key servers really help with.
- selimthegrim 12y ago
  I actually approached Kobeissi with this point in the meeting in Noisy Square right after the talk, suggesting he integrate a TPM into his key management system (like how you can call out to one in Firefox for SSL with libpkcs5.so or some similarly named library). He responded that the specs were open enough that anyone could add that in. As to a centralized place your guess is as good as mine. Also can MacBook users even access their TPMs?
  - BuildTheRobots 12y ago
    Depending on who you're protecting against you might want to _really_ avoid trusting your TPM.
    - higherpurpose 12y ago
      Yeah, I wouldn't trust the TPM - certainly not from a Windows machine, and not even an Apple one after the recent revelations/research, which shows Apple tries to make the device secure against "regular" hackers, but very easy to access by Apple itself or the US government.
rgj 12y ago
Relying on a passphrase only is not good enough. Enter it once on a compromised system and it's game over. Since your ID is tied to your passphrase you even have an issue and you will need to revoke your public key. Many years ago, people realised you need to rely on something more than knowledge (of a password/passphrase) alone. Pick any two out of {something you know,something you own,something you are}, the latter being implemented by biometry. That's why you need your ATM card, and why it has a PIN code. This is a step back into a world were security wasn't good enough. Security is more than crypto alone, it's mainly about keeping things secret. There are too many ways a passphrase could be compromised or discovered. This approach focuses too much on the crypto aspects, and not enough on all the other things involved in building something that is secure.
- zimbatm 12y ago
  > Enter it once on a compromised system and it's game over. It's the same issue with PGP. Instead of capturing the password it captures the decrypted private key.
- chacham15 12y ago
  > Enter it once on a compromised system and it's game over The same is true of any heavily used system today. All systems: banks, credit cards, facebook, etc. use "something you know". "Something you own" has just recently picked up steam in the form of two factor authentication, but then again, how many people you know actually use that? The only thing that I know of/heard of that might hold up against the type of attack that you describe is the behavioral keys: i.e. a key which is something about you that you dont necessarily know yourself, e.g. your style of chess, or your phrasing of sentences.
viralpoetry 12y ago
Some times ago I created my own file encryption software using libsodium. It uses XSalsa20, hmacsha256, pbkdf. It hide password input on the terminal. It is really slow for large files (GBs)... https://github.com/viralpoetry/VPcrypt https://github.com/viralpoetry/VPcrypt
- dchest 12y ago
  Yours uses symmetric keys while miniLock is public-key crypto (crypto_box in NaCl terms).
  - viralpoetry 12y ago
    Thank you for checking it out. I used it just myself, hence symmetric crypto only.
polvi 12y ago
MiniLock looks like a great option to introduce encryption to my non-technical friends. The alternative to minilock right now, for these users, is to do nothing. Even if we do not like it, right now state of the art on file sharing (for most of the non-technical world) is an unencrypted email attachment. MiniLock looks like it might be something I can install on my mothers (non-technical) computer so that I can send her a sensitive doc (copy of my tax return, for example). This crypto system is sufficient for that use case, and the alternative is to do nothing at all. The alternatives are not GPG, or RSA, or whatever, because outside of the technical community people have no idea how to use these things.
- napoleond 12y ago
  Exactly! When it comes to crypto apps, I have noticed two kinds of criticism: "This software is not built for the threat models that interest me" and "This software fails to properly address the threat model it claims to". Too often, commenters will act as though their critique belongs in the second category when it really belongs in the first. (It's great to question the design goals of a project! But that's very different from saying that a project fails to do what it says. In this case, Minilock has very clearly accepted a threat model where, if the passphrase is compromised, that's the game. If you don't like that, don't use it!)
edoceo 12y ago
My favourite is that the Tweet has be come some standard of measure "fit inside less than half a tweet". Not less than 70 characters; "less than half a tweet".

139 points by poolpool 12y ago

deleted 12y ago

[deleted]

jacobkg 12y ago
Generally, one would use a Hybrid Encryption scheme: http://en.wikipedia.org/wiki/Hybrid_cryptosystem http://en.wikipedia.org/wiki/Hybrid_cryptosystem The file would be encrypted using a symmetric encryption scheme (like AES), and then the key for decrypting it would be encrypted to each recipient. Adding an extra recipient then just involves encrypting the 128 or 256 bit key, which should be negligible increase in size.
Someone 12y ago
I would use a secret key to encrypt the file, then encrypt the decryption key with each of the keys of those recipients, and add each (user ID, encrypted decryption key) to the file. Reading the linked page, that's exactly what they do (with a nonce to thwart various (differential, known plaintext, etc.) attacks) The header itself is a stringified JSON object which contains information necessary for the recipients to decrypt the file. The JSON object has the following format: { senderID: Sender's miniLock ID, fileInfo: { (One copy of the below object for every recipient.) Unique nonce for decrypting this object (Base64): { fileKey: Key for file decryption (Base64), fileName: The file's original filename (String), fileNonce: Nonce for file decryption (Base64), } (Encrypted with shared secret derived from the sender’s private key and recipient's public key. Stored as Base64 string.) } } Note that in the above header, fileName is padded with the 0x00 byte until it reaches 256 bytes in length. This is done in order to prevent the discovery of the fileName length purely by analyzing an encrypted miniLock file’s header.
- tveita 12y ago
  Exercise: This padding scheme will not hide the length of the file name as intended. Why?
  - lolbrainwallets 12y ago
    AAAAAAAAAAAAAAAAA...

wyager 12y ago

Existing research strongly suggests that deriving asymmetric keys from human-provided seeds (i.e. passphrases) and nothing else is strongly inadvisable. This is because it is possible to attack large numbers of passphrases at once, and it is possible to harvest large numbers of targets from public databases of public keys. Additionally, entropy estimation tools generally are not good at accounting for the fact that human behavior results in non-obvious biases and patterns in passphrase selection. To see an example of this model failing on a large scale, look at the number of Bitcoin "brain wallets" that have been hacked, despite having apparently strong keys.

capnrefsmmat 12y ago
> This is because it is possible to attack large numbers of passphrases at once Do you mean some kind of rainbow table attack, where you go through a dictionary and derive keypairs for every likely password? Then you could match any public key to the precomputed private key. I'm not familiar enough with ECC to know if this is feasible, but it seems like an obvious weakness of the system.
- wyager 12y ago
  Yeah, the fact that breaking this cryptosystem is essentially equivalent to attacking unsalted passwords means that an attacker can save a lot of work. Also, this simplifies setting up the attack in general. For example, attacking a bunch of keys based on random data + passwords is way harder than attacking keys based on just passwords, because for the former you must also have the random data (which presumably is not posted online in massive troves).
Scaevolus 12y ago
I've been working on generating memorable passphrases with provable entropy: http://rmmh.github.io/abbrase/ http://rmmh.github.io/abbrase/ They work well for me, but some people dislike the abbreviation aspect. I'm investigating how to make a grammar-based engine (rather than bigram-based) for smaller data files and better phrases.
- 12y ago

simik 12y ago

Small UX nitpick. You can't select the miniLock ID by double-clicking it. I think it was one of the reasons bitcoin used Base58 encoding.

dchest 12y ago
Indeed, Base58 encoding would be preferable. I filed an issue https://github.com/kaepora/miniLock/issues/3 https://github.com/kaepora/miniLock/issues/3
178 12y ago
Afaik the main reason for base58 is making it impossible to mistake an 'I' for an 'l', etc. Beeing able to always double-click is a nice added bonus, though.

lolbrainwallets 12y ago

This is a bad cryptosystem which will result in people being fucked. Take it offline. A serious known weakness of zxcvbn is that it will grossly overestimate the entropy of things like quotes, lines from songs, lines from movies, etc. "the quick brown fox jumps over the lazy dog" has 111 bits of entropy according to zxcvbn.

rando289 12y ago
It is in a "a feedback period", exactly so they can get the feedback like you just gave. So get off your high horse about taking things down.
- CHY872 12y ago
  Not really. The feedback period is for things like UX etc - this essentially makes the software (as usual for these homebrew efforts) much less secure than you think it is. When the primary reason that this software is at all secure is that it enforces a minimum entropy, if there's a bug in that then no one should use the software.
  - rando289 12y ago
    I don't see any evidence of the feedback being "for things like UX" I also don't think the word homebrew is appropriate. Afaik homebrew means, 1 making beer at home. 2 apple package manager. 3. Term generally for endeavours connected to corporate products/projects but themselves small and independent.
ff7c11 12y ago
Yeah use of zxcvbn is a problem. Minilock's key strength checking goes[0]: key.length > 32 && zxcvbn(key).entropy > 100 Firstly minilock allows the following: zxcvbn(". . . . . . . . . . . . . . . . ").entropy = 161.421 [1] Secondly this only really works for English. While they are used to being forced to use English passwords, we can't expect that speakers of other languages would like English passphrases. It also has heuristics making assumptions of how people choose passwords (e.g. l33tifying) which may be less valid for longer phrases than short passwords. zxcvbn uses all English word lists and keyboard layout and automatically gives you a Unicode bonus[2] if you use unexpected characters. If I write a sentence in Chinese, I have a high entropy. Here minilock actually penalises Chinese by adding the key.length > 32 requirement as 32 Chinese characters is equivalent to a much longer English passphrase. I suggest lowering the key length requirement in this case. However, if my passphrase were in Arabic and my attacker knew it was likely to be in the Arabic alphabet, I'm not really entitled to the aforementioned Unicode bonus as the entropy drops to be similar to English (I think). That said, the design decisions of zxcvbn do make sense for Dropbox and zxcvbn is not the crucial part of the minilock program (the crypto is). Users will always find a way to game the system and find the lowest possible entropy passphrase. [0] https://github.com/kaepora/miniLock/blob/80aff2cdbcebf669faedcd12f61dafa5d1bc34cd/src/js/miniLock.js#L177 https://github.com/kaepora/miniLock/blob/80aff2cdbcebf669fae... [1] https://github.com/dropbox/zxcvbn/issues/39 https://github.com/dropbox/zxcvbn/issues/39 [2] https://github.com/dropbox/zxcvbn/blob/0a8b5b65a1864437eaac5b8828571c835cce28f0/scoring.coffee#L250 https://github.com/dropbox/zxcvbn/blob/0a8b5b65a1864437eaac5...

kijin 12y ago

Perhaps I'm missing something obvious, but I don't understand. What's so great about not having to store the key pair on disk? After all, this is a file encryption software. Its job is to store data on disk. In fact, it already adds a bunch of headers to every encrypted file. Why not just grab 128 random bits from /dev/urandom, make it the private key, encrypt it with the passphrase as all the other programs do, and stick the encrypted key in the header? It will only add a few dozen bytes to the header, which is peanuts.

ff7c11 12y ago
I think so you can use it from any computer anywhere with just the passphrase to derive the key and don't need to carry and secure a file.
- akerl_ 12y ago
  If you're entering your passphrase on systems you don't control, it's already game over for that passphrase.
  - woah 12y ago
    This comment is a perfect example of why encryption is mostly not used at all. (Which is far worse than any given vuln). There's kind of a perverse all-or-nothing attitude where the goal is to poke at any possible flaw in a system as proof that it is completely worthless. What's wrong with there being different tradeoffs between security and convenience? The insistence on all-or-nothing solutions has resulted in the powers that be knowing almost everything about almost everyone in our society, because almost no one wants to deal with the trouble of "completely secure" encryption.
nine_k 12y ago
If there are no media with your secret key, it can't be stolen. Of course, if your computer is cracked into, or your adversaries are using rubber-hose cryptanalysis, all bets are off. But this scenario is usually less probable than having your physical wallet or keychain stolen.

gdi2290 12y ago

dat weissman score

deathanatos 12y ago

But wait… if the entire key is derived from the passphrase, if two people both choose the passphrase "password", would they not then get the same public and private keys? Can I not brute force people's private keys by taking millions of common passwords¹ and generating public keys from them, and then seeing which ones match my friends? Am I wrong? Doesn't this seem much easier to brute force than a RSA key? (Presuming the private key hasn't been compromised; if it has, it's likely protected by a password, and then these two are about equal.) ¹accepting that some will get rejected because of "uses the zxcvbn library in order to impose a strict limit on the amount of detected entropy present in entered passphrases. miniLock will not allow passphrases that fall below the threshold of 100 bits of entropy"

diafygi 12y ago
Yes, and it clearly stated in the demo[1]. The key feature that this approach is trying to accomplish is allowing the user to not have to store anything beyond a password. Keeping track of a keyfile is HARD for a lay-user, so miniLock is trying to do the best it can securing files with only a password. [1] - https://github.com/kaepora/miniLock/blob/master/src/index.html#L37 https://github.com/kaepora/miniLock/blob/master/src/index.ht...
- akerl_ 12y ago
  Except that since there's no salt or other measures involved, there isn't even a trivial protection against rainbow tables letting me create one table and crack all the passwords. It's using ECC as a fun buzzword but tossing all the actual realworld benefits of key-pair crypto out the window by having a single user-provided string map to a single keypair.
  - diafygi 12y ago
    Alright, what do you propose? As I said, dealing with keyfiles is HARD for the lay-user.
    - sillysaurus3 12y ago

eliteraspberrie 12y ago

I am not a cryptographer, but I'll offer some advice, if I may: don't let people choose a passphrase, generate one for them. People are very bad at creating good passphrases, but decent at memorizing a good one. I say that because I don't trust the zxcvbn library. It underestimates the entropy of "aaaaa" as 7 bits [log(26 * 5)], not the correct value of 23 bits [log(26) * 5], for example. In this instance, it's to your advantage, but it doesn't inspire confidence in its other calculations.

lolbrainwallets 12y ago
zxcvbn has problems but your example is backwards. "aaaaa" gets (as it should) low entropy because it is a single repeated character. It is more likely to be used than "rqntd". The major limitations are that it is worthless for estimating entropy of passphrase (which is what it's being used for here) and words not in its dictionary (non english).
- eliteraspberrie 12y ago
  My mistake, zxcvbn uses that formula only for repetitions.
deleted 12y ago
[deleted]

Toad_King 12y ago

The overview literally just sounds like encrypted archive files. How is this different from putting a password on a .7z or .rar file?

SomeCallMeTim 12y ago
They aren't sending the PASSWORD in the clear, they're sending (effectively) a public key. Bob sends public key to Alice. Alice uses public key to encrypt file and sends to Bob. ONLY Bob can decrypt the file (using his PRIVATE key). If you sent a password, then anyone who intercepted it AND the encrypted archive would be able to decrypt it.
- MrUnknown 12y ago
  seems that how they generate the keys, it's basically the same. The same password would generate the same keys. Anyone who uses the same password would be able to decrypt data sent to anyone else using the same password. Am I understanding this correctly?
  - DiThi 12y ago
    If I send you an encrypted file with minilock, you won't know my password, and I won't know yours, but you'll be the only one that can read it, and also you'll be sure I've sent it and not anyone else. Public key crypto has more advantages and users should understand the basics. This introduction may be more clear (4:30) https://www.youtube.com/watch?v=vMiBwMHcSn0 https://www.youtube.com/watch?v=vMiBwMHcSn0 Also I would only use their 7-random-words feature for passwords.

achivetta 12y ago

I think the hesitations about passphrase being subject to brute force, rainbow table, etc. are warranted, but I have another concern: If my passphrase gets compromised, I have to retire the keypair. That's true of a key file with current asymmetric systems; but, presently if the passphrase of my GPG private key is compromised (e.g. by a hardware key logger), I only have to change the passphrase and ensure the old keyfiles are destroyed. With MiniLock, if my passphrase is compromised the entire key material is compromised and I need to revoke the public key. But how do I revoke it? Do I tweet a message with the private key saying the public key is revoked? Will there be a centralized place to publish revocation messages? Efficient key revocation will be absolutely critical to this system and that's hard if the key distribution mechanism is tweets or some other ad hoc mechanism. This is one thing that PGP key servers really help with.

selimthegrim 12y ago
I actually approached Kobeissi with this point in the meeting in Noisy Square right after the talk, suggesting he integrate a TPM into his key management system (like how you can call out to one in Firefox for SSL with libpkcs5.so or some similarly named library). He responded that the specs were open enough that anyone could add that in. As to a centralized place your guess is as good as mine. Also can MacBook users even access their TPMs?
- BuildTheRobots 12y ago
  Depending on who you're protecting against you might want to _really_ avoid trusting your TPM.
  - higherpurpose 12y ago
    Yeah, I wouldn't trust the TPM - certainly not from a Windows machine, and not even an Apple one after the recent revelations/research, which shows Apple tries to make the device secure against "regular" hackers, but very easy to access by Apple itself or the US government.

rgj 12y ago

Relying on a passphrase only is not good enough. Enter it once on a compromised system and it's game over. Since your ID is tied to your passphrase you even have an issue and you will need to revoke your public key. Many years ago, people realised you need to rely on something more than knowledge (of a password/passphrase) alone. Pick any two out of {something you know,something you own,something you are}, the latter being implemented by biometry. That's why you need your ATM card, and why it has a PIN code. This is a step back into a world were security wasn't good enough. Security is more than crypto alone, it's mainly about keeping things secret. There are too many ways a passphrase could be compromised or discovered. This approach focuses too much on the crypto aspects, and not enough on all the other things involved in building something that is secure.

zimbatm 12y ago
> Enter it once on a compromised system and it's game over. It's the same issue with PGP. Instead of capturing the password it captures the decrypted private key.
chacham15 12y ago
> Enter it once on a compromised system and it's game over The same is true of any heavily used system today. All systems: banks, credit cards, facebook, etc. use "something you know". "Something you own" has just recently picked up steam in the form of two factor authentication, but then again, how many people you know actually use that? The only thing that I know of/heard of that might hold up against the type of attack that you describe is the behavioral keys: i.e. a key which is something about you that you dont necessarily know yourself, e.g. your style of chess, or your phrasing of sentences.

viralpoetry 12y ago

Some times ago I created my own file encryption software using libsodium. It uses XSalsa20, hmacsha256, pbkdf. It hide password input on the terminal. It is really slow for large files (GBs)... https://github.com/viralpoetry/VPcrypt https://github.com/viralpoetry/VPcrypt

dchest 12y ago
Yours uses symmetric keys while miniLock is public-key crypto (crypto_box in NaCl terms).
- viralpoetry 12y ago
  Thank you for checking it out. I used it just myself, hence symmetric crypto only.

polvi 12y ago

MiniLock looks like a great option to introduce encryption to my non-technical friends. The alternative to minilock right now, for these users, is to do nothing. Even if we do not like it, right now state of the art on file sharing (for most of the non-technical world) is an unencrypted email attachment. MiniLock looks like it might be something I can install on my mothers (non-technical) computer so that I can send her a sensitive doc (copy of my tax return, for example). This crypto system is sufficient for that use case, and the alternative is to do nothing at all. The alternatives are not GPG, or RSA, or whatever, because outside of the technical community people have no idea how to use these things.

napoleond 12y ago
Exactly! When it comes to crypto apps, I have noticed two kinds of criticism: "This software is not built for the threat models that interest me" and "This software fails to properly address the threat model it claims to". Too often, commenters will act as though their critique belongs in the second category when it really belongs in the first. (It's great to question the design goals of a project! But that's very different from saying that a project fails to do what it says. In this case, Minilock has very clearly accepted a threat model where, if the passphrase is compromised, that's the game. If you don't like that, don't use it!)

edoceo 12y ago

My favourite is that the Tweet has be come some standard of measure "fit inside less than half a tweet". Not less than 70 characters; "less than half a tweet".