Re: send/receive for encrypted backup purposes

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2016-01-08 09:07, Christoph Anton Mitterer wrote:
> On Fri, 2016-01-08 at 15:02 +0100, Swâmi Petaramesh wrote:
>> Le vendredi 8 janvier 2016, 15:00:46 Christoph Anton Mitterer a écrit
>> :
>>> Shouldn't any crypto that can read from stdin and write to stdout
>>> do
>>> that?
>>> E.g. simply ssh.
>>>
>>> hostA$ btrfs send foo | ssh hostB btrfs receive bar
>>
>> It works, I do this on a regular basis…
>
> One should perhaps only ask some SSH experts, whether their crypto is
> actually safe for such use case.
> I mean depending on what kind of data is send (e.g. often repeating
> patterns and so on) some crypto schemas may be more pron to statistical
> attacks than other.
>
> But I wouldn't see much problems... ssh has rather problems with
> statistical attacks when measuring keystroke times...
>
The send data stream is (from what I can tell) about as structured as 
HTML over HTTP (although with binary data, not text), so it's likely 
similar security to using HTTPS (SSH uses essentially the same 
techniques as TLS, it's just part of the protocol as opposed to an 
intermediary layer).  That said, if you're using forced compression on 
the source FS, that may weaken things a bit.

One thing I would say in this case is to avoid using SSH compression. 
If you're on a local link, it's wasteful for bulk transfers; and even 
with non-local connections, it's not usually beneficial unless you pay 
per-unit transferred (like happens on a lot of cell networks).