hello John,
On Saturday 17 June 2006 00:35, John Pritchard wrote:
> Raif,
>
> thanks for your comments. the doc references have been linked,
thanks.
> the
> Init links have been changed to Doc ones,
yes but that does not help! linking @see references to anchors in the
class's javadoc does not make my Eclipse any happier. putting the bulk
of the parameters' documentation with their declaration, and if still
needed, linking to them --e.g. {@link #xxx} should fix this.
> the property strings
> shortened for faster hashing time,
yes but i see you're still using a non-dotted name. any strong reason
to diverge from the existing convention?
> a couple new constructors added,
> and a main for quick testing.
for testing we rely on Mauve, the companion project to GNU Classpath:
<http://sources.redhat.com/mauve/>. the only testing requirement for
the crypto classes is a self-test that validates the implementation.
for block ciphers for example one KAT (Known Answer Text) is used. no
main() methods should be present in the algorithms.
other notes:
* i like the idea of using the null-cipher as the "default" cipher. it
highlights the fact that this mode can be used, on its own, as an
All-Or-Nothing transform!
* shouldn't the following comment (in encryptBlock()) read:
// T = (R xor H(M xor G(r)))
rather than
// T = (R xor H( X xor G(r)))
* in computing T (in encryptBlock()) (and similarly for S in the same
method, M, and r in decryptBlock()) wouldn't be cheaper to just do:
T = R[idx] ^ Hx[idx];
aont[aont_idx] = (byte) T;
* finally, in your final patch submission, please fix the imports and
use the EFJ i mentioned in my earlier post.
> one question..
>
> has it been your intention that all assemblies would include a
> padding mode?
no; the long explanation follows.
> a quick test as included here will likely show the
> encode/decode cycle adding zero bits to the tail of the processed
> plaintext. of course this is due to the i-block-cipher enc/dec
> methods presuming input (and output) is 'block size' (no length or
> block length delta). it's not clear to me how an application
> generally avoids this modification of the plain text (without a
> padding mode).
all assemblies involving a block-cipher, once setup, will operate with a
block-size. this block-size may not be the same as the cipher's one,
nevertheless it is block-based. in this context if the input text size
is not a multiple of the assembly's block size you have a problem. you
can still construct assemblies without padding algorithms if for
example you use a mode with 1-byte block-size. this is how
block-ciphers can be turned into stream ciphers! on the other hand, if
the mode has a block-size > 1, the assembly must be fitted with a
padding algorithm, so when the last push (of data) occurs into the
assembly, it can/will produce the final block.
have a look at the gnu.javax.crypto.assembly classes and their Mauve
tests to see how you can build and operate different kinds of
constructs including a Blowfish-OFB-PKCS7-Zip cascade.
cheers;
rsn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://developer.classpath.org/pipermail/classpath/attachments/20060617/5012fffd/attachment-0001.pgp
