On 12/31/2016 11:43 AM, Andrew David Wong wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2016-12-30 19:32, Chris Laprise wrote:
On 12/30/2016 12:58 AM, Andrew David Wong wrote:
After meditating on this thread for a little over three years,
I'd like to revive it, because I think Marek made an important
point here, and I don't quite understand Joanna's response.
If we don't trust GPG in our backup system because it does too
much parsing of untrusted data before verification (which I
believe is correct), then why do we trust it in our dom0 update
system?
Ultimately, only Joanna can decide whether some guardian functions
are suitable for Qubes. But I don't necessarily buy into her
assertion about gpg verify: Watch some verbose output and declare
'Hark! Complexity!'. Is it /that/ worrisome for gpg to iterate over
X message segments and decide if each is valid?
Interesting point. I wish I knew.
If Qubes devs are going to start making commitments of time and effort
based on such claims, and disrupting the admin aspect of using Qubes as
well, I'd advise you to back them up with something rigorous before
leading the community down that path.
Laboring under the assumption that GPG is bad, you won't even know if
your Qubes-curated Fedora/Debian packages are good unless you get those
projects to switch to your alternative as well.
"If we don't trust GPG in our backup system" ...can it be trusted
anywhere else?
Remember, a number of us are defending pgp/gpg in social media for
general use. IIRC, Joanna recently has. Does it make sense to
assume Qubes backups or updates are special cases? This issue
should be taken to the GnuPG and OpenPGP fora.
Yes, I think the argument can be made that Qubes backups and dom0
updates are both special cases in Qubes, since both directly concern
the security of dom0. By contrast, using GPG in an AppVM is far less
security-critical, and the risk is mitigated even further with Split
GPG.
GPG is used by developers, whistleblowers, activists and journalists on
X number of platforms. Some of those platforms use it for secure system
updates. Sorry, but this aspect of Qubes isn't special --- When
non-Qubes users use GPG in whatever role, it is just as critical to
*their* security.
Perhaps we meant something slightly different here: All the
normal distro packages *for dom0* (e.g., Fedora 23 packages, in
the case of R3.2) would have to be included in the Qubes repos in
order for such a solution to be effective. Even this would be
true only if the custom solution were repo- or package-dependent,
and only if we wanted to guarantee secure updates using the new
method for all of those packages. (There's a lot to be said for
making dom0 smaller, and minimizing the number of packages
installed there accords with that notion.)
[2] This would seem to be a significant design flaw (perhaps a
flaw in the OpenPGP spec).[3] It means that GPG does either
mac-then-encrypt or mac-and-encrypt rather than the superior
encrypt-then-mac.[4]
[3] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html
[4]
http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html
No. 3 is really old. Does it still apply? Is there really no option
that results in encrypt-then-mac?
No idea.
No. 4 is interesting, but no mention of PGP and it seems focused on
AES.
IANAC, but I think this is a general cryptographic principle. I don't
see any reason to think that it's implementation- or
algorithm-specific. (BTW, we do use AES as the default encryption
algorithm in Qubes backups.)
On update packages -- Since they're not encrypted (only signed),
does it matter? Furthermore, its the repo manifests that are signed
(at least on Debian).
Indeed, it does. That's the central point here. If GPG does too much
pre-parsing before verification, and if that's why we rejected it for
the backup system, then we ought, on pain of inconsistency, to reject
it for the same reason in the dom0 update system.
I worry that a foolish consistency may be setting in.
Chris
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/a3e7d92a-9e31-e02d-6e33-57ee7642bc82%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
