On Fri, May 04, 2001 at 04:12:23PM +0200, Oskar Sandberg wrote:
> > > > So, it sounds like the way to go is to have a Storable.Client-data which
> > > > would be presumably a Base64 string-encoding of an encrypted byte array.
> > >
> > > Throwing data around in the Storables costs considerably more for the
> > > nodes then leaving the data as a unit. I'm not sure that the saved work at
> > > the client end is worth the extra work for every node.
> >
> > Remember, we're getting rid of the Metadata-length storable, and if we use
> > #2 below we're replacing it with something 26-42 bytes in length before
> > padding.
>
> So one step forward and one step back then...
Well, we could just encrypt Metadata-length, but I thought a more
general container for Client-data would be more useful (for example,
allowing us to not put the crypto key stuff at the beginning of the
document itself).
> > > > #2: decrypts to --
> > > > <2 bytes crypto key length><crypto key><8 bytes metadata length>
> > > >
> > > > Either way we can pad it to a decent length by repeating some hash
> > > > function of the data.
> > >
> > > Remember, fields are limited to 1024 bytes in length...
> >
> > 42 < 1024 :)
> >
> > Adam liked #2. Suppose we require it to be padded to a power of 2 of at
> > least 64 bytes.
>
> Where did you get 42 from? It becomes at least (2 + 18 + 8) * 2 as far as
> I can tell...
I was in binary, not hex-strings. 2+16+8 == 26 for the default crypto key
size. 2+32+8 == 42 for the current maximum.
--
# tavin cole
#
# "The process of scientific discovery is, in effect,
# a continual flight from wonder."
# - Albert Einstein
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/devl
