Message Digest MD5 Problem

My application downloads a zip file from given URL and also gets message digest (MD5) for the file.
Then, it creates another message digest and compares them.
I have tried files from tomcat.apache.org
The results are below:
apache-tomcat-6.0.20-deployer.zip (downloaded)
1b3287c53a12e935a8c965b15af39f07 --> code from the website
1b3287c53a12e935a8c965b15af39f7 --> code by the application
apache-tomcat-6.0.20.zip (downloaded)
714b973e98d47ec2df6d5e1486019f22 --> code from the website
714b973e98d47ec2df6d5e148619f22 --> code by the application
I could not understand why 0's are missing in my code. Should I try another files except from Apache?

try{
             MessageDigest algo = MessageDigest.getInstance("MD5");
             algo.reset();
             algo.update(data);
             byte messageDigest[] = algo.digest();
             StringBuffer hexString = new StringBuffer();
             for (int i=0;i<messageDigest.length;i++) {
                  hexString.append(Integer.toHexString(0xFF & messageDigest));
     System.out.println(hexString.toString());
catch(NoSuchAlgorithmException e) {
     e.printStackTrace();
}I have got the content of the file in a byte array --> data.

Similar Messages

Verifying a Digital Signature using message digest

Hi, i am new to java.
I have a Digitally signed document, i wanna verify this signed document against the original one.
i got the idea from this link:
http://help.sap.com/saphelp_45b/helpdata/en/8d/517619da7d11d1a5ab0000e835363f/content.htm
i signed a pdf doc with my SmartCard. the third party signing tool passed me the PKCS7 digital signature and i stored it in database. the problem arose when i retrieved this digital signature from DB and verified against the original doc using the message digest method. the base64 result strings are always not equal.
I am sure about this:
-the retrieved digital signature was GOOD.
-the original doc was GOOD.
but why i can't get the same 2 message digests? can somebody please help?
below is part of my code:
while (rsetDs.next())
     InputStream DSName2 = rsetDs.getBinaryStream(1);
     ByteArrayOutputStream byteStream = new ByteArrayOutputStream();
     byte[] myByte = Base64.decode(byteStream.toString());
     ByteArrayInputStream newStream = new ByteArrayInputStream(myByte);
     CertificateFactory cf = CertificateFactory.getInstance("X.509");
     Collection c = cf.generateCertificates(newStream2);
     Iterator i = c.iterator();
     while (i.hasNext())
          Certificate cert = (Certificate)i.next();
          X509Certificate cert1 = (X509Certificate)cert;
          try
               java.security.MessageDigest md = java.security.MessageDigest.getInstance("MD5");
               /*=============DB MD (BEGIN)==================*/
               byte [] pubkeyByte = cert1.getPublicKey().getEncoded();
               md.update(myByte);
               md.update(pubkeyByte);
               byte[] raw = md.digest();
               String db_md = Base64.encode(raw);
               /*============DB MD (end)============*/
               /*=============PDF MD (BEGIN)==================*/
               DataInputStream m_disFile = new DataInputStream(new FileInputStream("C:\\" + "original_doc.pdf"));
               int m_iNum = m_disFile.available();
               byte[] msgBytes = new byte[m_iNum];
               m_iNum = m_disFile.read(msgBytes, 0, m_iNum);
               md.update(msgBytes);
               byte[] digestMd = md.digest();
               md.reset();
               String pdf_md = Base64.encode(digestMd);
               /*=============PDF MD (END)==================*/
..thanks in advance.

PKCS#7 SignedData objects are far more complex then it looks like you are taking them. First the PKCS#7 SignedData object will contain the OID for the message digest algorithm used and for the encryption algorithm used. From the looks of your code you are simply assuming MD5.
It also contains all of the data that was signed which is typically much more than just the document. It also of course contains the public keys and signatures which singed the document. In your case it will probably only have one public certificate and one signature.
Also note that a signature is an encrypted hash. Looking at your code I do not see you use encryption at all or rather for verification decryption.
Here is the basic process a signature takes.
MessageDigest md = MessageDigest.getInstance(algOID);
byte[] digest = md.digest(message.getBytes(charEncoding));
Cipher c = Cipher.getInstance("RSA/2/PKCS1Padding");
c.init(Cipher.ENCRYPT_MODE, priKey);
byte[] signature = c.doFinal(digest);Note that the resulting byte array is not the message digest but the encrypted message digest. You must use the corresponding public key to decrypt the signature to get the message digest value. It is because the trusted public key can decrypt the correct message digest that we know it was encrypted by the holder of the private key. It is because the decrypted message digest value is equal to my computed message digest value that we know the document has not be altered...
Now PKCS#7 SignedData does not take the message digest of the document, in your case your PDF. It creates a message digest on an ASN.1 object which includes the bytes of your document plus a bunch of meta data.
For more info on the exact format of a PKCS#7 signature file check out
http://www.rsasecurity.com/rsalabs/pkcs/pkcs-7/index.html
Look through this doucment for SignedData as a starting place and follow through all of the sub objects that make up a SignedData object. This will give you an idea of what is involved.

Need a 64 bit Message Digest

I need a 64 (or 96) bit message digest function that acts like MD5 or something similar, but instead of spitting out 128 bit digests, it puts out either 64 or 96 bit digests. The problem is thus, we are currently using a piece of a proprietary library to create our pretty-close-to-unique keys, which happen to be 16 byte hexidecimal keys. The company that provides the proprietary library no longer exists, and has been sold to two different companies, therefore we are looking for a replacement. The only requirement is that the key remain 16 bytes, as we have customers that rely on that key.
I've read that MD5 runs a 2^63 chance of collision.. is is possible to take the 128 bit key and simply shave off bits? does that merely increase my chance of collision to 2^47? (for 96 bit key) or 2^31 for a 64 bit key? Or is the distribution less even than that? The messages going in will be around 150 characters btw.
Any Help would be appreciated!

If you are bound by these requirements then the simplest solution is, as
you said, to lop off unecessary bits from the 16/20 byte hash returned
by MD2 or MD5. The probability of collision, all else being equal,
can be computed directly from the number of bits used. For this reason
I would suggest going for the 96 bit base 64 encoding.
Alternately you could XOR the removed bits with the reamining 96 bits
however this should not really increase the randomness if the original
function is doing its job properly. Whether it is worthwhile depends on
the quality of the original hash function.
matfud

SASL DIGEST-MD5

Did anybody have any problem with using DIGEST-MD5 with iPlanet running on a 2000 Advanced Server?
I have no problem when iPlanet is running on 2000 Professional but always get the error 49 with message: "Internal authentication error." when trying to authenticate the user through SASL DIGEST-MD5. Simple authentication with the same credentials work fine.
Looking at the LDAP packets I can see no differences, that makes me think that this is somehow related to the OS or iPlanet configuration.
In both cases it was the same version iPlanet Server 5.1SP2 with default settings.
BTW: It fails the same way with NT4SP6 Server.

Michael,
Sun ONE Directory Server 5.2 is not supported on Windows 2000 Professional. It is only supported on server versions of Windows 2000 (Server and Advanced Server).
You should not have any problems running Directory Server on Windows 2000 Professional, though, but you should always keep in mind that the product has not been tested and is not supported on this platform.
Bertold

SASL - Digest MD5 - JNDI Help needed

Hi All,
I am using Sunone Directory Server 5.2 and jsdk1.4.1. I tried the Digest-MD5 SASL authentication example given in JNDI tutorial and it worked fine. The problem is , when i try to run the same program thrice or more in succession, it hangs. Actually, the initial context gets created but the operations like simple getAttrs etc does not happen. what could be the problem or rather what is the solution to overcome it.
Attached below is the sample source code used...
try {
Hashtable env = new Hashtable(11);
env.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://localhost:389/");
env.put(Context.SECURITY_AUTHENTICATION, "DIGEST-MD5");
env.put(Context.SECURITY_PRINCIPAL, "dn:uid=xxx,ou=xxx,dc=xxx,dc=xxx");
env.put(Context.SECURITY_CREDENTIALS, "xxxxx");
System.out.println("about to get context");
DirContext ctx = new InitialDirContext(env);
System.out.println("got context");
Attributes attrs = ctx.getAttributes("ldap://localhost:389", new String[]{"supportedSASLMechanisms"});
System.out.println(attrs);
} catch (NamingException e) {
e.printStackTrace();
}thanks in advance
sridhar

As i have metioned , this was the message from the other forum
I have posted the mail correspondences we had (hope they won't consider this as an offence)...
There was a bug in the provider. It has been fixed in 1.4.2 and later
releases.
Rosanna Lee
Java Software, Sun Microsystems, Inc
[email protected]
Date: Mon, 13 Oct 2003 04:46:49 +0100 (BST)
From: anala sridhar <[email protected]>
Subject: JNDI problem
To: [email protected]
Hi,
First, I would like to thank everyone behind the
excellent JNDI tutorial. It acted as the bible for my
JNDI learning.
I tried the sample code ServerSasl.java provided. I
got it working after a few trials. I tried to get the
supportedSasl Mechanisms by the Sunone Directory
Server 5.2 . I got them. Then i tried to authenticate
using the default Digest-MD5 (am using jsdk 1.4.1).
When, i try to run the same program in succession, it
hangs up (4 or 5 times in a row). I am getting the
initial context with the credentials provided but it
hangs at doing the simple getAttrs operation. What
could be the problem?
Please reply to this query
thanks in advance
sridhar

Message Digest Error (plz help)

Hi,
I am from India and working on Gemplus Java cards (211 PK) . and using the Gemplus RAD III Kit 3.2
For Java card Application development (key pair generation and Message DIgest) , I am using the Javacard.security package and MessageDigest class for creating the message digest.
But I am facing some problems.
So, I am attaching the .java File. The source Code gets compiled properly but raises a Null Pointer Exception at RunTime (See attached text file) .
Could you please tell me what the error is?
Being in India, do these cards support Limited Cryptography or is Message Digesting allowed.
My .java file (i.e. My source code)
import java.io.*;
import java.io.FileInputStream;
import javacard.security.MessageDigest;
import javacard.security.CryptoException;
class MsgDigest
public static void main(String args[])
     FileInputStream fIn; // File Input stream
     FileOutputStream fOut; // File output stream
     boolean          resRead; //result of "Is file readable?"
     int           resCompare; //resultof comparing 2 file's equality
     String           fNm,temp; //open file name,temparary variable for other testing
     long           fLength; //open file length
     int     resReadFile;// result of reading the file through read()
     int               fileLength=0; //file Length in int
int          cnt=0;
try
//open the file on which message digest is to be performed
          fNm=new String("c:\\sample.txt");
          File fSamp=new File(fNm);
//checking it for reading operation
          resRead=fSamp.canRead();
          System.out.println(resRead);
//creating input stream of file and writting it into another file output.txt
fIn=new FileInputStream(fNm);
fLength=fNm.length();
     System.out.println("in long file size is : " fLength"\n");
     fOut= new FileOutputStream("C:\\output.txt");
//reading the file and calculating the length
do
               resReadFile=fIn.read();
               if (resReadFile!=-1)
               fOut.write(resReadFile);
               fileLength=fileLength+1;
     }while (resReadFile!=-1);
     fIn.close();
//reading the file and storing it in a byte array
fIn=new FileInputStream(fNm);
     System.out.println("in int File size is : "+fileLength+ "\n");
     byte readData[]=new byte[fileLength]; //data in file stored in this byte array
     int i;
     i=fIn.read(readData);
     System.out.println("bytes in readData : "+i+"\n");
//creating message digest object and update message Digest to work on our message : readData
byte midData[]=new byte[fileLength];
MessageDigest md;
try
     md = MessageDigest.getInstance(MessageDigest.ALG_SHA,false);
catch(Exception e1)
     e1.printStackTrace();
//md.update(readData,(short)0,(short)(readData.length));
//md.doFinal(readData,(short)0,(short)(readData.length),midData,(short)0);
}//try
catch (CryptoException e)
          System.err.println("ERROR : "+e);
          System.exit(1);
catch (FileNotFoundException e)
          System.err.println("ERROR : "+e);
          System.exit(1);
catch (ArrayIndexOutOfBoundsException e)
          System.err.println("ERROR : "+e);
          System.exit(1);
catch (Exception e)
          System.err.println("ERROR : "+e);
          System.exit(1);
}//main
}//class
Getting THIS error
true
in long file size is : 13
in int File size is : 241
bytes in readData : 241
javacard.security.CryptoException
at javacard.security.CryptoException.throwIt(Unknown Source)
at javacard.security.MessageDigest.getInstance(Unknown Source)
at MsgDigest.main(MsgDigest.java, Compiled Code)
Press any key to continue...

