Wiring up MD5

["Adam R. B. Jack" <aj...@trysybase.com>]

Ok, here is what I am thinking, and I'm asking for feedback.

We have an MD5 checksum file associated with an artefact we are wishing to
download. We download/read the checksum, and then download the artefact,
creating a checksum ourselves, comparing it to that original.

Personally, I believe that we ought go to extreme measures to not leave any
artefact on disk if it failed a check [even if we are CTRL-C'ed], since it
is potentially tampered with. Even if we know it is bad, once taken out of
the context of our code (and it'd be available on disk) others might become
victim to it.

As such I'd like to develop something like a stream that does the MD5 check
as it is being written to, wrapped around some sort of tempfile(). If a
stream isn't overkill, then the MD5 check could complete in the close() and
if failed, perhaps destroy the file. We could attempt to re-write it with
blanks, then try to delete it.

Anybody got any thoughts on this? Anybody got any experience with similar
things?

regards,

Adam
--
Experience the Unwired Enterprise:
http://www.sybase.com/unwiredenterprise
Try Sybase: http://www.try.sybase.com

Re: Wiring up MD5

["Markus M. May" <mm...@gmx.net>]

>> You know about java.security.DigestOutputStream and the similar 
>>java.crypt.MD5OutputStream from the cryptix package, right?  It should 
>>be fairly straightforward to achieve what you want using either of these.
> 
> 
> Nope, I didn't (I am clueless in this area), thanks.
> Markus, any comments?
Jepp, hello,
sorry for the late reply. Currently kind of busy :-(
Anyway, DigestOutputStream handles the digest in the following way:
First of all you have to activate the stream by turn it "on". After it 
is on, every call of the write method (any of them actually) will update 
your digest, meaning that it will update you hashcode you will receive. 
In the HashCodeManager class we use already the DigestInputStream. 
Obviously the InputStream uses the read instead of the write methods to 
update the Digest :-)
The big thing is, that we throw away the stream, therefor it is just 
used for reading the file. Obviously we could extend this a little bit. 
I am not really sure, where we should implement something like this. 
Probably the best place would be the common component. another thing is, 
when this should be executed? during the download, or afterwards? I 
thing afterward is a pretty good quess, but also this is a waste of 
resources, since then we are touching the same file three times 
(downloading, checking and finally copying to the correct name). Also in 
my opinion there should be an option like "strictSecurityCheck" which is 
set to true by default but could be turned off. This is especially 
necessary when you are working in a closed source environment, where not 
every file gets an MD5 hashcode.

What do you think?

R,
Markus

> 
> regards
> 
> Adam
> 
> 

Re: Wiring up MD5

["Adam R. B. Jack" <aj...@trysybase.com>]

> You know about java.security.DigestOutputStream and the similar 
> java.crypt.MD5OutputStream from the cryptix package, right?  It should 
> be fairly straightforward to achieve what you want using either of these.

Nope, I didn't (I am clueless in this area), thanks.
Markus, any comments?

regards

Adam

Re: Wiring up MD5

[Michael Davey <Mi...@coderage.org>]

Adam R. B. Jack wrote:

>  
>
> As such I'd like to develop something like a stream that does the MD5 
> check
> as it is being written to, wrapped around some sort of tempfile(). If a
> stream isn't overkill, then the MD5 check could complete in the 
> close() and
> if failed, perhaps destroy the file. We could attempt to re-write it with
> blanks, then try to delete it.
>
> Anybody got any thoughts on this? Anybody got any experience with similar
> things?

You know about java.security.DigestOutputStream and the similar 
java.crypt.MD5OutputStream from the cryptix package, right?  It should 
be fairly straightforward to achieve what you want using either of these.

-- 
Michael