The remote Windows admin was not as timid as thought. Given the hex diff, he repaired the file himself (w/o me giving him pointers to tools gathered from this thread) <br>He reported successful decryption.<br><br><div class="gmail_quote">
On Thu, Apr 24, 2008 at 1:17 PM, Jerry Yu <<a href="mailto:jjj863@gmail.com">jjj863@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I meant "The presence of CR or NL in the encrypted file" instead of "The presence of CR or NL in the plain-text", near the end of the 2nd paragraph.<div><div></div><div class="Wj3C7c"><br><br><div class="gmail_quote">
On Thu, Apr 24, 2008 at 1:14 PM, Jerry Yu <<a href="mailto:jjj863@gmail.com" target="_blank">jjj863@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Greg,<br><br>that was my initial assumption too, with two twists. <br><ul><li>The \r\n is not an EOL, but part of a file encrypted in binary format.<br>
</li><li>the \r\n is on our Linux (RHEL5/ppc) server, while the \n only version is on the Windows server to be decrypted. I expected the other direction.<br>
</li></ul>I tried to spare the list the gory details of the whole thing when I initially posted the question. The file actually jumped a few more hops (outside my control, mainframe and all that) to get decrypted. Only one or two out of twenty files will get screwed like this. My theory is these one or two encrypted files happen to use \r, \n, or both in the middle of the file, just as it uses 'a' or 'b'. The presence of CR or NL in the plain-text, causing decryption to fail, if any \r \n or both get dropped or inserted <i>en route</i>.<br>
<br>Long-term, I proposed to switch to armor text to avoid non-ascii in the encrypted files. GPG can survive a unix2dos transformation. <br>For troubleshooting, I wants the final destination to verify decryption with the exact file on our Linux server (by repairing the 'bad' one) and make sure it is absolutely not an encryption/decryption problem, but a transmission problem. No good & secure channel exists to ensure the final recipient receive an exact replica.<div>
<div></div><div><br>
<br><div class="gmail_quote">On Thu, Apr 24, 2008 at 12:33 PM, Greg Freemyer <<a href="mailto:greg.freemyer@gmail.com" target="_blank">greg.freemyer@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Jerry,<br>
<br>
I just looked at your diff again and realized it really is a binary<br>
file, not a text file so a simple editor like I described won't work<br>
most likely.<br>
<br>
I bet you FTP'ed it in text mode and thus the corruption. If you have<br>
to resend it, be sure to use binary mode in FTP.<br>
<font color="#888888"><br>
Greg<br>
</font><div><div></div><div><br>
On Thu, Apr 24, 2008 at 12:29 PM, Greg Freemyer <<a href="mailto:greg.freemyer@gmail.com" target="_blank">greg.freemyer@gmail.com</a>> wrote:<br>
> Jerry,<br>
><br>
> If you look closely at the diff, you have a \n in the first and \r\n<br>
> in the second.<br>
><br>
> \n is the Unix / Linux way<br>
> \r\\n is the Windows way (iirc).<br>
><br>
> Assuming \r\n is never valid in this doc, then there are several<br>
> little converters available to do that. I think just bringing it into<br>
> vi and saving back out will do it.<br>
><br>
> Greg<br>
><br>
><br>
><br>
> 2008/4/24 Jerry Yu <<a href="mailto:jjj863@gmail.com" target="_blank">jjj863@gmail.com</a>>:<br>
><br>
><br>
> > what tool can I suggest a remote Windows admin to use to 'repair' his binary<br>
> > file given the hex diff below.<br>
> > Of course, if this 'repair' is too hairy, I'd go down the retransmission<br>
> > route (expensive).<br>
> ><br>
> > diff meta.od-x tpp.od-x<br>
> > 24,25c24,26<br>
> > < 0000560 6b92 d311 01fb f7be 402c c959 a125 0ac4<br>
> > < 0000600<br>
> > ---<br>
> > > 0000560 6b92 d311 01fb f7be 402c c959 a125 0d0a<br>
> > > 0000600 c400<br>
> > > 0000601<br>
><br>
> > _______________________________________________<br>
> > Ale mailing list<br>
> > <a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
> > <a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
> ><br>
> ><br>
><br>
><br>
><br>
> --<br>
> Greg Freemyer<br>
> Litigation Triage Solutions Specialist<br>
> <a href="http://www.linkedin.com/in/gregfreemyer" target="_blank">http://www.linkedin.com/in/gregfreemyer</a><br>
> First 99 Days Litigation White Paper -<br>
> <a href="http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf" target="_blank">http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf</a><br>
><br>
> The Norcross Group<br>
> The Intersection of Evidence & Technology<br>
> <a href="http://www.norcrossgroup.com" target="_blank">http://www.norcrossgroup.com</a><br>
><br>
<br>
<br>
<br>
--<br>
Greg Freemyer<br>
Litigation Triage Solutions Specialist<br>
<a href="http://www.linkedin.com/in/gregfreemyer" target="_blank">http://www.linkedin.com/in/gregfreemyer</a><br>
First 99 Days Litigation White Paper -<br>
<a href="http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf" target="_blank">http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf</a><br>
<br>
The Norcross Group<br>
The Intersection of Evidence & Technology<br>
<a href="http://www.norcrossgroup.com" target="_blank">http://www.norcrossgroup.com</a><br>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>