Idea: .bcup folder instead of a single file

[ph1p]

There are several problems that point in the same direction: "Add encrypted files to entries". Currently, the .bcup file is a single file that is gradually growing in size. We can save files as base64, but it's getting bigger.

My idea is to treat .bcup files like .sketch files. We simply create a folder instead of a single file.

my-vault.bcup

• vault.encbcup <-- the .bcup file like today
• files
  • 098osdvm-d4234-423jfad-09f8shfs <-- entry id
    • file.jpg.encbcup <-- an encrypted file
• cloud-services.encbcup <-- maybe cloud tokens ...

We can store an additional randomly generated key to our entry in the .bcup file to encrypt the files only when needed, so we don't have to keep the master password in memory.

Maybe this is dumb, but I wanted to share this idea (:

[perry-mitchell]

Not a dumb idea at all, we've considered doing this earlier. We've always steered clear of it though because of a few fatal issues we see with it:

• Files are just easier and more practical to move around. They can be targeted as a single file for external programs (can be opened by Buttercup on every platform - directories cannot behave this way on Windows for instance)
  • They can be transferred easily
• Directories require more requests to get the content - multiple networks requests are more expensive and time consuming when compared to a single file (assuming there are many files in the directory)
• Directories would require file discovery - checking if a file exists

They would ofcourse solve the issue in a better manner of storing attached files, as well as improving conflict resolution, but at least I feel the cons outweigh the pros on this one.

We can store an additional randomly generated key to our entry in the .bcup file to encrypt the files only when needed, so we don't have to keep the master password in memory.

Wouldn't this completely expose the secret the key contains? It could be easily copied and then someone would have decryption access to all of the files..

[perry-mitchell]

We're actually working on bcupfs right now that will allow us to store encrypted files within the same vault file. It might be the only other possibility for attaching files without using a directory.

[ph1p]

Oh you're right! Didn't think about windows and the other operating systems facepalm

Wouldn't this completely expose the secret the key contains? It could be easily copied and then someone would have decryption access to all of the files.

(I don't know if I got that right now.) The key is a randomly generated password to encrypt and decrypt the files for one entry. You would store it just like all other passwords also in the Buttercup file. It would belong to an entry. So you wouldn't have to decrypt everything at once and can only do it when needed.

We're actually working on bcupfs right now that will allow us to store encrypted files within the same vault file. It might be the only other possibility for attaching files without using a directory.

Saw it about a minute ago ^^. This is cool! I hope it doesn't take longer to unlock the vault.

I think this can be closed (: because you've already found a working solution. Just wanted to share some of my thoughts. (: It's definitely nice to hear that you've thought about it, too. But the disadvantages are really too many.

[perry-mitchell]

you wouldn't have to decrypt everything at once and can only do it when needed

That's at least the idea with bcupfs - each attachment is encrypted separately so there's no need to decrypt all of them at once of course. We're trying to design the library with streams in mind so that we can split the vault contents, file index and file collection into different segments to allow for higher performance. It's definitely a conscious thought that the files could end up being quite large, so we need to keep performance in mind at all times.

Well this is a great idea still, and really the only alternative to what we're proposing. The road to adding attachments will be a long one as we don't want to release functionality that is so difficult to retract if the idea fails. We'll do some heavy in-house performance testing before we release such a feature to the public.

[perry-mitchell]

I'm going to close this for now as I feel that the file is something we can't really move away from. It's such a huge benefit having a single blob of data, and folders are simply not as portable from a cross-platform perspective. Thanks for the discussion!