3 ms·
Very neat, but my preference would be for it to very rarely expand the file, instead of very rarely rarely decompressing wrong. Then you could actually use it i
by im3w1l 5y ago
Very neat, but my preference would be for it to very rarely expand the file, instead of very rarely rarely decompressing wrong. Then you could actually use it in practice. It would be pretty straightforward to change it as far as I can tell.
Edit: If c+1 would wrap around, you could fallback on encoding as C0(x) || enc(0) || Mac(C0(x) || enc(0)).
- assbuttbuttass 5y agoIsn't it just a normal compression algorithm then?
- im3w1l 5y agoNo, a normal compression algorithm will often (as opposed to very rarely) expand the output when given a random input.
- assbuttbuttass 5y agoI don't think you could expect this to do any better, though. Apparently this algorithm uses DEFLATE under the hood
- goldenkey 5y agoMost compression algos have a simple flag to indicate an embedded file for cases where compression is not workable. All the same principles still apply, it's just that the compression algo is now meta of sorts.
- labawi 5y agoIf the MAC and construction is solid, then wrong decompression is achievable, both theoretically, practically and by design, in many different ways except the one you mention - the rare collision. There likely won't be enough computation, ever, to trigger an accidental collision, even if was a galactic bitcoin equivalent. I'd only be worried about deliberate collisions, if the construction isn't sufficiently hard.