The Java card specification says that when calling MessageDigest.getInstance, the exception CryptoException will be thrown if the alg. is not supported or when the shared access mode is not supported. Can you pls check if Gemplus RAD III Kit 3.2 supports SHA-1 alg. ?
Also, the code that you have written is not compliant with Java Card spec. Because in Java card applets, we cannot use java.io.FileInputStream, etc., main method , etc. If I guess, you may be compiling the java file to class file by linking it to javacard package and executing class file using java interpreter like we do normally for executing a java application. This is not the way that Java applets are written, please go through the Java card spec for developing and compiling java applets.

URGENT: inconsistencies between Message Digests

Hi
I'm developing a system wherein the contents of a JMS message are fed into a MessageDigest, and signed by a Signature with the sending node's Private Key. The signed bytes from the Signature are then set as a message property.
The node that receives the message then creates a MessageDigest from the message body text, and using another Signature, performs verification of the new MessageDigest with the signed bytes obtained from the JMS message property that was set.
The problem is that, despite explicitly using the UTF-8 encryption when converting from byte[] to String in my code, the MessageDigest of the message body is always different (and differs upon each program run, even when the message body contents are the same for repeated runs). I've checked and the text being used to create the message digest on each node is exactly the same (including when checking the bytes), yet as I have said, the digests are always different. However, I am running one node on Windows XP, and another node on Solaris, but I can't see how this might affect things if I've explicitly used UTF-8 encoding, and have the same Provider (SUN version 1.2) in use on both platforms.
Are any aspects of Message Digests time-dependent/platform-dependent/randomly-generated?
Should I not even be using Message Digests/Signatures and instead use Ciphers?
Can anyone help me out here? I would be extremely grateful for any assistance!
Thanks,
Simon Parkin

