| * sarnold sets mode: +m |
| sarnold | ok, i'd like to welcome everyone back to the day's final presentation, james morris of intercode |
|---|
| jamesm | hello, thanks for turning up! |
|---|
| sarnold | his presentation will be on the new cryptographic infrastructure he helped introduce into the 2.5 linux kernel |
|---|
| sarnold | james has also been instrumental in the LSM prject |
|---|
| sarnold | please direct your questions and comments to #qc |
|---|
| jamesm | A new crypto api was added to the 2.5 kernel recently, which will be part |
|---|
| jamesm | of the next stable kernel series (2.6). |
|---|
| jamesm | This api was initially developed to support the ipsec implementation of |
|---|
| jamesm | David Miller and Alexey Kuznetsov (which is also merged into the 2.5 kernel). |
|---|
| jamesm | It is also intended to be a generic api for use by other kernel components |
|---|
| jamesm | which require crypto, such as CIFS, cryptoloop and the /dev/random driver. |
|---|
| jamesm | Currently, it is a very simple software API, with a pluggable interface |
|---|
| jamesm | for algorithm modules. |
|---|
| jamesm | lgorithms implemented so far: |
|---|
| jamesm | Algorithms implemented so far: |
|---|
| jamesm | Digests: SHA1, SHA256, MD4, MD5. |
|---|
| jamesm | these are used for verifying data integrity and creating digital signatures, and message authentication codes for networking |
|---|
| jamesm | Ciphers: Blowfish, DES, 3DES, Twofish, Serpent. (AES is in development). |
|---|
| jamesm | these are symmetric encryption algorithms, where you (usually) use the same key to encode and decode, and the key must be kept secret |
|---|
| jamesm | most encryption applications use a combination of data integrity and encryption |
|---|
| jamesm | <sarnold> jamesm: it'd make my life easier if you guys included assymmetric algorithms too :) |
|---|
| jamesm | asymmetric support is being considered, it would be useful for code signing and multicast ipsec |
|---|
| jamesm | and certainly we'd like to allow userspace to take advantage of available asymmetric crypto hardware |
|---|
| jamesm | as it is very slow in software |
|---|
| jamesm | <sh0nX> jamesq: can this new crypto API be used for SSH/SSL? or we still need to depend on software level crypto? |
|---|
| jamesm | not yet, and it would only make sense when the api provides access to hardware acceleration |
|---|
| jamesm | The api provides the HMAC algorithm for digests (used by ipsec), and CBC |
|---|
| jamesm | mode for ciphers (this chains the results of last encryption to the next |
|---|
| jamesm | one to increase security, and is very commonly used). |
|---|
| jamesm | Currently, the api has been proven with ipsec. Some further work may |
|---|
| jamesm | be required to make it work well for cryptoloop. |
|---|
| jamesm | A specific feature of the api is that it operates on arrays of page vectors |
|---|
| jamesm | (scatterlists) rather than plain memory buffers (pages are fundamental |
|---|
| jamesm | chunks of memory that the kernel manages). |
|---|
| jamesm | This allows deep integration with other kernel components such as the |
|---|
| jamesm | networking stack, and provides a scatter/gather interface. |
|---|
| * mathmoi has quit IRC (Signed off) |
| jamesm | (in userspace, a well known scatter/gather interface is readv()/writev(), the crypto api uses a similar concept on pages instead of plain buffers) |
|---|
| jamesm | <sarnold> i'd think cryptoloop might need to use ECB mode for random access to blocks.. is this correct? |
|---|
| jamesm | as far as i know, cryptoloop uses CBC mode, and sets the IV to something derived from the disk block |
|---|
| jamesm | so, the main idea of operating on pages and scatter/gather is efficiency. |
|---|
| jamesm | pages are fundamental to the kernel, and scatter/gather allows data to be transformed without copying it all into one buffer |
|---|
| jamesm | this can be carried down to the hardware level, and use scatter/gather DMA operations |
|---|
| jamesm | as Dave Miller has been part of designing this, it is aimed at high performance |
|---|
| jamesm | it will be good to compare our performance against openbsd, who already have integrated crypto |
|---|
| jamesm | In the case of ipsec, the design of the crypto api allows crypto transforms |
|---|
| jamesm | to be applied directly to discontiguous pages of memory associated with |
|---|
| jamesm | network packets (e.g. IP fragment lists, zero-copy pages being transmitted |
|---|
| jamesm | via sendfile()). |
|---|
| jamesm | it seems to be working ok so far, but we have done no performance optimizations yet, or tried hardware acceleration |
|---|
| jamesm | <addict> do you know why linux didn't integrated it before ? |
|---|
| jamesm | there has been a kernel crypto patch available for some time (by the people at kerneli.org), but i think that legal issues prevented crypto from being fully integrated into the kernel until now |
|---|
| jamesm | openbsd had crypto integrated because it is developed outside the USA |
|---|
| jamesm | The api currently works in-place on data, although it may soon be modified |
|---|
| jamesm | to allow different input/output scatterlists for cryptoloop. |
|---|
| jamesm | Future/ongoing work: |
|---|
| jamesm | Optimized assembler versions of the algorithms have not yet been implemented, |
|---|
| jamesm | all are currently generic C versions. |
|---|
| jamesm | Work has started on support for crypto hardware devices, which may be useful |
|---|
| jamesm | for increasing performance and scalability. |
|---|
| jamesm | (note that some people, such as Linus, have doubts about how useful hardware cards might be, as it will involve copying data back and forth across the pci bus, when todays cpu's are very fast. it is a big area to be analyzed) |
|---|
| jamesm | <sh0nX> with the new crypto, is all the memory protected while in use? |
|---|
| jamesm | <sarnold> sh0nX: kernel memory cannot be paged to disk |
|---|
| jamesm | when the userspace api is developed, this may become an issue though |
|---|
| jamesm | <addict> are you looking for some hardware crypto such as powercrypt ? |
|---|
| jamesm | yes, i have an older powercrypt card (hifn7751) and some soekris cards (which are quite cheap) |
|---|
| jamesm | Of particular interest are network cards which have crypto chips on them. |
|---|
| jamesm | Such cards allow packets to be copied once across the PCI bus to the card, |
|---|
| jamesm | where the packets can be encrypted and transmitted to the network without further |
|---|
| jamesm | copying across the bus. |
|---|
| jamesm | Unfortunately, we have not been able to get any documentation on these cards yet. |
|---|
| jamesm | A userspace API is also being designed to allow applications (e.g. SSL, IKE) |
|---|
| jamesm | to take advantage of available hardware. |
|---|
| jamesm | The userspace API will likely be a pseudo filesystem (cryptoapifs, perhaps), and character devices will be used for accessing the crypto features in the kernel and hardware |
|---|
| jamesm | as the api works on pages, we should be able to do interesting things by mmaping the character devices |
|---|
| jamesm | the userspace api will also allow a much cleaner and more extensive testsuite to be developed |
|---|
| jamesm | the current test code is a kernel module which is very very ugly |
|---|
| jamesm | <sarnold> jamesq: has there been discussion on using the openbsd /dev/crypto api itself? |
|---|
| jamesm | yes, it would be nice to provide a compatibility layer, although it has not been analysed deeply yet |
|---|
| jamesm | The first steps for hardware support are obtaining cards, documentation and |
|---|
| jamesm | writing clean GPL drivers (i.e. a lot of work). |
|---|
| jamesm | e are trying to get |
|---|
| jamesm | as many different types of cards as possible so that we understand |
|---|
| jamesm | generic requirements |
|---|
| jamesm | this is where support for asymmetric crypto will be considered, as many cards offer this now, and it is much faster in hardware |
|---|
| jamesm | <translator wait> |
|---|
| jamesm | Resources: |
|---|
| jamesm | http://samba.org/~jamesm/crypto/ (updates, status, patches etc.) |
|---|
| jamesm | http://www.kerneli.org/pipermail/cryptoapi-devel/ (development discussion) |
|---|
| jamesm | Kernel source files under the crypto directory, recent 2.5 kernels. |
|---|
| jamesm | Documentation under the Documentation/crypto directory (includes detailed credits). |
|---|
| jamesm | The March 2003 Linux Journal will have an article on the api. |
|---|
| jamesm | that's all i have prepared, so if anyone has any questions/discussion? |
|---|
| jamesm | <addict> jamesm: could be nice to past this URL too: http://www.openbsd.org/crypto.html |
|---|
| jamesm | <sarnold> jamesq: how would you suggest someone try to implement, e.g, RSA for the plugin api? |
|---|
| jamesm | i don't know yet, but Jean-Luc Cooke has been working on it |
|---|
| jamesm | see http://jlcooke.ca/cryptoapi/pk/ and discussion on cryptoapi-devel |
|---|
| jamesm | it's not an area that i've had time to look at in detail so far |
|---|
| jamesm | <riel> jamesq: did you read my idea about "random ipsec" without authentication ? does it look useful or does ipsec |
|---|
| jamesm | +really need authentication to be useful ? |
|---|
| jamesm | i seem to recall reading something about this in the last day or so, but can't remember the details |
|---|
| jamesm | but i believe ipsec generally needs authentication to be secure |
|---|
| jamesm | <riel> basically the idea was to have a "default ipsec" thingy that negotiates encryption with unknown hosts |
|---|
| jamesm | <riel> so a large percentage of internet traffic gets encrypted |
|---|
| jamesm | <riel> and passive sniffing of bulk traffic becomes prohibitively expensive |
|---|
| jamesm | i don't know the full cryptographic implications, it would need to be analysed further |
|---|
| jamesm | it may actually open up new attacks |
|---|
| jamesm | (i.e. if you decide to trust unauthenticated data) |
|---|
| jamesm | <riel> jamesq: ahh, but it's not about real trust, it is about making passive sniffing of bulk traffic prohibitively |
|---|
| jamesm | +expensive |
|---|
| jamesm | interesting idea |
|---|
| jamesm | are there any more questions on the api? |
|---|
| jamesm | ok, well that's the end of my presentation, i think there is some interest in a more general crypto discussion |
|---|
| sarnold | jamesq: any thoughts on theo's idea of setting aside one processor of an SMP machine for crypto tasks? |
|---|
| Ricardo | We've moved the discussion en #qc here, people |
|---|
| Ricardo | You can speak :) |
|---|
| riel | sarnold: probably no the smartest idea |
|---|
| jamesm | sarnold: not really |
|---|
| riel | sarnold: then your network traffic has to pass from one CPU cache to RAM and then into the other CPU cache |
|---|
| jamesm | also, |
|---|
| jamesm | <garoeda> how can a normal user benefit of this? |
|---|
| riel | it'll probably be faster if each network packet only touches one CPU |
|---|
| addict | sarnold: it will be many slower |
|---|
| jamesm | the main thing for users is integrated crypto in the kernel, so things like ipsec, disk encryption become part of the mainline kernel |
|---|
| viZard | plas plas plas plas plas plas plas plas plas |
|---|
| viZard | plas plas plas plas plas plas plas plas plas |
|---|
| viZard | plas plas plas plas plas plas plas plas plas |
|---|
| viZard | plas plas plas plas plas plas plas plas plas |
|---|
| gorog | clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap |
|---|
| viZard | plas plas plas plas plas plas plas plas plas |
|---|
| viZard | plas plas plas plas plas plas plas plas plas |
|---|
| viZard | plas plas plas plas plas plas plas plas plas |
|---|
| addict | stupid. |
|---|
| * riel buys jamesm a virtual beer |
| riel | thanks for the talk |
|---|
| riel | clap clap clap clap clap clap |
|---|
| riel | clap clap clap clap clap clap |
|---|
| krocz | CLAP |
|---|
| krocz | CLAP |
|---|
| viZard | addict huh ? |
|---|
| seeker | CLAP :) |
|---|
| sarnold | jamesm: do you think the encrypting block device needs the two scatter/gather lists to be implemented? |
|---|
| addict | a big Clap is enough no ? |
|---|
| krocz | yes |
|---|
| addict | jamesm: thx a lot, merry christmas ;) |
|---|
| krocz | :D |
|---|
| garoeda | clap clap clap clap clap clap |
|---|
| garoeda | nice one |
|---|
| Arador | addict: i don't see that in real life, why here? ;) |
|---|
| Arador | i don't know a lot about ipsec and cryptography , but could riel elaborate a bit about that idea for dummies (as everybody says it seems interesting ;)? |
|---|
| jamesm | sarnold: it needs either in/out scatterlists (difficult), or perhaps we provide direct access to the underlying crypto algorithms via api wrappers |
|---|
| * Ricardo wants to thank jamesm while he can (before continuing translating X)) |
| sarnold | Arador: normal ipsec requires both endpoints to be "authenticated" to each other |
|---|
| riel | Arador: jamesm is the crypto expert, I don't know much about it |
|---|
| sarnold | Arador: which requires pre-established trust relationships |
|---|
| garoeda | MJesus: you can pick up the #taee logs :-) |
|---|
| gorog | why this lecture-series isn't in openprojects ircnetwork? |
|---|
| surriel | THANKS jamesm !! |
|---|
| jamesm | thanks for waiting up everyone |
|---|
| sarnold | Arador: riel's idea is that two endpoints that both speak ipsec should be able to talk to each other even if they can't authentication each other |
|---|
| surriel | gorog: uninet has a bunch of events on different themes |
|---|
| sarnold | surriel: take care :) |
|---|
| garoeda | jamesm: it was interesting |
|---|
| surriel | gorog: UMEET is just one of many events |
|---|
| garoeda | surriel: goodnight |
|---|
| sarnold | gorog: openprojects is free to do whatever lecture series they wish ;) |
|---|
| jamesm | (also, i am not a crypto expert) |
|---|
| sarnold | Arador: (err, speak to each other via encrypted/"authenticated" connections...) |
|---|
| jamesm | we're lucky to have support from some real cryptographers e.g. jlcooke, dag arne osvik |
|---|
| sarnold | Arador: this would, if nothing else, make sniffing a network connection much more difficult -- it would require an active man in the middle attack |
|---|
| addict | Niels Provos |
|---|
| sarnold | Arador: and, intercepting an active session would be more difficult than without ipsec, though not as difficult as with full-authenticated ipsec |
|---|
| gorog | ok |
|---|
| gorog | i go away |
|---|
| gorog | bye all |
|---|
| sarnold | Arador: if i'm not mistaken though, this is where IKE and pluto and .. ? other key-negotiation protocols come in handy; they should be able to negotiate keys on the fly with anyone |
|---|
| gorog | and thx for jamesm |
|---|
| Arador | that's, encrypt everything to ensure the traffic in general? |
|---|
| sarnold | Arador: with other ipsec-aware endpoints, yes |
|---|
| addict | everything ? |
|---|
| Arador | when ipsec isn't available, i see |
|---|
| sarnold | Arador: well, when there is no pre-existing trust relationship between two ipsec endpoints |
|---|
| sh0nX | clap clap clap clap clap clap clap clap clap clap clap clap |
|---|
| sh0nX | clap clap clap clap clap clap clap clap clap clap clap clap |
|---|
| sh0nX | clap clap clap clap clap clap clap clap clap clap clap clap |
|---|
| sh0nX | clap clap clap clap clap clap clap clap clap clap clap clap |
|---|
| sh0nX | clap clap clap clap clap clap clap clap clap clap clap clap |
|---|
| sh0nX | just scrolled up ;-) |
|---|
| addict | hehe |
|---|
| Arador | jamesm: thanks for the lecture ;) |
|---|
| seeker | Is there any other talk for the next days? |
|---|
| sh0nX | yes, thank you jamesm. |
|---|
| garoeda | seeker: http://umeet.uninet.edu :-) |
|---|
| seeker | thanks :) |
|---|
| sarnold | jamesm: thanks! :) I appreciated it :) |
|---|
| sh0nX | er |
|---|
| sh0nX | questions: #qc english: #redes ? |
|---|
| sh0nX | perhaps |
|---|
| sarnold | after Javier's talk, we will have two presentations on Gentoo :) |
|---|
| * garoeda thinks..interesting |
| sh0nX | sarnold: that means people should be going #redes for english questions? |
|---|
| sarnold | sh0nX: or asking in #qc and hope someone translates :) |
|---|
| sh0nX | hehe |
|---|
| sh0nX | :) |
|---|
| Arador | sh0nX: or learn spanish NOW! :) |
|---|
| sarnold | Ricardo: jejeje, i thought about that... :) |
|---|
| Ricardo | sarnold: mh? |
|---|
| mjc | jejeje/ |
|---|
| mjc | ? |
|---|
| sarnold | Ricardo: thanks for fixing the accents :) |
|---|
| garoeda | next talk is today, 22 utc..is this correct? |
|---|
| Ricardo | oh |
|---|
| Ricardo | :-) |
|---|
| Ricardo | sarnold: I was more concerned about spelling correctly lecturer's surname O:) |
|---|
| sarnold | Ricardo: hummm, i did miss 'n' didn't I? :( |
|---|
| addict | garoeda: yes |
|---|
| Ricardo | sarnold: don't worry :-) |
|---|
| addict | Dec, 15. 22:00 Seth Arnold. WireX Communications USA "Sardonix: making the most of our open source" |
|---|
| jamesm | sarnold: no problems |
|---|