For security, somewhat. The current de-facto standard mode of operation for disk encryption utilities is XTS, which effectively encrypts each block on the disk with a different key, where the blocks are of the same size as the cipher block.
Whether this is of any significance depends on your adversary model. If the adversary controls your storage medium (imaging putting an encrypted container on Dropbox or Google Drive), they can mix-and-match (e.g. copy-paste) different versions of blocks from your history. Imagine your disk to be in a version control system; the adversary could pick the value of the block 1 from version 50, the value of the block 2 from the version 42, the value of the block 3 from the version 100 and so on. They could also potentially discover usage patterns (seeing e.g. that the value of block 3 remained constant between versions 20 and 200, while block 5 remained the same). Additionally, they could corrupt any of the blocks, by turning the corresponding plaintext into random bits.
Having a smaller block size means that they can perform any of these with finer granularity. Increasing the block size thus increases your security; ideally, your entire disk would be just one block (the only thing the adversary could do in that case is to completely restore an old version of the disk); but this is hugely impractical, since the performance would be abysmal (you'd have to re-encrypt the whole disk to change just one byte). So you have a spectrum of performance/security tradeoffs. Where on this spectrum the 1024-bit blocks lie, I'm not sure, but I suspect that they are better than 128-bit ones.
Note that we do have schemes which can do sector-level encryption (the EME mode), but they're not used since they're 2x slower than the schemes with smaller sizes.
Edit: in conclusion, for pretty much every scenario, other security concerns are much more significant than the block size :)
> Additionally, they could corrupt any of the blocks, by turning the corresponding plaintext into random bits.
Given that the premise is that the adversary controls the storage medium, this point doesn't seem terribly interesting. I feel like I'm missing something.
The theoretical attack there is that one could selectively garble the (decrypted) parts of your storage, and thus destroy the contents of e.g. your configuration files. E.g. they could corrupt your firewall configuration file and thus leave your computer open to outside network connections. I don't think this has been done in practice, and it's probably not very feasible.
Such an attack could not be detected, because the encryption modes commonly used do not provide integrity protection. This is due to the desire to have equal sizes for both the encrypted and plaintext sectors (as far as I understand, that's an efficiency/ease of implementation concern). Incidentally, you can easily see that such a scheme can never provide integrity, since the encryption operation has to be a permutation, and you have to be able to decrypt any ciphertext.
No; part of the point of XTS is to adapt 128-bit AES to 512-bit blocks, but the other part is to seamlessly incorporate sector numbers into the cryptosystem. Even with a cipher whose block size accommodates whole disk blocks, you still need a construction that achieves more than ECB does, which is what you'd get by naively applying Threefish.
Threefish is actually a tweakable block cipher - it takes a 128-bit tweak in addition to the key and the input, so it should be well suited for disk encryption.
It's a bit disappointing that it hasn't seen more uptake since the SHA-3 competition. I think the tweakability and large block size makes it a more flexible primitive that AES, and even naive implementations should be constant-time. It's hard to compete with hardware-accelerated AES, though.
