All Packages Class Hierarchy This Package Previous Next Index
java.lang.Object | +----java.security.Signature | +----cryptix.provider.rpk.Any_RPK_PKCS1Signature
This implementation uses the IJCE API in a specific way to adapt the implied digital signature scheme to the requirements of the RPK system.
In public cryptography, a digital signature is computed from the message to be signed, and the signer's private key. Anybody wishing to verify the obtained digital signature, would use the alleged signer's public key and the signed message to check the authenticity of the fact that the digital signature was indeed produced by the signer.
In the RPK system, a digital signature cannot be produced without
prior knowledge of the intended recipient or recipients. As a
consequence, the usual passing of the signer's private key as the
argument to the initSign()
method is replaced by passing
the recipient's public key instead. Also, the passing of the owner's
public key to the initVerify()
method is replaced by
the passing of the owner's private key instead.
More specifically, here are the steps involved in RPK digital signature/ verfication:
References:
Copyright © 1997
Systemics Ltd on behalf of the
Cryptix Development Team.
All rights reserved.
$Revision: 1.4 $
engineSign()
method.
protected Any_RPK_PKCS1Signature(String mdAlgorithm)
protected void engineInitSign(PrivateKey key) throws InvalidKeyException
protected void engineInitVerify(PublicKey key) throws InvalidKeyException
protected void engineUpdate(byte b) throws SignatureException
protected void engineUpdate(byte in[], int offset, int length) throws SignatureException
protected byte[] engineSign() throws SignatureException
NOTES: Sun's documentation talks about the bytes returned being X.509-encoded. In this implementation however, this is not the case. Instead, the bytes returned are formed by two parts: The first one is a byte representation of the quantity Q needed by the recipient to synchronise his keystream automaton, while the second part of the digital signature is an encrypted version of a PKCS#1 frame. The object of this PKCS#1 frame conforms to RFC-1423 section 4.2.1.
[DJH: is this correct? I thought RFC-1423 specified the same formatting as PKCS#1 section 10, which requires block type 01, not 00?]
Practically, its value will be formed by concatenating a leading NULL byte, a block type BT, a padding block PS, another NULL byte, and finally a data block D; ie:
0x00 || BT || PS || 0x00 || D.For signing, PKCS#1 block type 00 encryption-block formatting scheme is employed. The block type BT is a single byte valued 0x00 and the padding block PS is enough 0x00 bytes to make the length of the complete frame equal to the length of the sender's private key (which, in the RPK scheme, is also of equal length to the recipient's public key). The data block D consists of the message digest value and the message digest algorithm ASN.1 encoded identifier. The formal syntax in ASN.1 notation is:
SEQUENCE { digestAlgorithm AlgorithmIdentifier, digest OCTET STRING } AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL }
protected boolean engineVerify(byte signature[]) throws SignatureException
protected void engineSetParameter(String param, Object value) throws InvalidParameterException
protected Object engineGetParameter(String param) throws InvalidParameterException
protected abstract byte[] getAlgorithmId()
engineSign()
method.
All Packages Class Hierarchy This Package Previous Next Index