Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #8678
| Newsgroups | comp.lang.java.programmer |
|---|---|
| From | Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> |
| Subject | Re: Playful puzzle |
| References | <liu297tqgcph2150vrav92oj4k5676h1li@4ax.com> |
| Message-ID | <slrnj963r8.6gl.avl@gamma.logic.tuwien.ac.at> (permalink) |
| Date | 2011-10-10 15:29 +0000 |
Roedy Green <see_website@mindprod.com.invalid> wrote: > I offer this is the spirit of play. It is not a serious problem. :-) > Lets say you had a PAD file that among other things included the > zipped size of the distributable inside it in ASCII bytes. But the > PAD file itself is inside the distributable. > In the worst case, how many times must you adjust the size in the PAD > and rezip with java.util.zip if you want to be 100% sure it is bang on > accurate? In the worst case, you might never ever get a bang: e.g. you start with number 00000, and may get a zipped file of 55554 bytes, then you write 55554 (with a tiny bit more entropy) and now get 55555 bytes. Then you write 55555 (which that tiny bit less entropy) and get 55554 bytes... PS: I have no idea, if such cycles will really show up, but it appears plausible to me that they could... PPS: there may, however be a way out: By giving a slightly larger size and a means to add further entropy into the pad-file or into an extra file of the distributable, you can add just as much rubbish, until the initial size-overestimate is reached - and if it is surpassed rather than reached, then re-iterate with incremented size-estimate.
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar
Playful puzzle Roedy Green <see_website@mindprod.com.invalid> - 2011-10-09 03:45 -0700 Re: Playful puzzle Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-10-10 15:29 +0000 Re: Playful puzzle Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-10-10 11:53 -0700
csiph-web