Re: Experimental did:cel Witness Service (open-source)

I wonder if the concern of sizes is warranted.  I remember a report from
the Plan 9 people some 40 or more years ago that their disks were getting
emptier over machine generations.  Back then the growth in the amount of
data was swamped by the increase in storage density.

Does that observation apply today?  I have no idea, but it's what I see on
my own machines.

--------------
Alan Karp


On Wed, Mar 11, 2026 at 10:49 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On Wed, Mar 11, 2026 at 10:38 AM Stephen Curran
> <swcurran@cloudcompass.ca> wrote:
> > I've been thinking about log size recently, particularly when combined
> with PQ cryptography.  It seems to me that as we shift to the use of PQ
> algorithms, the size of the data will be dominated by the keys and
> signatures, and compression techniques will be much less useful. So if a 10
> year log has 5 years of PQ keys and signatures will not benefit much from
> compression.
>
> Maybe. :)
>
> I expect that keys that are re-used will be compressed greatly,
> compression is going to help a lot there (the same public key might be
> listed thousands of times, but will only need to go in the compression
> table once and from there on out, will take up a few bytes instead of
> thousands of bytes).
>
> However, if per-event pre-rotation is in play, you're right --
> compression isn't going to help you at all. This is one of the reasons
> did:cel doesn't do pre-rotation per event, though did:webvh escapes
> the worst of it (I think?) by externalizing the signatures.
>
> My hope is also that SQISign will win out over the current PQ
> standards, which have really large key sizes and signature sizes. For
> example, SQISign at security level "NIST I" has 64 byte public keys
> and 148 byte signatures.
>
> https://sqisign.org/
>
> ... which puts it in roughly the same category of storage requirements
> as elliptic curve signatures (~2x-ish more storage required for
> SQISign signatures, not the ~37x-ish storage needed for MLDSA or the
> ~122x-ish storage needed for SLHDSA).
>
> But, you're right... if we stick with MLDSA or SLHDSA, the total data
> you have to retrieve (no matter the log format) is going to balloon to
> 37x to 122x. I think, Stephen, did:webvh has a design pattern to get
> around this -- can you please remind me what happens there? I know you
> externalize into two separate files, but what I'm wondering is if you
> have to download both to verify (if you don't cache, that is).
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>
>