Thanks for the help.
I removed the MessageDigest code ... and I'm still having problems (in a different area now).
I hate having to do this, but here is the code listing for the functions I've created (minus the Exception catching code):
public String signedDigest(String messageText)
     PrivateKey key = (PrivateKey)KEYSTORE.getKey(LOCAL_ALIAS, LOCAL_PASSWORD.toCharArray());
     Signature kSig = Signature.getInstance(SIGNATURE_ALGORITHM);
     kSig.initSign(key);
     kSig.update(messageText.trim().getBytes("UTF-8"));
     byte[] signedBytes = kSig.sign();
     return new String(signedBytes, "UTF-8").trim();
public boolean verifyContent(String messageText, String signedDigest, String receiverID)
     Certificate kCert = KEYSTORE.getCertificate(receiverID);
     PublicKey kPub = kCert.getPublicKey();
     Signature kVer = Signature.getInstance(SIGNATURE_ALGORITHM);
     kVer.initVerify(kPub);
     kVer.update(messageText.trim().getBytes("UTF-8"));
     boolean result = kVer.verify(signedDigest.trim().getBytes("UTF-8"));
     return result;
'signedDigest' creates the signed content in the sending node, and 'verifyContent' checks it at the receiver end. Now I've checked the content of the 'signedBytes' produced in 'signedDigest', and compared it to 'signedDigest.getBytes("UTF-8)' in 'verifyContent', and they are exactly the same, yet the verification never returns true. I'm using the right keys, and the 'messageText' used at both ends is the same, so I still can't understand why this isn't working.
Any further help would be very much appreciated.
Simon Parkin

Are there any known issues concerning using DIGEST-MD5 SASL authentication with iPlanet Directory Server 5.0 on Windows NT 4.0?

I am developing support for the DIGEST-MD5 sasl mechnism on a c-ldap client. I am using the evaluation version of the iPlanet Directory Server 5.0 which lists DIGEST-MD5 as a supported SASL mechanism. The server is running on NT 4.0 After installing the Directory Server with the test database, a changed the passwordStorageScheme from the default of SSHA to clear text. I then added my test user. When I run my test I always get back a resultCode of 49 (invalidCredentials). The digest-challenge I receive from the server and my digest-response are shown below. I have satisfied myself that the calculation of the response directive in the digest response is correct. Does anyone see any problems in the digest response or have any other suggestions? Is there a known problem with the iPlanet Directory Server 5.0?
digest-challenge:
realm="BGB2.ndp.provo.novell.com",nonce="Ed8UPLXsWaC6CN",qop="auth",algorithm=md5-sess,charset=utf-8
digest-response:
username="uid=bgbrown,ou=people,dc=siroe,dc=com",realm="BGB2.ndp.provo.novell.com",cnonce="A9IuPJKr30RiwL",nc=00000001,qop=auth,digest-uri="ldap/BGB2.ndp.provo.novell.com",response=97061205298e5ebaf206c8ac3598fdce,charset=utf-8,nonce="Ed8UPLXsWaC6CN"

Found the answer. When the username is an LDAP DN it needs to be proceeded by "dn:".
example: username="dn:uid=bgbrown,ou=people,dc=siroe,dc=com"
The server also accepts a simple uid value.
example: username="bgbrown"

How to decrypt to get the message digest?

Ok, I'm aware that, message digest, is a one-way hash algorithm. From what I gathered, we can decrypt then use the MessageDigest method, IsEqual to compared the hash value to ensure they are the same right?
But my problem is, right now, I has the code to encrypt and digitally signed on a xml.
But no one has used it before to decrypt. So i need to find out how.
Below is the code to generate the signed XML.
Can anyone tell me how to decrypt it?
Thanks...
    public boolean generateSignXmlDocument(String xmlDocPath, String newDocPath, KeyStore keystore, String alias, String password)
        boolean status = false;
        try
            DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
            dbf.setNamespaceAware(true);
            DocumentBuilder builder = dbf.newDocumentBuilder();
            File f = new File(xmlDocPath);
            Document doc = builder.parse(new FileInputStream(f));
            KeyPair kp = getPrivateKey(keystore, alias, password);
            DOMSignContext dsc = new DOMSignContext(kp.getPrivate(), doc.getDocumentElement());
            String providerName = System.getProperty("jsr105Provider", "org.jcp.xml.dsig.internal.dom.XMLDSigRI");
            log.info("Creating xml sign.....");
            log.debug("Provider Name " + providerName);
            XMLSignatureFactory fac = XMLSignatureFactory.getInstance("DOM", (Provider)Class.forName(providerName).newInstance());
            javax.xml.crypto.dsig.Reference ref = fac.newReference("", fac.newDigestMethod("http://www.w3.org/2000/09/xmldsig#sha1", null), Collections.singletonList(fac.newTransform("http://www.w3.org/2000/09/xmldsig#enveloped-signature", null)), null, null);
            javax.xml.crypto.dsig.SignedInfo si = fac.newSignedInfo(fac.newCanonicalizationMethod("http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments", null), fac.newSignatureMethod("http://www.w3.org/2000/09/xmldsig#rsa-sha1", null), Collections.singletonList(ref));
            KeyInfoFactory kif = fac.getKeyInfoFactory();
            javax.xml.crypto.dsig.keyinfo.KeyValue kv = kif.newKeyValue(kp.getPublic());
            javax.xml.crypto.dsig.keyinfo.KeyInfo ki = kif.newKeyInfo(Collections.singletonList(kv));
            XMLSignature signature = fac.newXMLSignature(si, ki);
            signature.sign(dsc);
            java.io.OutputStream os = new FileOutputStream(newDocPath);
            TransformerFactory tf = TransformerFactory.newInstance();
            Transformer trans = tf.newTransformer();
            trans.transform(new DOMSource(doc), new StreamResult(os));
            status = true;
        catch(Exception e)
            log.error(e);
        return status;
    }

