Deploying ECC-based SSKs may involve changes to how SSKs are stored, so I need to reopen the debate on how big SSKs should be. Given we have some experience of messaging apps, what is the ideal size for an SSK's payload?
We can support more than one size, but variable sizes will make storage more
difficult and will mean variable timeouts, so I am reluctant to support more
than two sizes.
For top blocks for splitfiles, FLIP posts and so on, IMHO 512 bytes of payload
would be plenty. It has the advantage that it will fit in a single packet
complete with headers and pubkey, and we can fit it into a single slot in the
SSK cache/store (ignoring the pubkey store), without having to make major
changes involving moving data around.
However for forum posts, messages can be quite big especially if they quote
lots of prior messages, or include lots of hints. So it may be better to have
fairly big SSKs - 4KB or even 32KB?
I'm inclined to make the key strength configurable, from secp256r1 up to
secp521r1.
My other thought is maybe we could go straight to PSKs and not rebuild SSKs at
all? In which case we should probably have a standard maximum size (e.g. 1024
bytes), some basic headers (e.g. for decryption on the client node), and the
rest is divided between program, fixed data, variable data, and payload however
is appropriate for the particular type of key being emulated. E.g. a native
SSK; an SSK with revocation support; a multi-signer key; a hashcash key; etc.
The program and fixed data are constant for a particular PSK URL (the routing
key would be made from the hash of {program data, variable data,
E(H(docname))}), but the division between the variable data and the payload
might vary per key; but it should be predictable enough for the client layer.
A simple multi-signer key would require two signatures (2*72 to 2*139 bytes)
and one pubkey (91 to 158 bytes). So even if we implement it directly rather
than doing PSKs, it would still have longer headers than are needed for a plain
SSK.
A further possible complication is we might want to throttle PSKs independently
of SSKs due to CPU load? We can however impose any arbitrary restrictions we
need on PSKs, e.g. no more than 2 signature verifications, 3 hashes, 1024
trivial operations, etc.
So the big questions are:
1. How big should SSKs be? (Possibly two sizes)
2. Do we want to keep SSKs separate from PSKs?
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
