Crypto from Linux
"My system is a linux/windows dual boot, with some of the drives accessible from both OSs. Presumably this would fail if the windows involved were win 10 (not that that is going to happen in the forseeable future). Come to that, would linux partitioning tools screw the drive so that windows could not read the data either?"
Can't speak for Windows in terms of being able to repartition (they love to use "magic" sectors, hidden files, and so on...)... but I think the principles are the same, see below.
I just got a Chromebook13 (Nvidia TK1, quad-core ARM + decent GPU) that I set up to dual boot Ubuntu (ChromeOS on the internal flash, Ubuntu on an SDCard). I accidentally repartitioned the flash first; whether it would have screwed up the encrypted "vault"s on there or not, I don't know (I doubt it); the ChromeOS automatically decided something was screwy with the partition it wiped itself back to factory defaults (and then when I re-expanded the partition back to full size it did it again.) I would GUESS (as long as you don't trash the NTFS filesystem) that Windows, including the cryptosystem, would not care a bit if it's partition size changed.
So, from Ubuntu, I mounted the largest volume on the flash drive and looked around. I went to the /home/chronos and it's empty, /home/user/ and it's got an empty directory with 40 character (0-9, a-f)... I found there's a /home/.shadow/ directory with same 40 character (0-9,a-f) directory in it (so you can't even get user names), under that under vault/user/ there are files and diectories all named like ECRYPTFS_FNEK_ENCRYPTED.(15 chars).(40 chars).(40 chars) (these are not hex, it's (0-9, a-z, A-Z) ). So, if I wanted to snoop, not only encrypted file contents, no useable file names either. I assume it'd be similar with Win10...either useless file names and contents, or "best" case useable file names but unreadable contents.
For the record, I've looked into Chromebook key handling, and it's sensible; the disk crypto key is based on username, password, and TPM value (or a value from Scrypt library if you ha a non-TPM system.) This key is not stored or sent out anywhere! When you log in, the Google account password is not sent to Google, rather a hash value is sent. If you use the Chromebook to change your account password, it updates the on-disk crypto to use the new key (I assume having to reencrypt everything?) If you change your account password elsewhere, then log into the Chromebook, it logs into Google, then realizes the disk crypto key doesn't work; it gives you a chance to put in the older password. If you can't, it wipes the encrypted data and starts fresh with the new password (hased with username + TPM data).
So yeah, accessing one of these Win10 accounts from Linux-side would fail. But it's not a Windows-specific fail, it's true with any encrypted disk system.