Kyle Treece wrote:
It says that both IMAP and POP are enabled in my settings.
what settings ? in gmail webmail interface? I'm talking about how your gmail account is configured in Mail on your computer. It's configured for POP. you need to delete it from Mail and then create a new account in Mail and make it IMAP. do not use automated account setup which Mail will offer to do. that will make the account POP again. enter all server info and account type by hand.
see this link for details
http://mail.google.com/support/bin/answer.py?answer=81379
If I turn POP completely off, will it kick all the messages out of my iPhone?
as I said, this is not about turning something on or off in webmail gmail. you have to configure your email client Mail correctly. it will have no effect on your iphone.

Using tls:sasl/DIGEST-MD5 with client authentication

Hi
Have installed a certificate on the server and enabled it. Using Netscape i got the cert7.db and key3.db
These work with ldapsearch with -Z -p options to get data securely through port 636.
But when i copy db file to /var/ldap on the Solaris 8 client, and use a profile with tls:sasl/DIGEST-MD5 or tls:simple
i get :
Mesg: Session error , no avalible connection. And openConnection: sasl/DIGEST-MD5 (or simple) bind failed - Invalid credentials.
Must i use Certificate based Authentication instead?
Like the proxyagent must have a certificate installed. Or is there something that must be done to the cert7.db and key3.db files i got from Netscape?

