On Saturday 26 January 2008 19:12, bbackde at googlemail.com wrote:
> On Jan 26, 2008 12:55 PM, Michael Rogers <m.rogers at cs.ucl.ac.uk> wrote:
> > bbackde at googlemail.com wrote:
> > > Maybe it would help if we would be able to retrieve a KSK without to
> > > retrieve the underlying CHK. Then we could check the underlying
> > > CHK at .... key if we already know this key. In this case we could choose
> > > to not to retrieve the CHK and therefore stop pushing the request
> > > stats for this CHK? I don't know if this makes any sense.
> >
> > If we've already retrieved the CHK it will be in the cache, so
> > retrieving it again won't do much except pull it to the top of the
> > cache. But I think you're onto something - is the signature in the KSK
> > or the CHK? If it's in the KSK, maybe Frost could check the signature
> > and choose not to retrieve the CHK if the message won't be displayed
> > anyway (eg the identity's status is CHECK and the user has configured
> > that board to hide CHECK identities)?
> 
> If you mean the signature that Frost creates and checks, its of course
> in the data, in the CHK.
> I don't know if there is a signature or filehash in the KSK, but I
> know that we can't retrieve
> a KSK or its properties via fcp2 currently. When we retrieve a KSK,
> the CHK is always retrieved
> and we only get the data. There is no way to store or retrieve
> application data inside a KSK (or CHK).

You could insert a binary KSK (no mime type, application/octet-stream) which 
includes some frost metadata including a signature and a pointer to the real 
payload - an application level redirect (must be <1kB after the node gzip's 
it).

Then you could verify the signature and not download the message if 
don't-show-CHECK-messages was turned off for that board???
> 
> > Cheers,
> > Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20080126/63fd5e2e/attachment.pgp>

Reply via email to