Menu
▾
▴
cryptoapi-devel — internal mailing list for developers only
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
(16) |
Mar
(71) |
Apr
(28) |
May
(7) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Herbert V. R. <hv...@hv...> - 2002-05-31 21:54:28
|
fyi, I've moved the mailing lists to kerneli.org; the new mailing list page can be found at http://www.kerneli.org/mailman/listinfo/cryptoapi-devel you will be unsubscribed from the sourceforge.net list right after this mail has been sent, while having been subscribed at the new kerneli.org list (you should have received some notification already) sorry for amy inconveniences -- Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 Email: hv...@hv... / Finger hv...@gn... for GnuPG Public Key GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142 |
|
From: Justin C. <ju...@po...> - 2002-05-30 22:45:12
|
Hi HVR, Count me in for updating www.kerneli.org. :-) Regards and best wishes, Justin Clift Herbert Valerio Riedel wrote: > > the util-linux cvs module was updated to 2.11r > (btw, a neat combination of cvs import / cvs tag / cvs up / cvs up -j > -j) > > http://www.kernel.org/pub/linux/kernel/people/hvr/util-linux-patch-int/util-linux-2.11r.patch.bz2 > > new redhat73 RPMS were built and uploaded to: > http://www.ifs.tuwien.ac.at/~hvr/crypto/ > > new loop-jari-2.4.18 patch; added to cvs; > > http://www.kernel.org/pub/linux/kernel/people/hvr/testing/loop-jari-2.4.18.0.patch > > uploaded new patch-int to > > http://www.kernel.org/pub/linux/kernel/people/hvr/testing/patch-int-2.4.18.3.bz2 > > uploaded cryptoapi tarball to > > http://www.kernel.org/pub/linux/kernel/people/hvr/testing/cryptoapi-0.1.0-pre4.tar.bz2 > > content of http://cryptoapi.sf.net/ copied to > http://www.kerneli.org/cryptoapi/ > please try to remove references to sourceforge... we're gonna switch to > kerneli.org within the next months; > > also, the content of www.kerneli.org needs to be updated... any > volunteer? > > regards, > -- > Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 > Email: hv...@hv... / Finger hv...@gn... for GnuPG Public Key > GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F > 4142 > > ------------------------------------------------------------------------ > Name: signature.asc > signature.asc Type: PGP Armored File (application/x-unknown-content-type-PGP Armored File) > Description: This is a digitally signed message part -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi |
|
From: Jean-Luc C. <jl...@ce...> - 2002-05-30 16:37:35
|
Finally made it on the internal list.
My goals:
Harmonize the hasher API
Add SHA256/384/512 support
Add CTR(insecure) and RTC(my tweak of CTR) to the list of available
modes of operation.
- This implies I fix the current blkdev_size vs. IV location bugs.
By background is crypto, so FileSystems and kernel hacking is new to
me, I hope to get help from you in the #crypto room and this list with
testing my changes.
Questions #1: I understand loading a built cryptoapi.o module is all
that's needed to start testing the cryptoloop functionality. Can I
please get a rundown of this process?
Cheers
JLC
--
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6
C: 613.263.2983
|
|
From: Herbert V. R. <hv...@hv...> - 2002-05-30 15:19:10
|
the util-linux cvs module was updated to 2.11r=20 (btw, a neat combination of cvs import / cvs tag / cvs up / cvs up -j -j) http://www.kernel.org/pub/linux/kernel/people/hvr/util-linux-patch-int/util= -linux-2.11r.patch.bz2 new redhat73 RPMS were built and uploaded to: http://www.ifs.tuwien.ac.at/~hvr/crypto/ new loop-jari-2.4.18 patch; added to cvs; http://www.kernel.org/pub/linux/kernel/people/hvr/testing/loop-jari-2.4.18.= 0.patch uploaded new patch-int to http://www.kernel.org/pub/linux/kernel/people/hvr/testing/patch-int-2.4.18.= 3.bz2 uploaded cryptoapi tarball to http://www.kernel.org/pub/linux/kernel/people/hvr/testing/cryptoapi-0.1.0-p= re4.tar.bz2 content of http://cryptoapi.sf.net/ copied to http://www.kerneli.org/cryptoapi/ please try to remove references to sourceforge... we're gonna switch to kerneli.org within the next months; also, the content of www.kerneli.org needs to be updated... any volunteer? regards, --=20 Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 Email: hv...@hv... / Finger hv...@gn... for GnuPG Public Key GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142 |
|
From: David B. <db...@du...> - 2002-05-15 05:54:57
|
Ok so.. i did some more testing, and came up with a couple strange things. Jari's loop patch also crashes, which further points to the bug having to do with xfs specifically. One strange thing i did notice, was that 2 out of the 3 times i crashed it, it crashed while running the bdflush thread, and one time during the kupdated thread. But the iv patch always(6 out of 6 times) hangs in kupdated thread. The other *very* strange thing is that if you recompile the loop driver and modprobe it(without rebooting after make modules, and make modules_install) it works fine! This is *really* strange, i don't think i quite know enough about the kernel to figure out why this would happen, but something fishy is going on. Maybe someone can give me some advice here, my only thoughts this far are to read the kernel code for kupdated and bdflush, try to understand whats going on. Then setup a more advanced debugger like kdb, or kgdb. Dave |
|
From: David B. <db...@du...> - 2002-05-12 01:56:12
|
Ok, so i did some stress testing on different file-systems this weekend trying to track down this "bug". As far as I can tell, it only happens when using XFS, because ext3 and reiser work fine(the patches for jfs and xfs don't place nice, so i'll have to build an extra kernel for that). What i did was, make a 200 meg /dev/urandom file, then mount it via loopback with twofish, then made the necessary file systems on it. And I untarr'd kernel sources in there, so there would be a lot of meta-data generation. Anyway, so it consistantly crashes with xfs, at different points in the untar'ing. My friend showed me how to play with Sysrq key, so after it crashed i looked at things through there... and it seems to stop working in the kupdated kernel thread. So i read a bit about it in my handy dandy understanding the linux kernel book, and it "flushes old dirty buffers from memory", which i believe has something to do with filesystem block data in memory. So, that's what i have found so far, any suggestions on where to go from here? i'm reading up on doing more in depth kernel debugging, but very new to it ;-) dave |
|
From: David B. <db...@du...> - 2002-05-10 17:20:31
|
hey all, no traffic for a while, so I thought i'd throw up an update on what's going on, at least afaik. Looks like we are almost ready for a release save a couple of show stoppers. - Apparently a data syncrhonization issue has cropped up with cryptoloop and SMP machines, this is caused even when running SMP on a UP machine.=20 If anybody has experiences with this, or anything we can use to debug it please post it. Every little bit helps ;-) - RC5 is still broken, not sure that it will be fixed before the next release, it is currently disabled in the source code. - hvr added a cryptoapi version macro in crypto.h #define CRYPTO_API_VERSION_CODE 0x000100 is the current status. - I've been workign on rewriting DES, and there is about 10 more lines of code that i need for the key schedule and I am done. It is currently 1/2 the size of the current implementation and MUCH more readable. I am also working on an assembly implementation on the side in ppc, hopefully that will be done as well. On another note, i'm having trouble grasping specific bit manipulations in C :-( If anybody can help me out, or point me towards some helpful links i would *really* appriciate it as I am kind of kludging along here ;-) Finally, some interesting benchmarks i did quicly on my G4 867: des-ecb: encryption: 3125 kb, 219111 usecs, 14262.177618 kb/sec decryption: 3125 kb, 225151 usecs, 13879.574152 kb/sec twofish-ecb: encryption: 6250 kb, 185478 usecs, 33696.718748 kb/sec decryption: 6250 kb, 175742 usecs, 35563.496489 kb/sec serpent-ecb: encryption: 6250 kb, 305774 usecs, 20439.932761 kb/sec decryption: 6250 kb, 295950 usecs, 21118.432168 kb/sec aes-ecb: encryption: 6250 kb, 266338 usecs, 23466.422366 kb/sec decryption: 6250 kb, 283241 usecs, 22066.014454 kb/sec mars-ecb: encryption: 6250 kb, 190797 usecs, 32757.328470 kb/sec decryption: 6250 kb, 187064 usecs, 33411.025104 kb/sec dfc-ecb: encryption: 6250 kb, 744733 usecs, 8392.269444 kb/sec decryption: 6250 kb, 746533 usecs, 8372.034458 kb/sec rc6-ecb: encryption: 6250 kb, 141812 usecs, 44072.433927 kb/sec decryption: 6250 kb, 157185 usecs, 39762.063810 kb/sec Enjoy! |
|
From: Kyle M. <ky...@de...> - 2002-04-28 16:46:05
|
just added a quick hack to handle placing modules in the right directory after a $make modules... i think i'll proofread the documentation today. regards, kyle -- copyleft (c) 2002, Kyle McMartin |
|
From: Herbert V. R. <hv...@hv...> - 2002-04-24 13:40:43
|
hello! On Wed, 2002-04-24 at 00:17, Tobias Ringstrom wrote: > A little bit off-topic perhaps, but I'd like to congratulate you all on a= n > extremely useable piece of software! When I decicided to make a > light-weight IPsec tunnel implementation some time ago I decided very > early on to use your CryptoAPI, and found it really easy to use. >=20 > I now have a version of my IPsec tunnel implementation that seems to work > just fine, and I think it's time to let you guys have a peek at it. You > can find the code and a first stab at actual documentation at >=20 > http://ringstrom.mine.nu/ipsec_tunnel/ >=20 > Please remeber that this is an early version, and I do not guarantee > anything. It does seem to interoperate with OpenBSD's IPsec though, and = I > have been using it for several weeks myself. >=20 > And yes, I've heard about FreeS/WAN... :-) >=20 > I'm interested in any comments or questions! I decided to CC this reply to the lkml, since IMO more people should know about this implementation of yours. I've taken a quick look at your webpage and the source code itself... one thing I saw is, that your implementation doesn't require any modification to the main kernel -- i.e. no patching required -- it's a plugin... just like CIPE... (which btw uses cryptoapi as well in its latest code base) (thus you don't even need to reboot your system in order to enable lightweight IPSEC in your kernel...) -- this fits well with the cryptoapi, which can add modular crypto support without needing to patch or reboot your kernel... I think, some people will like this lightweight IPSEC/IPv4 implementation, since it doesn't have the eroute/route-filtering facility of frees/wan...=20 on the other hand, it's not a complete IPSEC implementation (yet)... it only implements ESP for tunneling purposes, and lacks AH and IKE.... and frees/wan offers some advanced features like compression and icmp handling, which ipsec_tunnel may still lack... regards, --=20 Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 Email: hv...@hv... / Finger hv...@gn... for GnuPG Public Key GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142 |
|
From: Herbert V. R. <hv...@hv...> - 2002-04-24 07:11:56
|
fyi, -- Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 Email: hv...@hv... / Finger hv...@gn... for GnuPG Public Key GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142 ---------- Forwarded message ---------- Date: Wed, 24 Apr 2002 00:17:13 +0200 (CEST) From: Tobias Ringstrom <to...@ri...> To: lin...@nl... Subject: An IPsec tunnel implementation for Linux using CryptoAPI A little bit off-topic perhaps, but I'd like to congratulate you all on an extremely useable piece of software! When I decicided to make a light-weight IPsec tunnel implementation some time ago I decided very early on to use your CryptoAPI, and found it really easy to use. I now have a version of my IPsec tunnel implementation that seems to work just fine, and I think it's time to let you guys have a peek at it. You can find the code and a first stab at actual documentation at http://ringstrom.mine.nu/ipsec_tunnel/ Please remeber that this is an early version, and I do not guarantee anything. It does seem to interoperate with OpenBSD's IPsec though, and I have been using it for several weeks myself. And yes, I've heard about FreeS/WAN... :-) I'm interested in any comments or questions! /Tobias - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ |
|
From: Beau V.C. B. <be...@bo...> - 2002-04-23 12:50:32
|
>On Tue, 23 Apr 2002, Beau V.C. Bellamy wrote: >> I was wondering if the Crypto-API included support for encrypting the >> MAC (and IP) layers to provide a more secure networking environment. >well... if you encrypt MAC's and IP's in the IP packet header... how are >standard-konforming routers and switches supposed to work w/o getting >confused? I'm sorry to confuse and befuddle. I really meant encrypting just the da= ta at=20 level 2, not the header. The ethernet frame data. I use MAC to describe= the=20 whole layer, perhaps incorrectly. >or are we talking about some ethernet media being used as completely >encrypted 'serial' line, w/o the usual ethernet frame structure? Actually, the ethernet media I was refering to was 802.11 or Wireless=20 Ethernet. Though, It could probably to appled to wired ethernet if you f= eel=20 that someone might be able to gain unauthorized access to your network. >> The idea is to augment WEP or perhaps replace it with a kernel based >> solution with stronger encryption that would be both vendor neutral an= d >> more flexable. >..what is WEP? can you give me some pointers/URLs? :-) WEP stands for Wired Enquivalence Privacy. It is based on a weak keyed X= ORed=20 encryption algorithm that encrypts the ethernet frame data as it is=20 transmitted. It is usually implimented in the hardware and It's main pur= pose=20 is to prevent eavesdropping on wireless traffic. But... It is also very=20 easily broken with the right software. http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html >> I've used FreeS/WAN before but feel it's not very good for this type o= f >> application. After all, I'm not doing tunneling. >fres/wan is not only for creating tunneling, it also provides means for >authentification and/or encryption of untunneled connections... I feel that FreeS/WAN is too heavywieght as all I really want is to encry= pt=20 the ethernet frames. >> I would be willing to devote a lot of time to hacking in this type of >> support. >I'd like to learn more about what you're going to implement :-) I'm more than willing to talk about about this further... >regards, |
|
From: Herbert V. R. <hv...@hv...> - 2002-04-23 12:13:23
|
On Tue, 23 Apr 2002, Beau V.C. Bellamy wrote: > I was wondering if the Crypto-API included support for encrypting the > MAC (and IP) layers to provide a more secure networking environment. well... if you encrypt MAC's and IP's in the IP packet header... how are standard-konforming routers and switches supposed to work w/o getting confused? or are we talking about some ethernet media being used as completely encrypted 'serial' line, w/o the usual ethernet frame structure? > The idea is to augment WEP or perhaps replace it with a kernel based > solution with stronger encryption that would be both vendor neutral and > more flexable. ..what is WEP? can you give me some pointers/URLs? :-) > I've used FreeS/WAN before but feel it's not very good for this type of > application. After all, I'm not doing tunneling. fres/wan is not only for creating tunneling, it also provides means for authentification and/or encryption of untunneled connections... > I would be willing to devote a lot of time to hacking in this type of > support. I'd like to learn more about what you're going to implement :-) regards, -- Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 Email: hv...@hv... / Finger hv...@gn... for GnuPG Public Key GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142 |
|
From: Beau V.C. B. <be...@bo...> - 2002-04-23 08:57:16
|
Hello, I was wondering if the Crypto-API included support for encrypting the MAC= (and=20 IP) layers to provide a more secure networking environment. The idea is = to=20 augment WEP or perhaps replace it with a kernel based solution with stron= ger=20 encryption that would be both vendor neutral and more flexable. I've used FreeS/WAN before but feel it's not very good for this type of=20 application. After all, I'm not doing tunneling. I would be willing to devote a lot of time to hacking in this type of sup= port. Tell me your ideas... Thanks, Beau V.C. Bellamy |
|
From: David B. <db...@du...> - 2002-04-15 05:18:18
|
Hey guys, Just wondering if we could get a concrete listing of the things that need to be taken care of before we can release, I noticed jari released again today and we have nothing yet :-( Anyway, the other reason i ask is i ask hvr at different times and he gives me different peices each time ;-) So far i have: 1.) put dale's swap setup script somewhere as contrib script 2.) be sure the findpatch thingie works in at least 80% 3.) fix rc5 I looked at the source code a little this week, definatly not in depth as much as I should have. At any rate, if there is anything else speak up, so we can take care of it ;-) Dave |
|
From: Dale A. <am...@vn...> - 2002-04-11 19:26:49
|
On Thu, Apr 11, 2002 at 11:33:00AM -0600, David Bryson wrote: > $ make unpatch-loop KDIR=<kernel source dir> LOOP=<loop type> > Does that seem to work ok ? > Dave Kernel built and tested. Passes. |
|
From: Dale A. <am...@vn...> - 2002-04-11 18:12:14
|
On Thu, Apr 11, 2002 at 11:33:00AM -0600, David Bryson wrote: > Ok, I updated the findpatch script to take an option for jari or iv loop > patches and additionally modified the make file to deal with it as well. > > now patch-kernel will auto-patch loop-iv unless otherwise specified > quoteth the README: > > > $ make patch-kernel KDIR=<kernel source dir> LOOP=<loop type> > > And if you don't want to patch the loop driver: > > $ make patch-kernel-noloop KDIR=<kernel source dir> > > Or to just patch the loop driver > > $ make patch-loop KDIR=<kernel source dir> LOOP=<loop type> > > To remove the CryptoAPI from your kernel sources directory type: > > $ make unpatch-kernel KDIR=<kernel source dir> LOOP=<loop type> > > Similarly to undo the similar commands: > > $ make unpatch-kernel-noloop KDIR=<kernel source dir> > > and > > $ make unpatch-loop KDIR=<kernel source dir> LOOP=<loop type> > Does that seem to work ok ? > Dave Looking good. Command line worked; build is now in progress while I make supper and go off to watch the BBC evening news. |
|
From: David B. <db...@du...> - 2002-04-11 17:37:05
|
Ok, I updated the findpatch script to take an option for jari or iv loop patches and additionally modified the make file to deal with it as well. now patch-kernel will auto-patch loop-iv unless otherwise specified quoteth the README: $ make patch-kernel KDIR=<kernel source dir> LOOP=<loop type> And if you don't want to patch the loop driver: $ make patch-kernel-noloop KDIR=<kernel source dir> Or to just patch the loop driver $ make patch-loop KDIR=<kernel source dir> LOOP=<loop type> To remove the CryptoAPI from your kernel sources directory type: $ make unpatch-kernel KDIR=<kernel source dir> LOOP=<loop type> Similarly to undo the similar commands: $ make unpatch-kernel-noloop KDIR=<kernel source dir> and $ make unpatch-loop KDIR=<kernel source dir> LOOP=<loop type> Does that seem to work ok ? Dave On Thu, 2002-04-11 at 09:30, Dale Amon wrote: > On Thu, Apr 11, 2002 at 10:20:50AM -0600, David Bryson wrote: > > > So, possible solutions are to move the findpatch execution to another > > make process, which includes make patch-kernel and then runs findpatch, > > similary for unpatch-kernel. Or we could add a flag that specifies > > whether we use the iv or the jari patch. > > Why not give the options: > make patch-kernel-jari > make patch-kernel-iv > > or else the seqeunce > > make patch-jari or make patch-iv > make patch-kernel > > or perhaps > > make LOOP=iv patch-kernel > make LOOP=jari patch-kernel > > with the default LOOP=iv. > > Something that makes it explicit on the command line. > I want to be able to make this choice from a script. > > -- > ------------------------------------------------------ > Nuke bin Laden: Dale Amon, CEO/MD > improve the global Islandone Society > gene pool. www.islandone.org > ------------------------------------------------------ |
|
From: Herbert V. R. <hv...@hv...> - 2002-04-11 16:32:22
|
On Fri, 12 Apr 2002, Justin Clift wrote: > Herbert Valerio Riedel wrote: > > I'm toying w/ using the "Dual BSD/GPL" tag for ciphers which have a BSD > > w/o advertising clause license... > Where do you see an advantage in that? ...not (license)tainting the kernel ;) ...those insmod/modprobe warnings usually scare some users... and we don't want to scare poor users, do we? :) the other reason is, that linux distribution makers want non-tainting modules as well, as they look like having less legal issues to look after... regards, -- Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 Email: hv...@hv... / Finger hv...@gn... for GnuPG Public Key GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142 |
|
From: Justin C. <ju...@po...> - 2002-04-11 16:29:21
|
Herbert Valerio Riedel wrote: > > hey... > > I'm toying w/ using the "Dual BSD/GPL" tag for ciphers which have a BSD > w/o advertising clause license... Where do you see an advantage in that? :) Regards and best wishes, Justin Clift > > ...seems to be a common practice in the linux kernel... any > comments/ideas/suggestions? > > regards, > -- > Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 > Email: hv...@hv... / Finger hv...@gn... for GnuPG Public Key > GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142 > > _______________________________________________ > CryptoAPI-devel mailing list > Cry...@li... > https://lists.sourceforge.net/lists/listinfo/cryptoapi-devel -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi |
|
From: Herbert V. R. <hv...@hv...> - 2002-04-11 16:22:52
|
hey... I'm toying w/ using the "Dual BSD/GPL" tag for ciphers which have a BSD w/o advertising clause license... ...seems to be a common practice in the linux kernel... any comments/ideas/suggestions? regards, -- Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 Email: hv...@hv... / Finger hv...@gn... for GnuPG Public Key GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142 |
|
From: David B. <db...@du...> - 2002-04-10 20:20:09
|
Committed my first patches/findpatch.pl addition to the make patch-kernel/unpatch-kernel stuff. The script looks at the kernel version of the kernel to be patched, then attempts to locate the patch of the closest version, it's not very smart right now. For example if you have kernel version 2.4.17, and there are patches for 2.4.16 and 2.4.18 it will always choose the higher patch. I'll most likely change this to find the patch with the least distance numerically from the kernel version. Anyway, also updated the Makefile to include this at the end of the patch-kernel and unpatch-kernel instructions. ./kernel/Documentation/cryptoapi/cryptoloop.txt has also been updated to explain a bit about how loopback fs encryption works, and there is a section on how to use cryptoapi if you are migrating from loop-AES. also, it turns out apache is lame and doesn't list README files, even if you appent .txt to them. So those of you that looked at my docs earlier please go back and check again, since the readme's i modified are now up. Figure out what we still need put in there so that it's informative enough. all for now! Dave |
|
From: Herbert V. R. <hv...@hv...> - 2002-04-10 17:36:11
|
On Wed, 2002-04-10 at 18:36, Tobias Ringstrom wrote: > The example code has at least one typo: >=20 > struct cipher_implementation* ci =3D=3D cx->ci; my fault; fixed... > Unrelated to the docs, I see that most ciphers do not set the key_length=20 > member of the cipher_context struct. That should probably be fixed as=20 > well. you named the bug -> I fixed it & committed... :-) --=20 Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 Email: hv...@hv... / Finger hv...@gn... for GnuPG Public Key GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142 |
|
From: Tobias R. <to...@ri...> - 2002-04-10 16:36:37
|
On 10 Apr 2002, David Bryson wrote: > Ok, yesterday I updated the documentation (README's etc). And I ran out > of steam, so any ideas on what else needs to be added would be great. > If you all have some time, go over what I have > www.cs.du.edu/~dbryson/crypto The example code has at least one typo: struct cipher_implementation* ci == cx->ci; Unrelated to the docs, I see that most ciphers do not set the key_length member of the cipher_context struct. That should probably be fixed as well. /Tobias |
|
From: David B. <db...@du...> - 2002-04-10 16:17:29
|
Ok, yesterday I updated the documentation (README's etc). And I ran out of steam, so any ideas on what else needs to be added would be great.=20 If you all have some time, go over what I have www.cs.du.edu/~dbryson/crypto I'm almost finished with the find-nearest-patch perl script, and most likely i'll update the makefile for it some time later today. Dave |
|
From: Herbert V. R. <hv...@hv...> - 2002-04-10 08:25:22
|
> 4) rewrite DES/3DES, I mean seriously... it's nasty to look at actually that's not so important for the next release... the code works... even if it looks ugly... it's higher priority to check whether gladman's implementations we use can be made license compatible w/ the GPL kernel... regards, -- Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 Email: hv...@hv... / Finger hv...@gn... for GnuPG Public Key GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142 |
