- 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