gnu-crypto-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNU Crypto] MD2 hash


From: Raif S. Naffah
Subject: Re: [GNU Crypto] MD2 hash
Date: Fri, 25 Oct 2002 20:39:30 +1000
User-agent: KMail/1.4.3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

On Friday 25 October 2002 19:45, Casey Marshall wrote:
> Raif S. Naffah wrote:
> | On Tuesday 22 October 2002 18:08, Casey Marshall wrote:
> |>Raif S. Naffah wrote:
> |>|>... The GCJ compilation tripped me at first
> |>|>since I didn't run `automake; autoconf`, but since the CVS
> |>|> sources still include the Makefile.in's they should be patched
> |>|> as well (or removed;
> |>|
> |>| if you're referring to the top level directory, the Makefile.in
> |>| should not be there anymore (in my local CVS it is not).
> |>
> |>I meant the gcj/ ones, but isn't that build method destined to be
> |>included in the top level build?
> |
> | in the future may be.  i was not personally able to combine both;
> | but if somebody else is willing and have the time, then pls go
> | ahead.  i think ultimately we should have one way to build with the
> | GNU tools
>
> I'm personally more comfortable with the two builds being separate,
> since their ultimate goals are so different. It just doesn't seem
> like a good idea to make things so much more complicated when (I'm
> guessing) most of the people building the library would want
> bytecodes.


so be it.  let's continue having the current trilogy: ant + make 
(toplevel) + make (gcj/).  Olivier seems to have the same thought too, 
but i'll clarify that in the other thread.

is it worth coming up with a checklist for maintainers/developers, of 
what to do when adding a new algorithm/class to the package?


> |>| [...]
> |>|
> |>|>... -- which reminds me, how will we decide what algorithms to
> |>|>include next?
> |>|
> |>| my personal list is:
> |>|
> |>| 1. current algorithms (hash, cipher, modes, etc.):
> |>|
> |>|    DES, DES-EDE, CAST, Blowfish, RC6,
> |>|    HAVAL, TIGER, SHA-256 et al
> |>|    CBC, CFB
> |>
> |>Doesn't RSA Security hold a patent for RC6? Other than that I would
> |>agree with this list.
> |
> | yes they do.  my understanding is that RC6 in this regard is
> | similar to IDEA.  if you use it commercially in the USA you have to
> | get a license.
> |
> | in addition, as per RSA's FAQ, the name itself MAY become a
> | trademark, like ARC4...
> |
> | how about replacing it with the latter?  this way, if we get all
> | those ciphers implemented, GNU Crypto can be used out-of-the-box in
> | most current libraries and applications incl. SSL/TLS.
>
> ARC4 sounds like a better way to go. I don't see any real need for
> RC2/RC5/RC6 other than for completeness, since none of them are in
> *that* widespread use (that I know of).

ok.  unless somebody disagrees, i'll update the home page this weekend 
to include the proposed list with the above algos.


cheers;
rsn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Que du magnifique

iD8DBQE9uR9j+e1AKnsTRiERA1KPAKC5xTfPcF+BvdYqZjooEskKeecXmwCg0bSa
MYP8Gsyn11Hbu2e/gWkzOIQ=
=IYHO
-----END PGP SIGNATURE-----





reply via email to

[Prev in Thread] Current Thread [Next in Thread]