Re: [dtn-security] SDNV

[Scott Burleigh <[e-mail]>]

John S Segui wrote:

>I am currently working on a DTN simulation project and have read the interesting email exchanges regarding SDNVs. First, I would like to say that I agree with the current push to unify SDNV-8 and SDNV-16. However, while the proposed SDNV nicely allows for relatively large length fields, it has an upper limit in length. So my question is: is there any reason SDNV should not handle variable length fields of all sizes?
>
>One method for handling infinitely long fields is to nest SDNVs. For instance, make bit two of the SDNV discriminant byte signify whether the SDNV nests another SDNV. In this case, the “root” SDNV follows whatever agreed upon standard for root SDNV encoding but its numerical value represents the length (in bits) of the *length* field in the nested SDNV (e.g. SDNV{SDNV}, SDNV{SDNV{SDNV}}, etc.). This is somewhat similar to the proposed method of encoding the length of the following field inside an SDNV, but has the added benefit, through nesting, of allowing infinite length; thus avoiding the Y2.1K bug.
>
>An alternative (suggested by a co-worker) is to chain SDNVs together. For instance, let bit two of the SDNV’s discriminant byte signify whether the field overflowed into another SDNV.
>
>In conclusion, there appears no reason why we can’t have a standard fully scalable data type to handle all variable length fields, including ever-growing crypto keys. Also, neither suggested method seems more complex or simpler than the current method. Comments?
>  
>
This is a pretty elegant idea, John, especially the nested variant, but 
I don't think I'd favor changing.  One disadvantage of both these 
approaches is that you lose the second bit of the discriminant, reducing 
the maximum size of the value you can represent in one byte from 127 to 
63; having to use two bytes to encode values on a fairly common scale 
like 1-100 doesn't seem attractive.  At the same time, it's not clear 
that we'll need to be able to represent numeric values of infinite 
length in these protocols.  For some kinds of math research I can 
imagine the nested SDNV structure being pretty handy, but using the SDNV 
to encode the length of a field (such as an encryption key) lets us have 
fields whose lengths are up to (2^68) bytes; I think that is likely to 
be plenty.

Scott