Why proof of freshness?

108 views
Skip to first unread message

iry

unread,
Apr 1, 2017, 2:56:58 AM4/1/17
to qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi everyone,

Qubes has been using the feeds from several news websites in its
[Warrant
Canary](https://github.com/QubesOS/qubes-secpack/tree/master/canaries)
to prove that the warrant was not created in advance.

However, I am not sure why we need the proof of freshness here. In
other words, what kind of threat model has been considered
when deciding to include this section?

I have been thinking about several threat models, but none of them
makes much sense. Could anybody help me with the question, please? I
will be really appreciated!

Best,
iry
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJY308oAAoJEKFLTbxtzdU8R3kP/3SA4qhDqTIdfPDagllPxXGh
i1Q8pZSYYsZsOcxEmiIIeG+JnxFRKbA0hAXxl2zGm75ckSg/WdtlN660AJ2Zd3h3
rwsTXDaGhn/sLr4pXqzX3SSg2hnCMP3GV/N7of+hQC/Wo9ZO5e8mW122ZQvWnoPM
niVljO+FSBAxqXjni4SfU0rxBmwUonpwl5llM85KlaYUmOjWmS5h2g6SOibfwiFm
7roFoYtQLhesA+dbMWUyttFAHNhFFGsXLoZmQocbYmwZCWsOWmz9msE39K5ktJN5
/8WY/+MYKB8muP9Li5ke4Dy9JeaCY7PtIcLkGqAzFRt1piiS5kUIBNcJC9Rxln+T
UAmkI6HqBDyJZSmpuXGGKwQPdVJ255QBpAQaCvIvDRl0+USgIm3IT7bfq9L6Hj7Z
DncPmNnu1c+pqnOUxjSYVMDVB2pdzVk3UWGQO1OBCcbR/jndtwXS2Yp/kNMEhsN+
PSC20YH4lgJJgxljy4XJyvTFpyOJ6mdwwwP/ut/vBG+o7LVin69qUprK7GNXqE17
hUmLw2kITetRlBC1MZEOA8n89cLTc5QfDfFFXcl+NMMaqDjo8fdHjG3C75hZ4NoF
/bLk1MN7ISZV0JkPw2wJjdh+UHVJ31cc9jSsnBHM4nLbIiYBnX3hk8N6YxHSYiTz
REkPHifkvrFxJijoHZ0+
=eSBU
-----END PGP SIGNATURE-----

Radoslaw Szkodzinski

unread,
Apr 1, 2017, 4:30:37 AM4/1/17
to iry, qubes...@googlegroups.com
Easy to answer:
The proof of freshness is simply to show these were not made ahead of
time and then released later after a compromise to fool everyone.

iry

unread,
Apr 1, 2017, 1:39:18 PM4/1/17
to Radoslaw Szkodzinski, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Radoslaw, thank you very much for your reply!

Radoslaw Szkodzinski:
> Easy to answer: The proof of freshness is simply to show these
> were not made ahead of time and then released later after a
> compromise to fool everyone.

Could you please tell me "these were not made ahead of time" by whom?

If it is used to prove "these were not made ahead of time" by Qubes
developers, then it is assuming that we do not trust the Qubes
developers who made and signed the warrant.

1. But if we do not trust them not signing the warrant in advance, why
can we trust what they said in the warrant? Won't the whole warrant
become meaningless?
2. Besides, if we do not trust them, we can even assume they are just
using a script that can generate, sign and publish the warrant
automatically every certain length of time.

If we trust the Qubes developers who made and signed the warrant,
shouldn't the system date included in the signed message blocks be
enough to prove the freshness?

If it is used to prove "these were not made ahead of time" by an
adversary, then it may make a little bit more sense.

Thank you very much! I am Looking forward to a further discussion!

Best,
iry

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJY3+W0AAoJEKFLTbxtzdU8QUAP/0zHrM8xyyZ8TngQsDvXMFed
wKG1Fsg1t0gOM6sZKPtR2hmpEQ6f4Hx5hqhySP0r5dZBRAhLKoUdn0h318tdwA0y
f84utL49PY+wkqWteb80daoI1EcUw5s/2xNewbtmw5Xa6VYCrB4jxNAtvt9sZzu6
JbbyZtsSO+ir0xOyLnB2dqREbvo5D1jJ8r10YixafToc5WLKUAQWQ51LXViHk6Sa
dh5Cgc7OvjL3OSA+mxfn2uWPra80EBAGDmZiAFMrHj1p1mk9K9JIqske51e15jKO
W253tjrZA+QoBIDwpcYRDbzoCfqJ3cHIwThPkemu9KU/AWLKQJ1JsrqKLdLi95zF
Glqy7Ae7Nghb3FntQ0zDQRK0nTXAcmshKQfk4CQ9qMCQOIM0czScUT6DK8UMyaZi
1X9wPa9+ZkF3ur6GVKYGo9HYp6+DvQ+jtoqs5TC620PqnPdN7Wt+Fh5t4cCq0vlD
jjvZEEQJSn1ZSX7A5wGgEyQgrU5z7HcRsZQ20LnqEM3D3dUJWtIamg+RjavVi0zB
CSC5LvS1VrFMLhxBKdVBMvOHep22V48uypv9t+QZR5JLieNiAlBbXoXwCqnhVj6R
ZSAQXfjy2ghCfhkJEMfeCYvDBIrVa4iOf4oXDkmT8icl1R2zxS4Lt0zrqvZ2eRqU
MmGh7sVzMx02hOjyZibu
=NMVC
-----END PGP SIGNATURE-----

Ivan Mitev

unread,
Apr 1, 2017, 3:24:20 PM4/1/17
to qubes...@googlegroups.com


On 04/01/2017 08:39 PM, iry wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hi Radoslaw, thank you very much for your reply!
>
> Radoslaw Szkodzinski:
>> Easy to answer: The proof of freshness is simply to show these
>> were not made ahead of time and then released later after a
>> compromise to fool everyone.
>
> Could you please tell me "these were not made ahead of time" by whom?

By the Qubes devs.

https://en.wikipedia.org/wiki/Warrant_canary

Of course, all bets are off if someone (government/hacker) gets his
hands on the private key used to sign the canary and prevents all the
devs required to sign from saying so.

hope this helps.
ivan

Andrew David Wong

unread,
Apr 1, 2017, 8:57:02 PM4/1/17
to iry, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2017-04-01 10:39, iry wrote:
> Hi Radoslaw, thank you very much for your reply!
>
> Radoslaw Szkodzinski:
>> Easy to answer: The proof of freshness is simply to show these
>> were not made ahead of time and then released later after a
>> compromise to fool everyone.
>
> Could you please tell me "these were not made ahead of time" by
> whom?
>
> If it is used to prove "these were not made ahead of time" by Qubes
> developers, then it is assuming that we do not trust the Qubes
> developers who made and signed the warrant.
>
> 1. But if we do not trust them not signing the warrant in advance,
> why can we trust what they said in the warrant? Won't the whole
> warrant become meaningless? 2. Besides, if we do not trust them,
> we can even assume they are just using a script that can generate,
> sign and publish the warrant automatically every certain length of
> time.
>
> If we trust the Qubes developers who made and signed the warrant,
> shouldn't the system date included in the signed message blocks be
> enough to prove the freshness?
>
> If it is used to prove "these were not made ahead of time" by an
> adversary, then it may make a little bit more sense.
>
> Thank you very much! I am Looking forward to a further discussion!
>

A good question, but it sounds like you're assuming a simplistic,
binary model of trust that doesn't accurately reflect trust dynamics
in the real world. Just because an assertion *can* be accepted on
trust doesn't mean that there's no value in providing proof for it,
especially if the proof is easy to produce. Providing proof in one
area (especially at consistent intervals over a long period of time)
can serve to bolster overall trust.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJY4ExMAAoJENtN07w5UDAwFkkQAKn1ODvRVUqk+5ybTZtXf4k3
3Uz2uUEvOENfxhfJtzYP9qUY8c41VhjDzT33o/ja4q0powzDHTa3XC0SGKF55bhK
F5Z9labhS9wPC6JSBLXK4WV4zx/kqPz3A0yaXluqMOviMgFu3oTiceFzd3YCau2h
IFJVX1Hu6pCWc2otJOwDgkOCw/pH/Dbmrg7/7sP+AXiwP29QVBgVGC+JIgTYhkgw
YV/JkfIYzo7H8JlORPKdxXThjjZLekKLHxIoDJ/kg8EYEjD/qQ9nswosauWddM3h
A0lLaQlbjpQI/V9bK+yzKSCy/0coyrcg82LR9oa9npf/poQ1SQVpq25gzO3522uU
OVfsm9yPDSw1pmOzzKfUFWVFLgy6OJj4jxwVCPZQoQ0IMhCsfyydn8m0B8LPDfK2
q8lOA9XXFcEU9tqfe2eRzCHjN46M/p+TXO5rPUuAq2N9jZ3WOWQbE8dP4udSzAZC
BKkceDEPJfsWPXyUNC3Q7KKV/EgUn0phQFK1xnQL4OwR3dV7/9aJinKQkVJxq/sS
rd8oyv0pQXkIHxTBpXCDK0tVgnIpP9XfY6gNf2p5dThKkrF1Eu0G/Z7+DaA+ROjH
YNwfjzPcbl42bdwfZfSgQp9MvIbP4NMPCZHvOw7M/QkAvhV3P6t+E6SbSMgihKdY
hVBoDIAoA6w+8z6fhUq7
=SlLs
-----END PGP SIGNATURE-----

Jean-Philippe Ouellet

unread,
Apr 1, 2017, 11:24:59 PM4/1/17
to qubes...@googlegroups.com, iry
Maybe one could imagine a scenario where some court-order is issued to
create fake future canaries to be released by law enforcement at a
future date. If this order is appealed and the decision reversed, then
the fake-future canaries without proof-of-freshness are
indistinguishable from real-future canaries, whereas with
proof-of-freshness you could at least tell the difference?

IANAL, but there seems to at least be at least *some* (contrived)
scenario in which it might be marginally useful. Since there's
virtually no cost or risk to including it... why not?

iry

unread,
Apr 2, 2017, 12:36:21 AM4/2/17
to Andrew David Wong, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Andrew David Wong:
Thank you very much for pointing out my logic flaw here. I agree with
you that the trust model is not binary in the real world.

> Just because an assertion *can* be accepted on trust doesn't mean
> that there's no value in providing proof for it

I agree with you that there is some extra values in providing the
proof of freshness, which has also been pointed out by Jean-Philippe.

> especially if the proof is easy to produce. Providing proof in one
> area (especially at consistent intervals over a long period of
> time) can serve to bolster overall trust.

Thank you very much for your answer, Andrew!
You've helped me think more clear now!

Best,
iry
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJY4H+6AAoJEKFLTbxtzdU8m0AP/A2JbvnsNmI4eMKcCWoCg5do
x5yB0QJLgQEyE04mndw0RZmqTLQbpKuILSwfSm5XUjnv4wT+UV4YdkNcxEiMvYBA
Qhveu1d0P/TaLgQPHuN4vardESi33spEGfh1KEH9WnkpNFOOMCO3LLgcXWqRG8uC
a45Vipd1eQhuqkGns90W/unvxky14GAkBjhZBOS/Le4wxOOAEjV0WmMgGN0aXAeb
7ROXwiLSMpHOVPyI3oyxRDaaSP2j7/fYdbatnnYUzpmnrkB723rQDJc2TBD4ipye
itDo4IhFujAcVb78Rge64lCbHnLYZ2xbB7MQnB58GlCPlAxlqlsAl/D//zId/KW4
7mzK7D99D69jvmCXqanUygb97afd1V4q0dEQ2iaqTsNX2oSnsPWtCfnPOJfKoD/E
LWuBTfuRb1yVkSlEVTIZfBROLhq88PMa3KbauOaowH2xVuf6E4ERPc1WO41BuGzU
BB1lsYbXfK8Y1yQZ7mxTttiGdc56FwbstW5Ww9Ff17IlKqlrGcGmVXL9RkeBICQe
WabR2B0O7EwRiEwzwZsjriSTHGEn2IfSiqubs7j6wv7N7wyhThm4W2Roon0iXsI9
yyu/ktXE21w1XaOwkJq7LMhg9n0zGTNn9sxIbo8s98a2xVmxdaEGQFwg9z9uFvzC
moCpiCsr5AIt+ojP929v
=C1RC
-----END PGP SIGNATURE-----

iry

unread,
Apr 2, 2017, 12:44:50 AM4/2/17
to Jean-Philippe Ouellet, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



Jean-Philippe Ouellet:
> Maybe one could imagine a scenario where some court-order is issued
> to create fake future canaries to be released by law enforcement at
> a future date. If this order is appealed and the decision reversed,
> then the fake-future canaries without proof-of-freshness are
> indistinguishable from real-future canaries, whereas with
> proof-of-freshness you could at least tell the difference?
>

Yes! This is a good case to prove that the proof of freshness can be
still useful.

> IANAL, but there seems to at least be at least *some* (contrived)
> scenario in which it might be marginally useful.

I agree. I also came up with some other scenarios where the proof of
freshness may also be useful. I will share them with you all once the
thoughts are mature enough.

> Since there's virtually no cost or risk to including it... why
> not?
>

Thank you very much for your help!

Best,
iry
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJY4IG5AAoJEKFLTbxtzdU8Yj4QAMMOTwUVNey8gcYuRSYuCRa5
8m3ur2Qv1XtuzeHmCwwKQ+slw701eLxvXvix4ajl30nzgCK+PRlubLJH+o90tHc5
40I/vk6jOH5ZBfmUubpzX2s9DHKLsL2vEYdvZG1XhrwloBm0f7RIcRJQAEZxbA9g
Snkq0/t8ido+KIZ6rkbu3aGTmT3cGKhjmTmYlALngX4gL/Mp6por7BDvRgHPvBkI
dnUVqE3FWAZoDOXnnSxsnHqSmNmMrAf5pPy/EPiZ+z8mo2I87d4GAATgbUxS3pfC
G9o0S2D6vGAXPsBWj8lRn9lCdGqMpl3TGzlVNtisPVm/9jU/6TP2Tstv4U7XxGoH
MyAMGiePRmT/37IWK4vYxeLf8jR5KDMuPT6gn3MH0jqKe+W5v34OhQOaKaPpw8V7
6pXQ9lF76s1Lf5WHq3uZWM2blnUjWcCBpJn9lqaJcUFKyjgGgENAFDFC2rkDfDPO
CdO9qbWnk90Ilop068PZDYwjKd+Uz+qeOT4Oyb0vdWFOrcODoOCsfP1BrmGemJfX
96RlXXWOl/6NHP/g7LCR8dnxh20NuzUblhpyzmc3k7UPvMG8vYI11ea4D72ECDy2
dIuwqaPY60CXk8HlSJstiVbxRDaadEGyTn1IIGOPYQ8I+6Sl2pJ8nGZSve797C3e
C3ljjcfxil8voCJ/idP4
=Em1f
-----END PGP SIGNATURE-----

Radoslaw Szkodzinski

unread,
Apr 2, 2017, 4:07:07 AM4/2/17
to Jean-Philippe Ouellet, qubes...@googlegroups.com, iry
On Sun, Apr 2, 2017 at 5:24 AM, Jean-Philippe Ouellet <j...@vt.edu> wrote:
> Maybe one could imagine a scenario where some court-order is issued to
> create fake future canaries to be released by law enforcement at a
> future date. If this order is appealed and the decision reversed, then
> the fake-future canaries without proof-of-freshness are
> indistinguishable from real-future canaries, whereas with
> proof-of-freshness you could at least tell the difference?

You mean a specific court order to forge documents? Hmm, never heard of such.
As opposed to a gag order - which this will detect by the virtue of
not appearing.
Creating the documents ahead of time would defeat the measure.

It's probably more vulnerable to covert coercion than to that. But
then again, if devs are compromised
in this way they may instead introduce more subtle backdoors or bugs.

--
Radosław Szkodziński
Reply all
Reply to author
Forward
0 new messages