[langsec-discuss] delimited base64 file specification

lee hughes toxicnaan at gmail.com
Thu Mar 21 10:36:52 UTC 2013

So, just because i've installed a new multiterrabit routing platform, it's
now okay to send uncompress data everywhere? what about encryption, most
schemes compress, and then encrypt.

If bandwidth is unlimited and scales on moores law (it doesn't). the i can
just transmit binary data to you like this via email.


There you go, job done! I think there's no denying what that is..however
256 bits for ever 1 bit i send you! awesome! :-)

oh no! was that stream big endian or small endian!! DOH!



On Wed, Mar 20, 2013 at 4:00 PM, Grawrock, David
<david.grawrock at intel.com>wrote:

> On the compression side, I agree that we shouldn't really be too worried
> about the size and that the complexity is not worth the gain.
> The argument doesn't hold on the integrity side. One of the points of
> delimited base64 is to avoid weird machines and other such gotcha's. Well
> having the data change is a big gotcha. Passing off integrity means that
> NOBODY can ever trust the file. It's what we have today. Few, if any, file
> formats include their integrity metrics. Now I admit a bit of a bias
> towards trusted solutions, but I think that it is critical to make this
> type of definition to include integrity checks.
> At a minimum, there should be a provision to include an integrity check at
> the end. Result of a hash maybe? That would give those who care the ability
> to provision their files with checks that all can validate regardless of
> the transport or storage mechanism.
> David Grawrock
> Security Architect
> 503 264 3642
> -----Original Message-----
> From: langsec-discuss-bounces at mail.langsec.org [mailto:
> langsec-discuss-bounces at mail.langsec.org] On Behalf Of Michael Ossmann
> Sent: Wednesday, March 20, 2013 8:38 AM
> To: Felix 'FX' Lindner
> Cc: langsec-discuss at mail.langsec.org
> Subject: Re: [langsec-discuss] delimited base64 file specification
> On Wed, Mar 20, 2013 at 04:12:42PM +0100, Felix 'FX' Lindner wrote:
> >
> > It's hard enough to get one thing right. And by the way, wouldn't the
> > compressed data form another language?
> Clearly.  My point is not that I want to recommend archival/compression.
> (I certainly do not want to include any such function or recommendation in
> the delimited base64 file format specification!)  However, files will be
> stored/packaged/encapsulated in various ways with various benefits and
> risks.  People who are concerned about the base64 expansion or who want
> features like integrity checking have several archive format choices
> available to them.  While these things may be problematic in practice, I
> don't have a problem with them in theory, and I consider them to be out of
> the scope of the file format specification.
> > The cost of bandwidth and storage decreases constantly, so why bother
> > with the past when designing for the future?
> You make an excellent point, but I'm afraid there will always be people
> with a need to push the limits.
> _______________________________________________
> langsec-discuss mailing list
> langsec-discuss at mail.langsec.org
> https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
> _______________________________________________
> langsec-discuss mailing list
> langsec-discuss at mail.langsec.org
> https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.langsec.org/pipermail/langsec-discuss/attachments/20130321/dcfedfed/attachment-0001.html>

More information about the langsec-discuss mailing list