Im trying to get sasl/DIGEST-MD5 to work with Solaris 9 client. This command work:
ldapsearch -D "" -w test1234 -o mech=DIGEST-MD5 -o authid="dn:cn=proxyagent,ou=profile,dc=net2,dc=kongsberg,dc=com" -o authzid="dn:cn=proxyagent,ou=profile,dc=net2,dc=kongsberg,dc=com" -b "dc=net2,dc=kongsberg,dc=com" "(objectclass=*)"
Client configured with this:
ldapclient -v init -a profileName=default -a domainName=net2.kongsberg.com -a proxyDN="cn=proxyagent,ou=profile,dc=net2,dc=kongsberg,dc=com" -a proxyPassword=test1234 172.18.2.19
Profile:
NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_BINDDN= cn=proxyagent,ou=profile,dc=net2,dc=kongsberg,dc=com
NS_LDAP_BINDPASSWD= {NS1}4a3788e8c053424f
NS_LDAP_SERVERS= 172.18.2.19
NS_LDAP_SEARCH_BASEDN= dc=net2,dc=kongsberg,dc=com
NS_LDAP_AUTH= sasl/DIGEST-MD5
NS_LDAP_SEARCH_REF= FALSE
NS_LDAP_SEARCH_SCOPE= one
NS_LDAP_SEARCH_TIME= 30
NS_LDAP_PROFILE= default
NS_LDAP_CREDENTIAL_LEVEL= proxy
NS_LDAP_BIND_TIME= 10
messages log on client:
Jan 14 08:00:32 panzer ldap_cachemgr[904]: [ID 293258 daemon.error] libsldap: Status: 49 Mesg: openConnection: sasl/DIGEST-MD5 bind failed - Invalid credentials
Jan 14 08:00:32 panzer last message repeated 1 time
Jan 14 08:00:32 panzer ldap_cachemgr[904]: [ID 293258 daemon.error] libsldap: Status: 7 Mesg: Session error no available conn.
error log on server:
[14/Jan/2004:08:06:47 +0100] conn=1622 op=2 msgId=-1 - closing - U1
[14/Jan/2004:08:06:47 +0100] conn=1623 op=-1 msgId=-1 - fd=47 slot=47 LDAP connection from 172.18.2.41 to 172.18.2.19
[14/Jan/2004:08:06:47 +0100] conn=1622 op=-1 msgId=-1 - closed.
[14/Jan/2004:08:06:47 +0100] conn=1623 op=0 msgId=1 - BIND dn="dn: cn=proxyagent,ou=profile,dc=net2,dc=kongsberg,dc=com" method=sasl version=3 mech=DIGEST-MD5
[14/Jan/2004:08:06:47 +0100] conn=1623 op=0 msgId=1 - RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress
[14/Jan/2004:08:06:47 +0100] conn=1623 op=1 msgId=2 - BIND dn="dn: cn=proxyagent,ou=profile,dc=net2,dc=kongsberg,dc=com" method=sasl version=3 mech=DIGEST-MD5
[14/Jan/2004:08:06:47 +0100] conn=1623 op=1 msgId=2 - RESULT err=49 tag=97 nentries=0 etime=0
Not sure why i get Invalid credentials, the passwords
are stored in CLEAR. And you can see i use the same in ldapsearch and ldapclient.

