age icon indicating copy to clipboard operation
age copied to clipboard

Missing repeated recipient detection

Open mykhal opened this issue 4 years ago • 3 comments

Environment

  • OS: Linux
  • age version: 1.0.0-rc.3

What were you trying to do

Checking what happens if the same recipient pubkey is given multiple times (which can happen by mistake, when encrypting to multiple recipients).

What happened

No failure or warning. Resulting encrypted file is larger, containing unnecessary multiple master file key items for the same recipient in the header. (Also note that age happily encrypts empty file.)

$ r=age1recjpjentexampleeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeq7xc72d
$ age -o 1.age -r $r /dev/null
$ age -o 2.age -r $r -r $r /dev/null
$ age -o 3.age -r $r -r $r -r $r /dev/null
$ stat -c '%s %n' ?.age
200 1.age
298 2.age
396 3.age

mykhal avatar Jun 22 '21 22:06 mykhal

In Python, I'd do at least set() on provided recipient list. Should not be serious memory issue even though number of recipient is theoretically unlimited now.

mykhal avatar Jun 25 '21 07:06 mykhal

While undocumented, for key types other than SSH-RSA repeating recipients does allow obscuring the total number of recipients in a way that is traceable by the recipients (as opposed to adding randomly generated keys and throwing away the private keys). Note that this is only the case iff age generates a new ephemeral secret for every stanza (as this go implementation does) and would not work if age used the same ephemeral secret across stanzas (as the spec allows).

I'm not sure that age should have that as a feature, but some people might find it useful and since it comes for free...

neinseg avatar Jul 25 '21 20:07 neinseg

would not work if age used the same ephemeral secret across stanzas (as the spec allows)

The design document didn't specify it, but the v1 spec spells out that

A new ephemeral secret MUST be generated for each stanza and each file.

FiloSottile avatar Jul 07 '22 16:07 FiloSottile