- From: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
- Date: Fri, 19 Oct 2001 10:54:17 +0200
- To: Dave Roberts <dave.roberts@saaconsultants.com>, dsig <w3c-ietf-xmldsig@w3.org>
>> Certificates. But you _can_ use KeyName with a custom KeyIdentifier or a >> retrival method that works in the signature verification environment. > > Understood. A mutual agreement of the secret key, and an identifier that > both parties use. Or retrieval via SSL perhaps to keep the key secret. > Much obliged. Sorry, my idea with the RetrievalMethos was wrong. Of cource I can use RetrievalMethod to reference a key somewhere in the filesystem that's only available in the verification environment, but there's no way to 'tag' this resource to be a symmetric key. Sorry about that. You can only use KeyName. > OK, I understand the truncation, but which bits do you lose, the Most > Significant or Least Significant? I suspected the MSB is lost, and the > LSB is kept, but... I took a look at the examples in the > merlin-xmldsig-fifteen tarball. There is one example outputting the full > MAC, and one that outputs 40 bits. As far as I can see, the data being > signed is exactly the same, and they use the same secret key, however > converting the base64 MAC back into binary, there appears to be no > instance of the 40 bits as a subset of the 160 bits (IFSWIM)... so I'm > obviously missing something (probably very simple :) Maybe this (JAVA-Code) helps: this is what I did: private static byte[] reduceBitLength(byte completeResult[], int length) { int bytes = length / 8; int abits = length % 8; byte[] strippedResult = new byte[bytes + (abits == 0 ? 0 : 1)]; System.arraycopy(completeResult, 0, strippedResult, 0, bytes); if (abits > 0) { byte[] MASK = { (byte) 0x00, (byte) 0x80, (byte) 0xC0, (byte) 0xE0, (byte) 0xF0, (byte) 0xF8, (byte) 0xFC, (byte) 0xFE }; strippedResult[bytes] = (byte) (completeResult[bytes] & MASK[abits]); } return strippedResult; }
Received on Friday, 19 October 2001 04:52:19 UTC