> One reason you may want to select aes-128-gcm rather than aes-128-ccm is
> that GCM is one of the modes for AES in NSA Suite B[3], but CCM is not.
> Are there symmetric algorithms other than AES that are of interest ?
How might AES-XTS [1] be able to fit into the the ZFS picture?
Additionally
To whom it may concern...
Those who subscribe to this list in digest format
are receiving upwards of ten (10) digest mailings a day.
This is not standard list practice for digests, which should
commonly be sent/expected once a day.
No apparrent message overlap, missing or repetition.
Seems like ran
Thanks for the archive pointer, I completely overlooked it.
Replacing the obfuscated 'at's allows mutt to read them :)
Doing some other lint checks... these lines in the gzip archives
could be adjusted by the list maintainer if so desired:
# Could be missing ' at ohsu.edu'
2006-May.txt.gz:From hak
Hi. As sometimes list-owner's aren't monitored...
I signed up for digests.
On the mailman page it hints at once daily service.
I'm getting maybe 12 per day, didn't count them.
Non-overlapping, various messages counts in each.
This is unexpected given the above hint.
Once a day would be nice :)
Than
> > Well, ok, and in my limited knowhow... zfs set checksum=sha256 only
> > covers user scribbled data [POSIX file metadata, file contents, directory
> > structure, ZVOL blocks] and not necessarily any zfs filesystem internals.
>
> metadata is fletcher4 except for the uberblocks which are self-
>> Perhaps I meant to say that the box itself [cpu/ram/bus/nic/io, except disk]
>> is assumed to handle data with integrity. So say netcat is used as transport,
>> zfs is using sha256 on disk, but only fletcher4 over the wire with send/recv,
>> and your wire takes some undetected/uncorrected hits,
>> Hmm, is that configurable? Say to match the checksums being
>> used on the filesystem itself... ie: sha256? It would seem odd to
>> send with less bits than what is used on disk.
>> Was thinking that plaintext ethernet/wan and even some of the 'weaker'
>> ssl algorithms
> Do you expect the sam
> No. Checksums are made on the records, and there could be a different
> record size for the sending and receiving file systems.
Oh. So there's a zfs read to ram somewhere, which checks the sums on disk.
And then entirely new stream checksums are made while sending it all off
to the pipe.
I se
Are the sha256/fletcher[x]/etc checksums sent to the receiver along
with the other data/metadata? And checked upon receipt of course.
Do they chain all the way back to the uberblock or to some calculated
transfer specific checksum value?
The idea is to carry through the integrity checks wherever po