SHA-1 Message Digest

Hi All,
I have been given a task to create a SHA-1 (160 bit) Message Digest for a compiled executable. I have the SHA-1 string which contains 40 chars. Can someone shed some light?
Much Appreciated.
KayMan

sabre150 said:
Right, but do you know what you can do with asingle
colliiding block?The only paper I have read on this is
http://eprint.iacr.org/2004/356.pdf and it does not
fill me with dread. Maybe it should! Taken to it's
logical conclusion, any hash is flawed as soon as one
colliding block is known and dangerous once the
algorithm for creating the colliding block is
published..Yes exactly.
For some time now we have known that MD5 is flawed
and we now know that SHA1 is flawed. I expect that in
the next few years sha 256 will be found flawed. Possibly.
As I
understand it, at this time the theory of hashing is
in it's infancy and falls well behind the theory of
encryption and until the theory of hashing is more
advanced I don't expect to get really secure hashes.Yep.
Since I have now retired and only work on a very very
part time basis I don't think it will fall to me to
implement any of the upgrades.Of course; my point was to just to make a note that SHA-1 is seriously broken and should not be used if possible.

Encrypting a message digest

Hi I'm trying to encrypt a message digest using RSA Encryption. For some reason when the encrypted message digest is decrypted it does not match the original. If this is hard to follow the following code illustrates this point:
String input = "Testing message";
MessageDigest hash = MessageDigest.getInstance("SHA1");
hash.update( input.getBytes() );
generator.initialize(512, random);
KeyPair pair = generator.generateKeyPair();
Key pubKey = pair.getPublic();
Key privKey = pair.getPrivate();
cipher.init(Cipher.ENCRYPT_MODE, privKey); // encrypt
byte[] cipherText = cipher.doFinal( hash.digest() );
// now decrypt
cipher.init(Cipher.DECRYPT_MODE, pubKey);
byte[] plainText = cipher.doFinal(cipherText);Here the byte array plainText does not match the original message digest from hash.digest() Any help on how to correct this problem would be great.
thanks
-B
Edited by: BenWhethers on Dec 13, 2007 12:49 PM
Edited by: BenWhethers on Dec 13, 2007 12:50 PM

