From 692d9f352c2adc7dc27feedeecb0aec78410acba Mon Sep 17 00:00:00 2001 From: miod <> Date: Tue, 29 Mar 2005 17:29:10 +0000 Subject: belive -> believe --- src/lib/libcrypto/des/times/usparc.cc | 2 +- src/lib/libcrypto/ripemd/README | 2 +- src/lib/libssl/src/crypto/des/times/usparc.cc | 2 +- src/lib/libssl/src/crypto/ripemd/README | 2 +- src/lib/libssl/src/doc/ssleay.txt | 4 ++-- 5 files changed, 6 insertions(+), 6 deletions(-) (limited to 'src/lib') diff --git a/src/lib/libcrypto/des/times/usparc.cc b/src/lib/libcrypto/des/times/usparc.cc index f6ec8e8831..0864285ef6 100644 --- a/src/lib/libcrypto/des/times/usparc.cc +++ b/src/lib/libcrypto/des/times/usparc.cc @@ -2,7 +2,7 @@ solaris 2.5.1 usparc 167mhz?? - SC4.0 cc -fast -Xa -xO5 For the ultra sparc, SunC 4.0 cc -fast -Xa -xO5, running 'des_opts' gives a speed of 475,000 des/s while 'speed' gives 417,000 des/s. -I belive the difference is tied up in optimisation that the compiler +I believe the difference is tied up in optimisation that the compiler is able to perform when the code is 'inlined'. For 'speed', the DES routines are being linked from a library. I'll record the higher speed since if performance is everything, you can always inline diff --git a/src/lib/libcrypto/ripemd/README b/src/lib/libcrypto/ripemd/README index 7097707264..f1ffc8b134 100644 --- a/src/lib/libcrypto/ripemd/README +++ b/src/lib/libcrypto/ripemd/README @@ -4,7 +4,7 @@ http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html This is my implementation of RIPEMD-160. The pentium assember is a little off the pace since I only get 1050 cycles, while the best is 1013. I have a few ideas for how to get another 20 or so cycles, but at -this point I will not bother right now. I belive the trick will be +this point I will not bother right now. I believe the trick will be to remove my 'copy X array onto stack' until inside the RIP1() finctions the first time round. To do this I need another register and will only have one temporary one. A bit tricky.... I can also cleanup the saving of the 5 words diff --git a/src/lib/libssl/src/crypto/des/times/usparc.cc b/src/lib/libssl/src/crypto/des/times/usparc.cc index f6ec8e8831..0864285ef6 100644 --- a/src/lib/libssl/src/crypto/des/times/usparc.cc +++ b/src/lib/libssl/src/crypto/des/times/usparc.cc @@ -2,7 +2,7 @@ solaris 2.5.1 usparc 167mhz?? - SC4.0 cc -fast -Xa -xO5 For the ultra sparc, SunC 4.0 cc -fast -Xa -xO5, running 'des_opts' gives a speed of 475,000 des/s while 'speed' gives 417,000 des/s. -I belive the difference is tied up in optimisation that the compiler +I believe the difference is tied up in optimisation that the compiler is able to perform when the code is 'inlined'. For 'speed', the DES routines are being linked from a library. I'll record the higher speed since if performance is everything, you can always inline diff --git a/src/lib/libssl/src/crypto/ripemd/README b/src/lib/libssl/src/crypto/ripemd/README index 7097707264..f1ffc8b134 100644 --- a/src/lib/libssl/src/crypto/ripemd/README +++ b/src/lib/libssl/src/crypto/ripemd/README @@ -4,7 +4,7 @@ http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html This is my implementation of RIPEMD-160. The pentium assember is a little off the pace since I only get 1050 cycles, while the best is 1013. I have a few ideas for how to get another 20 or so cycles, but at -this point I will not bother right now. I belive the trick will be +this point I will not bother right now. I believe the trick will be to remove my 'copy X array onto stack' until inside the RIP1() finctions the first time round. To do this I need another register and will only have one temporary one. A bit tricky.... I can also cleanup the saving of the 5 words diff --git a/src/lib/libssl/src/doc/ssleay.txt b/src/lib/libssl/src/doc/ssleay.txt index d44d2f04a0..666de94e50 100644 --- a/src/lib/libssl/src/doc/ssleay.txt +++ b/src/lib/libssl/src/doc/ssleay.txt @@ -3800,9 +3800,9 @@ made public on sci.crypt in Sep 1994 (RC4) and Feb 1996 (RC2). I have copies of the origional postings if people are interested. RSA I believe claim that they were 'trade-secrets' and that some-one broke an NDA in revealing them. Other claim they reverse engineered the algorithms from -compiled binaries. If the algorithms were reverse engineered, I belive +compiled binaries. If the algorithms were reverse engineered, I believe RSA had no legal leg to stand on. If an NDA was broken, I don't know. -Regardless, RSA, I belive, is willing to go to court over the issue so +Regardless, RSA, I believe, is willing to go to court over the issue so licencing is probably the best idea, or at least talk to them. If there are people who actually know more about this, pease let me know, I don't want to vilify or spread miss-information if I can help it. -- cgit v1.2.3-55-g6feb