|
Powered Descent posted:That does sound neat, thanks for the link. But unfortunately it doesn't appear to have my favorite feature of EncFS: reverse mode. That allows you to mount an encrypted view of unencrypted files, on the fly and with no extra disk space used up. I've been using it for years for my own backups. I'm not quite paranoid enough (yet) to keep my stuff encrypted on my local machine, but I want it scrambled before it goes off to the cloud. So my backup script just mounts the encrypted view and then rsyncs that. Works great. Hmm. That does sound like a cool way of doing it. Kind of like using Dropbox (or whatever) for an encrypted snapshot, rather than constantly looking for file changes. I was gonna use EncFS but read somewhere that the way the files are encrypted it's possible to reverse engineer the encryption key under certain circumstances. I think it was in relation to versioning, thus: Say you have a text file that you modify by adding a sentence to the end, then decide to edit again and remove that sentence. Dropbox (or whomever) now has two versions of the file and can use the differences generated by EncFS to calculate your symmetric key. See here: http://security.stackexchange.com/questions/83292/is-encfs-secure-for-encrypting-dropbox I guess it would be trivial for a big company like Dropbox to watch user accounts that seem to be encrypted with EncFS and run a bot to check file versions for when this scenario appears. If they wanted to. apropos man fucked around with this message at 22:57 on Dec 25, 2016 |
#
?
Dec 25, 2016 22:43
|
|
|
|
| # ? May 19, 2024 14:24 |
|
|
Apparently the EncFS flaw is that it encrypts the last block with a stream cipher. It won't leak any keys, but it can leak the last kilobyte of a file if it changes.
|
|
#
?
Dec 26, 2016 03:43
|
|
|
Ah, OK. I'm no expert in these things, which is why I asked here to see if anyone thought CryFS has any obvious problems. I dunno what a stream cipher is, and how it would differ from transforming a whole file with a symmetric key. I've got CryFS set up to unlock a directory on boot by piping my passphrase through stdin and using the -c (--config) flag, so that I could move the cryfs.config file out of the directory to be uploaded. I'm keeping cryfs.config somewhere safe, since it's a bit like a luks header in that it contains the encryption key wrapped in further encryption. I realise that my local files are boned if someone has a look around and sees my config file passphrase, but if someone gains that kind of access I would have worse problems to care about. Seems good so far.
|
|
#
?
Dec 26, 2016 09:24
|
|
|
apropos man posted:Ah, OK. I'm no expert in these things, which is why I asked here to see if anyone thought CryFS has any obvious problems. I dunno what a stream cipher is, and how it would differ from transforming a whole file with a symmetric key. They appear to have done this to handle files that aren't an exact multiple of the block in length, but there are much better ways to do that.
|
|
#
?
Dec 26, 2016 10:29
|
|
|
Dylan16807 posted:With a stream cipher you don't directly encrypt the data. You generate a block of noise the same size as your data, and XOR them. This is appropriate in some circumstances. It is not appropriate when a key will be used more than once. Ah, right. I can kind of visualise what you mean. So the file is padded out to n*blocklength.
|
|
#
?
Dec 26, 2016 11:56
|
|
|
apropos man posted:Ah, right. I can kind of visualise what you mean. So the file is padded out to n*blocklength. The opposite. If they had padded it to an entire block and then encrypted it normally, things would be fine. They used a stream cipher at the end because it doesn't care about blocks, without considering how it weakened the security.
|
|
#
?
Dec 26, 2016 18:17
|
|
|
That seems like a lot more over-engineering (not to mention slower and more fragile - mode switch means double the code paths and exceptional states) to save an average of 16 bytes per file. Given that symmetrical block boundaries fit evenly into 4k allocation units, it won't save any storage space at all. Do they have a justification for it, or is it just "Someone tried to be clever and now we need to be backwards compatible"? Edit: It's because there's no good option to store metadata, so they need to keep the encrypted file length the same as the unencrypted length. You can't encode metadata in the filename, because that turns open() into a linear scan. The only option is to front-pad the file (breaking block boundaries or taking up an extra 4k block) or store metadata in a separate file with all the problems that entails - you're basically just using a filesystem as a backing store at that point, which kills the benefit of "just" having encryption but leaving everything else up to the underlying FS. E2: I took a look at cryfs, and I don't think it's safe to use from an integrity standpoint. It's just a pile of 32kb blocks dumped on dropbox, which uploads them in whatever order it chooses. If you've been editing files on your machine and syncing to dropbox and your PSU blows up and takes your drive with it: chances are the data in dropbox is completely unusable, depending on how many blocks were outstanding. Ask any filesystem developer about a storage device that writes-out dirty memory in 32kb chunks in random order, and they'll tell you it's impossible to guarantee integrity. No journaling either, so you may end up with chunks of a file updated and others not. Good luck rolling every 32kb block back to some semblance of a consistent state. In terms of security, I don't think it's anywhere near as secure as they think it is. Taken at rest, you can't gather much information. Taking the streaming update log that a cloud provider has, you can trivially identify the root directory blocks, other directories and individual files with a size granularity of 32k. You can see what files the user is working on with frequency, and as they grow you capture the additional blocks. You can tell exactly what directory they are in as well. This is all the stuff their scheme was supposed to prevent. apropos man posted:
Remember one critical point: If something happens to the cryfs.conf file all your data is just gone. That means if you keep it locally and your drive dies, there's no reason to have wasted bandwidth uploading to dropbox in the first place. They really need to highlight that in their setup instructions. If you want to keep it separate from dropbox, keep it backed up safely. Harik fucked around with this message at 20:31 on Dec 27, 2016 |
|
#
?
Dec 27, 2016 19:02
|
|
|
Harik posted:In terms of security, I don't think it's anywhere near as secure as they think it is. Taken at rest, you can't gather much information. Taking the streaming update log that a cloud provider has, you can trivially identify the root directory blocks, other directories and individual files with a size granularity of 32k. You can see what files the user is working on with frequency, and as they grow you capture the additional blocks. You can tell exactly what directory they are in as well. This is all the stuff their scheme was supposed to prevent. I've got the cryfs.conf file stored inside my keepass database file, since keepass allows you to store attachments there. I have the same file regularly synced across three different hard disks and my mobile, so I don't think all of those are gonna break at the same time. As for the encryption, thanks for checking it out to a degree I couldn't understand. I've been tinkering with it most of today and even set up an AWS S3 storage "bucket" to sync the encrypted shards in my CryFS directory to S3 from the command line. I also set up a cron job to sync automatically every hour. I thought I had it all sorted but obviously this CryFS poo poo needs to go. I don't want to use an overall encryption container because I'll get bummed for bandwidth money by Amazon and also it'll slow my home net and connection down, since every time a file is altered in the container the whole container checksum changes. I'd like some automated file by file encryption that does the job properly. Ho hum.
|
|
#
?
Dec 27, 2016 22:19
|
|
|
apropos man posted:I've got the cryfs.conf file stored inside my keepass database file, since keepass allows you to store attachments there. I have the same file regularly synced across three different hard disks and my mobile, so I don't think all of those are gonna break at the same time. I didn't actually do an audit, I just glanced over it and saw some structural problems. You absolutely do need to drop CryFS for anything but experiments though - they've broken on-disk compatibility, and probably will do so at least once more before they consider it a stable release. That's not a negative, it's just a fact of life with new, experimental systems like this. They don't want to get locked into a bad format by early mistakes. EncFS with the right options to avoid the known issues is probably good enough, but you'll want to weigh the pros and cons of all your options.
|
|
#
?
Dec 27, 2016 23:36
|
|
|
I think I'll switch over to EncFS. It'll be a trivial job tomorrow to copy the decrypted files to a new directory for EncFS, and then point my sync script to the new location. If Amazon want to check my encrypted blocks for file changes then have at it! Like you say, the important thing here is that I have a reliable backup that I know I can reassemble. Cheers! Edit: I'll also look at the best setup options for running EncFS.
|
|
#
?
Dec 27, 2016 23:59
|
|
|
https://twitter.com/mikeymikey/status/813848628888408064
|
|
#
?
Dec 28, 2016 05:58
|
|
|
apropos man posted:I think I'll switch over to EncFS. It'll be a trivial job tomorrow to copy the decrypted files to a new directory for EncFS, and then point my sync script to the new location. You want borgbackup. The only reason to use EncFS is if you need online access to it; if all you need is "batch" (aka backup) access, you want a deduplicating encrypted backup.
|
|
#
?
Dec 28, 2016 07:32
|
|
|
CaladSigilon posted:You want borgbackup. The only reason to use EncFS is if you need online access to it; if all you need is "batch" (aka backup) access, you want a deduplicating encrypted backup. Ooh. Thanks for mentioning that. I've had a look at a couple of reviews now that I know what to search for. This page (http://changelog.complete.org/archives/9353-roundup-of-remote-encrypted-deduplicated-backups-in-linux) is pretty informative and suggests to use Obnam instead of Attic (which borgbackup is a fork of). Since I'm not uploading a large amount like the guy in that article I'm gonna give borg a try.They may also have improved on the remote index problem that existed in Attic, since that article is almost two years old. I've gotta go out for a couple of hours, then I'll mess around with borg and maybe Obnam to compare.
|
|
#
?
Dec 28, 2016 09:58
|
|
|
apropos man posted:Ooh. Thanks for mentioning that. I've had a look at a couple of reviews now that I know what to search for. rsync.net has an awesome special price for people using attic/borg. Ridiculously, insultingly cheap, and they're incredible. No support, though; that only comes with the not-crazily-discounted plans. (Even the real plans aren't that expensive though.)
|
|
#
?
Dec 28, 2016 11:36
|
|
|
CaladSigilon posted:rsync.net has an awesome special price for people using attic/borg. Ridiculously, insultingly cheap, and they're incredible. No support, though; that only comes with the not-crazily-discounted plans. (Even the real plans aren't that expensive though.) A bit out of my league, there. You can't pay for less than 100GB and I'm lucky if I will hit 3GB for just personal documents and stuff. Looks good and cheap for those with big data. I'm gonna run S3 for a couple of months and see how it averages out. If it's more than $5, which I very much doubt, then I'll consider it.
|
|
#
?
Dec 28, 2016 13:28
|
|
|
If you need backup (rather than syncing) just use tarsnap. It's backed by s3
|
|
#
?
Dec 28, 2016 15:40
|
|
|
Harik posted:Do they have a justification for it, or is it just "Someone tried to be clever and now we need to be backwards compatible"? Couldn't they store the additional metadata in extended attributes? Or do they need to be FAT compatible for USB sticks? Edit: Oh, Dropbox. Why do they care about the exact file size again? ExcessBLarg! fucked around with this message at 17:00 on Dec 28, 2016 |
|
#
?
Dec 28, 2016 16:58
|
|
|
ExcessBLarg! posted:So they're trying to store an encrypted file without taking up any additional space from the unencrypted version? Presumably the key is derived from a user-input passphrase, but where do they store the IV and MAC? Do they have an IV and MAC? Last question first, because two answers: You want to hide exact file size because with today's large files, to-the-byte filesizes are a pretty good fingerprint, especially if there's a number of them that all match known "subversive" documents you're hunting for. EncFS needs to know the exact filesize because it presents as a filesystem - without something indicating the filesize it has no way of knowing how many unencrypted bytes to return. You could stuff it in extended attributes, but those aren't backed up by 99.99% of tools so copying your data effectively makes it unreadable. You could put it in a separate file, but then you have syncronization problems if you have a partial upload. IV/MAC depends entirely on your options, there's a number of tradeoffs you can make when initializing the system. By default (2005 crypto defaults) there's a single 8-byte IV for the entire filesystem, stored in the metadata. You can do per-file, but it breaks block alignment. That's also where they stuff Block MAC headers if you enable that. Yes, MAC is an option. 2005, remember? By default, filenames are encrypted with the same global IV. That means Readme.txt in the root directory has the same in-directory filename as Readme.txt in src/. You can enable per-directory IVs at the cost of having to rename every file (recursively!) when you rename a directory, and potentially having complete garbage filenames if a crash happens mid rename. There's a lot of non-obvious gotchas to doing an overlay filesystem like this. You can't stuff anything in the filename, because that turns Open() into a linear scan. Putting the IV at the beginning of the file screws up page alignment and performance. Putting it at the end involves extra seeks. Storing anything critical to the file outside the file leads to a multitude of ways to lose everything with minor corruption. It would be interesting to see someone try to make a better EncFS, and what tradeoffs they make. Harik fucked around with this message at 22:45 on Dec 28, 2016 |
|
#
?
Dec 28, 2016 22:42
|
|
|
Rufus Ping posted:If you need backup (rather than syncing) just use tarsnap. It's backed by s3 Thanks for that. I've been playing with borgbackup for 24 hours and I like the versioning control I can do with it. I'm running it with crontab, so I can easily adjust time between archival operations. I've also got a second local borgbackup for my mozilla dotfiles, which used to occupy multiple tarballs but are now in one borg repo. I've been extracting different local and remote snapshots this morning and checking with diff to prove the integrity of my snapshots and it's all working out fine. I really like borgbackup. If Amazon start billing me too much for my borg syncs I'll have another look at tarsnap. Cheers!
|
|
#
?
Dec 29, 2016 10:18
|
|
|
I'm on vacation right now and I'm going to need to print some documents this week. What's the general safest way to get these PDFs onto a public computer to print if I don't have a USB stick with me? I'd rather not log into my email or any accounts. I was thinking just putting it on Dropbox, getting the share links, printing it and then deleting them from Dropbox? e: I'm not really worried about the contents of the documents being accessible (just boarding passes, some notes/checklists etc), rather the idea of logging onto my poo poo on public computers.
|
|
#
?
Dec 31, 2016 14:24
|
|
|
Could create a burner gmail account and mail stuff there.
|
|
#
?
Dec 31, 2016 15:15
|
|
|
Subjunctive posted:Could create a burner gmail account and mail stuff there. I thought of that but I guess you can't make gmail accounts without a phone number now? It says my phone numbers been used too many times to register.
|
|
#
?
Dec 31, 2016 15:44
|
|
|
That's what Google Voice is for.
|
|
#
?
Dec 31, 2016 16:21
|
|
|
Boris Galerkin posted:I thought of that but I guess you can't make gmail accounts without a phone number now? It says my phone numbers been used too many times to register. Hotmail or yahoo might work and probably you won't have already set up an account
|
|
#
?
Dec 31, 2016 16:23
|
|
|
Haven't used it myself but I found out about https://www.sharklasers.com/ the other day. (EDIT: Probably doesn't work with attachments though. Meh. Still a neat link?)
|
|
#
?
Dec 31, 2016 16:25
|
|
|
Boris Galerkin posted:I'm on vacation right now and I'm going to need to print some documents this week. What's the general safest way to get these PDFs onto a public computer to print if I don't have a USB stick with me? I'd rather not log into my email or any accounts. I was thinking just putting it on Dropbox, getting the share links, printing it and then deleting them from Dropbox? Mediafire, IIRC, lets you set a password and temporary share links for files. Or (maybe) it did last time I used it years ago. I've been using a paid Dropbox account that lets you do time-limited public links (free account doesn't).
|
|
#
?
Dec 31, 2016 23:07
|
|
|
doctorfrog posted:Mediafire, IIRC, lets you set a password and temporary share links for files. Or (maybe) it did last time I used it years ago. I've been using a paid Dropbox account that lets you do time-limited public links (free account doesn't). Mega.nz also does this, and also splits the URI for your download link into two parts, seen here in black and red.  If you want you can just share the first part of the link publicly. This gives a prompt for the decryption key, which is the red half of the URI. The whole thing joined up allows you to download the file or directory. Dunno how great the encryption is but it could be handy to keep the link in two halves. You might also be helping Kim DotCom with some hits to pay his solicitors fees.
|
|
#
?
Jan 1, 2017 02:03
|
|
|
Boris Galerkin posted:I'm on vacation right now and I'm going to need to print some documents this week. What's the general safest way to get these PDFs onto a public computer to print if I don't have a USB stick with me? I'd rather not log into my email or any accounts. I was thinking just putting it on Dropbox, getting the share links, printing it and then deleting them from Dropbox? Use mailinator or otherwise to sign up for a throwaway github account, start a new public repo (have it auto-create the readme file so there's some activity), then upload the files to a new branch of the same repo. 1. It's all drag and drop (really nice web UI on github for uploading files to a repo) 2. The only way anyone would know there's files in the repo is if they noticed that it has 2 branches (AFAICT changes to non-master branches do not show up in the user profile or repository activity) 3. https://github.com/sdfsdfsiduf/test 4. Easy to remember urls https://github.com/sdfsdfsiduf/test/raw/sdfsdfsiduf-patch-1/SHENZHEN-IO-Manual.pdf (clicking this automatically downloads an outdated Shenzhen I/O instruction manual) 5. Unlikely to be blocked for "file sharing", does not require the latest browsers to function 6. Built in web-viewer for an impressive number of file types (this way, if downloads are disabled, you can at least screen shot and print) 7. Easy to delete permanently (at any granularity, from repo activity, to entire repo or whole account), and also easy to falsify/make it look like someone else pushed the commit 8. Could always upload password protected/encrypted self-extracting zip files or obfuscate otherwise. 9. Easy to automate 10. This is just personal opinion, but I trust github to be slightly more reliable/proactively secure than any cloud file service like mega or dropbox Happy new year
|
|
#
?
Jan 1, 2017 07:00
|
|
|
That's a convenient way but not particularly safe.
|
|
#
?
Jan 1, 2017 09:48
|
|
|
For gently caress's sake, just pick up a usb drive, they sell them at drugstores for five bucks.
|
|
#
?
Jan 1, 2017 09:51
|
|
|
Powered Descent posted:For gently caress's sake, just pick up a usb drive, they sell them at drugstores for five bucks. Hell, they're so cheap these days you can often find them lying round in car parks.
|
|
#
?
Jan 1, 2017 10:24
|
|
|
apropos man posted:Hell, they're so cheap these days you can often find them lying round in car parks. Those usually have a bunch of helpful programs installed, as well!
|
|
#
?
Jan 1, 2017 17:38
|
|
|
Boris Galerkin posted:I thought of that but I guess you can't make gmail accounts without a phone number now? It says my phone numbers been used too many times to register. Well, there are a bunch of email providers. I doubt you've registered with all of them too many times.
|
|
#
?
Jan 1, 2017 18:23
|
|
|
Boris Galerkin posted:I thought of that but I guess you can't make gmail accounts without a phone number now? It says my phone numbers been used too many times to register. e: nm
|
|
#
?
Jan 1, 2017 19:09
|
|
|
Back to infosec... Literally  gets you a usb U2F/Fido security key from amazon. (https://www.hypersecu.com/products/hyperfido) Half the price of Yubico..No reason to not do it any more.
|
|
#
?
Jan 1, 2017 19:13
|
|
|
unknown posted:No reason to not do it any more. I'm still saddened that Firefox is majorly dragging their heels on implementing support in the browser. There''s an add-on that works pretty much perfectly (minus for a couple of sites that intentionally don't support it -- looking at you, Google); it shouldn't take them so long. I mean, christ, look at this mess https://bugzilla.mozilla.org/show_bug.cgi?id=1065729.
|
|
#
?
Jan 2, 2017 03:31
|
|
|
unknown posted:Back to infosec... Holy moly, thanks for pointing this out. I've been meaning to replace my dead yubi.
|
|
#
?
Jan 2, 2017 19:53
|
|
|
CaladSigilon posted:I'm still saddened that Firefox is majorly dragging their heels on implementing support in the browser. There''s an add-on that works pretty much perfectly (minus for a couple of sites that intentionally don't support it -- looking at you, Google); it shouldn't take them so long. What the gently caress, that bugzilla thread. I thought people got pissy in the request thread that FF ESR include "esr" in its DisplayName in the Win reg. Holy gently caress I had no idea. Potato Salad fucked around with this message at 20:39 on Jan 2, 2017 |
|
#
?
Jan 2, 2017 20:36
|
|
|
unknown posted:Back to infosec... Just noticed in Amazon reviews that it's a rebadged Feitian K5 token. Just in case anyone can find one of those even cheaper than the cheapness that is the one you posted.
|
|
#
?
Jan 2, 2017 20:50
|
|
|
|
| # ? May 19, 2024 14:24 |
|
|
Well, if you're in Canada, it's $9.99cdn with free 2day/prime shipping. That's what, like $7.50 usd? https://www.amazon.ca/HyperFIDO-Mini-U2F-Security-Key/dp/B01LZO0WE9 I'm not sure if it's possible to get cheaper. Makes me wonder if something is wrong with these tokens. 
|
|
#
?
Jan 2, 2017 22:52
|
|