You don't provide testable code so I have made a guess as to the missing code and for me the decrypted digest is the same are the original.
        Cipher cipher = Cipher.getInstance("RSA");
        SecureRandom random = new SecureRandom();
        KeyPairGenerator generator = KeyPairGenerator.getInstance("RSA");
        String input = "Testing message";
        MessageDigest hash = MessageDigest.getInstance("SHA1");
        hash.update( input.getBytes() );
        generator.initialize(512, random);
        KeyPair pair = generator.generateKeyPair();
        Key pubKey = pair.getPublic();
        Key privKey = pair.getPrivate();
        cipher.init(Cipher.ENCRYPT_MODE, privKey); // encrypt
        byte[] digest = hash.digest();
        byte[] cipherText = cipher.doFinal( digest );
        // now decrypt
        cipher.init(Cipher.DECRYPT_MODE, pubKey);
        byte[] plainText = cipher.doFinal(cipherText);
        System.out.println(Arrays.equals(plainText,digest ));

Message Digest. HASH algorithms

Please, Why I calculated hash (message digest) of word "Fausto", used java.security.MessageDigest is 5e064a44ab768f9e0d5a7e0639cc16e7 but used OpenSSL with this same word "Fausto", result is 0de02ffc6280f4d111680373fa60c0b9????
Someone to say because happen this????
Thanks..
:-)

