Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new

Michael Demmer <demmer@cs.berkeley.edu> Thu, 26 May 2005 18:48 UTC

Received: from pisco (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j4QImQV08771; Thu, 26 May 2005 11:48:26 -0700
Received: from demmer by pisco with local (Exim 4.50) id 1DbNP8-0001Ak-4g; Thu, 26 May 2005 11:48:26 -0700
Date: Thu, 26 May 2005 11:48:25 -0700
From: Michael Demmer <demmer@cs.berkeley.edu>
To: dtn-security@mailman.dtnrg.org
Cc: dtn-dev@mailman.dtnrg.org
Subject: Re: [dtn-security] Re: [dtn-dev] Re: SDNV-new
Message-ID: <20050526184825.GE4301@pisco.cs.berkeley.edu>
References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <42944BEF.7090007@cs.tcd.ie> <20050525152006.GA7633@pisco.cs.berkeley.edu> <42949E83.9050000@cs.tcd.ie> <20050525163707.GB14911@pisco.cs.berkeley.edu> <4294ABB9.5010009@jpl.nasa.gov> <20050525172205.GD14911@pisco.cs.berkeley.edu> <20050526002442.GE28634@pisco.cs.berkeley.edu> <4295F1AF.5020607@jpl.nasa.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4295F1AF.5020607@jpl.nasa.gov>
User-Agent: Mutt/1.4.2i
Sender: dtn-security-admin@mailman.dtnrg.org
Errors-To: dtn-security-admin@mailman.dtnrg.org
X-BeenThere: dtn-security@mailman.dtnrg.org
X-Mailman-Version: 2.0.13
Precedence: bulk
Reply-To: dtn-security@mailman.dtnrg.org
List-Unsubscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=unsubscribe>
List-Id: DTN Security Discussion <dtn-security.mailman.dtnrg.org>
List-Post: <mailto:dtn-security@mailman.dtnrg.org>
List-Help: <mailto:dtn-security-request@mailman.dtnrg.org?subject=help>
List-Subscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=subscribe>
List-Archive: <http://mailman.dtnrg.org/pipermail/dtn-security/>

> I don't much care one way or another.  Do we really think we're
> likely to need to represent numbers bigger than (2*68) - 1 in SDNVs?

Very doubtful if all they're used for is lengths, maybe so if they're
used for other things like crypto keys and such. 

> If so, what convinces us that we're likely to need 16 bytes but not
> equally likely to need 128 bytes?  Certainly we can use an encoding
> scheme like this, or lots of others (for example, 1 2 4 8 16 32 64
> 128), but the fact that we can doesn't necessarily mean we should.
> What's the rationale for this particular system?

Well -- mostly a gut feeling at the time that we may find 12 and 16
more useful than 5 and 7, but I confess that I don't have any
particular proposed use cases or concrete justification for this
feeling. So I'm really fine either way as well.

-m