By using the file-lock box key generated above as a seed, we can bootstrap
the seed into file-sign and file-verify keys as follows. Let the version
file-sign key be
and the corresponding file-verify key be
. In Plutus
is stored in file's header in the clear,
signed by the owner to protect its integrity. Note that all files in the
filegroup with the same version have the same value for
.
When a user is revoked, the owner picks a new RSA modulus
, and
rotates the file-lockbox key forward to
. Using the latest seed
,
owners and readers generate the file-verify key as follows. Given the seed
,
is calculated by using
as a seed in a pseudo-random
number generator. The numbers output are added to
and tested
for primality. The first such number is chosen as
. The conditions
that
and
is a prime guarantee that
[28], making it a valid RSA public
key. (Notice that the latter test cannot be performed by readers because
they do not know
). The pair
is the file-verify key.
Owners generate the corresponding RSA private key
and use it
as the file-sign key. Since writers never have to sign any data with old
file-sign keys, they directly get the latest file-sign key
from
the owner. If the writers have no read access, then they never get the
seed, and so it is hard for them to determine the file-verify key from the
file-sign key.
Given the current version seed
, readers can generate previous version
file-verify keys
, for
as follows. They first rotate the
seed
backwards to get the seed
, as described in the previous
section. They read (and verify) the modulus
from the file
header. They then use the procedure described above to determine
from
and
.
The reason for changing the modulus after every revocation is to thwart a
subtle collusion attack involving a reader and revoked writer - if the
modulus is fixed to, say
, a revoked writer can collude with a reader
to become a valid writer (knowing
,
, and
allows them to
factor
, and hence compute the new file-sign key).