-----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 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. > >> 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. - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYZ+AxAAoJENtN07w5UDAwnN4QAKptm9zQoNuIS/bQY5ibBYrV Omrb9w5Is1YO4Jfl5Ci+F/qBEC9vavJst3j8HrT03VgZHehNNnCnvZke91znjo9Z jM/bKfiPInCkSlNmQBCa/ihriDQcpFm0h4Kcec4VmWcLadxR8xb5xK1Ikfpj6NvS nQIQJB1oHPuMSrIDCDCJITHszW2TBeQptal3fS7NNHswgehjkLkJ+vuoGCJEZM+h aom6e5RewW/uzk+UcvdMS7h17PNeRFU8WP5o96g+bJrkS5XVgL7/jZ7N5kcmjZel TTZ/mqjORtjUm1QjMNlxbqrxK2nOw9hgQ3PI5pilRoUVhZ0lxojTk7uCI8gL4L2N oNXqs3VN4wVVqfFiZxu7vxGGo6DK6WgaKUfVyUgql5Tp4IDQPVZDrTENB18mM6ER 7oZ9JEtfM5tdogc1DsOqAYGU8BdbMQB90byzv9wPxllyQ14yVUs8BqCpQATnOOIf ubl9QKzjRuNvKahxwjRG0OZ/MT+SFwXVkjOPj/+E3m/3zgeYyQ9qtBV1rRkW0UAE gWQyUhnU43LD+Q0uYoUSoWluFF8MwkGzKPIZphjgW9hMTQgppzmvuuM9rVKafdQX Na1FTGONoDcfbmPsSG51Y/7kl+I3+wZ64d5hHNwTXuDKvcQWADiysIx9RXxDkFwq AKMjT73pfEjcreMGRqU2 =2bhn -----END PGP SIGNATURE----- -- 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/017e4d0e-5570-ea4b-43f7-a068dc863521%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