Please, Why I calculated hash (message digest) of
word "Fausto", used java.security.MessageDigest is
5e064a44ab768f9e0d5a7e0639cc16e7 but used OpenSSL
with this same word "Fausto", result is
0de02ffc6280f4d111680373fa60c0b9????
Someone to say because happen this????
Thanks..
:-)The OpenSSL result is the value you get by taking the MD5 of "Fausto\n". I suspect you are not using the -n option with echo. i.e. you should use
echo -n Fausto | openssl md5

SASL's DIGEST-MD5 is causing the smtp authentication failure

Hello,
I've asked this question in JavaMail forums [at this link|http://kenai.com/projects/javamail/forums/forum/topics/2944-DIGEST-MD5-sasl-authentication-failing-after-verifying-rspauth] and was forwarded here.
Basically, I'm trying to authenticate to the email server using JavaMail(latest source) via sasl's Digest-MD5.
Problem: Looks like sasl's DigestMD5 implementation (com.sun.security.sasl.digest.DigestMD5Client) is returning a null after a successful authentication in evaluateChallenge(). The SMTPTransport thinks this is wrong and sends a "*" to server and the server responds with "Authentication aborted".
The java doc for SaslClient's evaluateChallenge() says this..
Returns: The possibly null reponse to send to the server. It is null if the challenge accompanied a "SUCCESS" status and the challenge only contains data for the client to update its state and no response needs to be sent to the server. The response is a zero-length byte array if the client is to send a response with no data.
In this case, client do need to send a response with no data. I don't know if Digest-md5 implementation is generic and if it's behavior is correct.
I appreciate any suggestions to solve this problem.
Thanks

Not an expert. Maybe you can read or debug into the exact place when the names are compared. Anyway, Java is open sourced now.

Reuse the LDAP connection when Using SASL DIGEST-MD5

I have problem to use the same ldap connection for multiple SASL authenticaiton.
step1, LDAPConection conn=new LDAPCo...
conn.conect()..
step2, do a SASL DIGEST-MD5, successfully get a challenge from server and server confirmation after the response is correct.
step3, I want to use the same connection for another authetincation of different user, some how the server did not give back the challenge and reject the authenticaiton request again.
So my question is how can we reuse the same connection for SASL authentication?
Any switch or reset on the LDAP connection or the LDAP server has to be configured in some way to take multiple authentication using the same connection?

More than fifty people have read this post, but there are no replies as
of yet. I'm going to interpret that as "SASL DIGEST-MD5 is not
supported by the Novell CSharp library."
danielnapierski;1995522 Wrote:
> I haven't been able to bind to an LDAP server using SASL DIGEST-MD5
> using the Novell CSharp library. Can anyone explain how this is done,
> or point me to a code example?
>
> I can connect, bind, and search this LDAP server using Apache Directory
> Studio, so I know that my credentials are correct.
>
> Also, I have already used the Novell CSharp library for searching other
> LDAP servers using simple authentication, and SSL, but never SASL
> DIGEST-MD5.
>
> Thanks in advance for any help.
danielnapierski
danielnapierski's Profile: http://forums.novell.com/member.php?userid=63370
View this thread: http://forums.novell.com/showthread.php?t=414964

Message Digest MD5 Problem

Similar Messages

Maybe you are looking for