Re: dar encryption - RSA

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 27/09/2014 18:13, Tobias Specht wrote:
> Hi Denis,

Hi Tobias,

> 
> now I see the problem with signing the symmetric key and your
> solution to sign also the catalogue sounds reasonable.
> 
> Are you interested in discussing the catalogue topic a little bit
> more?
Of course!

> I don't feel comfortable with storing passwords in clear text even
> on my own system and to store the catalogue unencrypted is also not
> very consistent in terms of privacy. In my opinion both options
> prevent users actually from encryption there backups.
I guess the main reason is not more complexity of encryption than
ignorance and blindness of marketing/profiling possible abuses. When
you even don't ask yourself whether you can trust the owners of the
remote "cloud" storage you send your data to, for they do not read or
analyze the content you've sent, you don't even thing about encrypting
your data before sending it out...


> To make encryption more popular there should be no disadvantages
> when using it!
I agree with that point, the less a task requires effort, the more
people will probably do it. However, sometimes doing something safely
will always cost more than doing it another way. In that situation
educating users is at rescue. Example, many people today use seat belt
 during their travels by car, while it is just easier not to use it. :)

> (I mean the problem with doing referential backups when using 
> encryption at the same time.) The effort for the user should be as
> small as possible.
Right, for now as small as possible is issuing a password. Without any
key (of any sort) to be provided, how can you see a mechanism that
could differentiate a user that has the right to access the data from
another one that has not that right? How could it be done
better/simpler? I guess you have suggestions about the differential
backup context? :)

> As you know it isn't even simple to convince a user to make backups
> at all.
... education... unless automatic backup is performed by the system.
But if user are ignorant about the existence of such automatic backup
mechanism, how would they think they can rely on it to restore their
system when a single file got lost by mistake or a whole system has
been destroyed (crash, stealing, disaster,...): The system has to be
even more "smart" (by opposition to the user). Usually having systems
getting "smarter" removes freedom to the users... so we must also pay
attention not to remove freedom to clever users, those that either are
educated about a subject (here backup) and/or that don't completely
(want to) rely on a "smart" system to provide the service they need.

> But when it means more effort to use the encryption option, it is
> very unlikely that he will use it. What do you think?
Nothing more than what I have answered above.

The new public key encryption is a partial solution to that point,
with the additional feature of encryption algorithm in archive
headers/trailer:
* Encrypting an archive is as simple as listing the email recipients
we want to encrypt the archive with corresponding public keys.
* Deciphering an archive is as simple as a clear archive (as soon as
you have an adequate private key), no -K option to give...

But, yes, this does not answer the differential backup you underline,
nor it address the backup/restoration to recover a disaster for
example: you need the private key to decipher the archive...

Another point to mention and take into consideration in this
discussion: dar/libdar is quite low level tool not targeted to people
that need to relying on a smart system... However,
it can serve other tool that provide this high level intelligence of
what user need without user expressing any request...

The "philosophy" of dar/libdar is a tool with logical default values
and systematic explicit options, no guessing, no "intelligence" in
order to preserve user freedom to use or activate the features they want.

By opposition, maybe you have been using MS Word. What annoying it is
to have it capitalizing a word automatically because it "thinks" that
it has to be capitalized... But if it was not the case, it gives you
additional work to correct what has been changed without you having
been asked, and lead you to become more vigilant for that it does not
modify what follows an 'E' to an exponent and so on... My point of
view with such "intelligent" tool is that I am not that stupid, I know
how to type an uppercase or an lowercase... let me assume my mistakes
and keep my freedom of writing the way I want.

In short, too much or badly designed "intelligence" in software may
become more painful than helpful.

As you see, I just want to avoid that with dar/libdar, tools relying
on libdar are not my concern, every need has to be satisfied but at
different levels.

In that context, yes, I am open to consider anything that could
simplify the use of encryption within dar/libdar, or any mechanism
that could help overlying applications on dar/libdar to provide that
smart service to users. :)

> I would be glad about hearing other comments on this topic.
> 
> Regards, Tobias
> 

Best Regards,
Denis.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIVAwUBVCfIfwgxsL0D2LGCAQLs5w/7Br/J89pJjhP5gxfz9q/bKCyTvxS2bgnz
kdtI+LLhmmQCjB6uhD/MVPIo1xO7NHTRA0oruo+K9uESfHyYxTkqmpTixASkOLAC
NrV0qugHwXd9VAB/bQM3dDRy1eU2tWbwzS5ezvK4kzaicrD2MUvXI8lgnP7AP1l2
ZldoRs0B87doWJwyrFzzp5OFn2AWlhO1NX720D/j50x1SViQQkTVjGywggGADyLP
2wqCOgAup1VStswLMRSWAA6HEFTkQKG67b8AJ5BMfpbezwFqbkk530JtDGw3XfPL
HmOvpfVgEnAkd06vK1RUL/93eH4cYhWOIBf36OnjA2RTLHTqIVG/quvDvggw5DPR
qmANAOozwXTLFEbqJf2idY8QWoQKfahqpqOKNeFZXIFWMS0t/yi1xnG6cd9SkwDq
2iPANIITQLwjYvZ4PJXjr9/347yTk/qKVfdJxqEUuRwNBNt77N568+UkhDyw16Eh
ra03BAD1j2cqYj8IjxIOjPg5ocD/HF+q4fiBc5SGQOOIE3iMe2B4loosQwbDHgrt
bOtrGGfIEJ4hSpdgHiM1szj5mA9IhnBZErDFOEQANCCRhQCq8tk4izi239HDuTUR
PeGlVcGUjXxUMJ133Qzhw5KJGYBYuPVsBbmPl3KVh7HskapErE+D3O1+9t5DE5N6
OW3uF59hgPI=
=5IBE
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk