FUD about CGD and GBDE
I'm not regularly reading hackers these days, but I was pointed to the amazing FUD being spread here. Please keep me in the Cc: if you want me to see your replies. The fact that the CGD author(s) engage in this FUD spreading in random mailing lists rather than contact me directly speaks speaks for itself, but here are my replies to some of the points raised: If an attacker decides to attack a GBDE encrypted disk by brute-forcing all the sectors he might have a theoretically very simple task of on average 2^128 * Nsect work. Right now 2^128 is considered a safe workload for brute force, but that is assuming that the algorithms stand up to analytical attack. But the devil is in the detail, and the detail in this case is knowing that you had a hit. The biggest problem in brute-force attacks is very often to _know_ that you had a hit. The actual crypto operations can be put in silicon, but the practical hit-recognition is usually too complex for hardware. A brute force attack will produce 2^128 possible sector contents and the attacker has no way of _knowing_ that he found the right contents until he has checked if the hit is consistent with the rest of his hits and the GBDE key schedule. A brute force attack on a single sector in a trivial disk encryption like CGD will reveal the key for all of the disk and you can very fast verify that you got it right. The fact that filesystems contains highly structured data like superblocks and bitmaps makes this sensitive to almost any kind of weakness in the chipher. A brute force attack on a single sector in GBDE gives that sector and nothing which you can use the rest of the sectors with because the key is PRNG, one-time use for each sector. GBDE is written so there is no two-side leverage on any protocol involved. This means that if a weak key is discovered or if one of the algorithms has a major glaring hole of some kind, breaking one single sector does not reveal any other sectors. GBDE is probably slight overkill in this respect, but the other extreeme, encrypting the entire disk with the same key (as CGD) is very vulnerable to any kind of weakness in the ciphers: On a contemporary disk that approach offers 80.000.000 differential data points. No sane persone should ever encrypt 80.000.000 piece of data with the same key: A one bit chip in the armour of the cipher cuts 26 bits off the key. CGD even uses the key twice (a BIG no-no if I ever learned anything) so they may loose much more. The claim that: It is also structured in such a way that substantial breakthroughs in the cracking of many different encryption algorithms, hashes and random number generators will bring the house of cards down. Sounds very interesting and I am very much looking forward to, but not seriously expecting ever to, read a substantiation of this claim. (Notice that I made the margin wider here to make sure they don't run out of space :-) As for the encryption algorithms being changeable, GBDE can be used with any cipher and hash you care for. True, at this point it would require a source code change, but it is not impossible as claimed. If somebody wants an AES256 bit version of GBDE it wouldn't take an hour to make the necessary changes. The choices of algorithm I made were guided by which algorithms had the best legal standing. It is no use that I think that algorithm FOO is better if all the users of GBDE is bound by a legal requirement for AES. Right now everything I have seen in the real world demands AES128. The claim that CGD can change the passphrase without reencrypting they entire disk falls flat on its face: One cannot seriously claim to have changed the passphrase if the 256 bit key used for the entire disk remains constant. The static master key needs to be at least 1024 bits to satisfy the contemporary security policies I have been given access to. With respect to the dictionary attack. The _real_ key of GBDE is either 512 bits (changeable, for each of the four keys) or 2176 bits static, depending on where you decide to attack. I have not heard of any realistic dictionary attacks of that size, mostly due to shortage of atoms in the universe. Now, currently the 512 bits are derived by running whatever the user provides through SHA2, and if the user provides password, then a dictionary attack is indeed very feasible. That, however, is not a problem in GBDE, that is a problem in the users key-handling. A very crucial design decision was that I did not want to impose a particular kind of key-management on users of GBDE. Some people want to use smartcards, some wants to split the the key between multiple persons, across multiple locations or multiple media. Some people use PGP/GPG for password management, other people use signed CERTS. PKCS5 can obviously be used too. GBDE allows any and all of these, by simply requring the production of a repeatable bytestring of user selected length. Users so far seem
Re: FUD about CGD and GBDE
[EMAIL PROTECTED] wrote: The fact that the CGD author(s) engage in this FUD spreading in random mailing lists rather than contact me directly speaks speaks for itself, but here are my replies to some of the points raised: Obviously this is a part of some aggressive NetBSD advocacy campaign that was started just recently, I find it hard to believe that someone just happened to find my original RFC on backporting GEOM to 4.x from like a month ago and then decided to revive the thread. Someone was looking for something recent about GBDE they could claw into. Anyone who has read recent posts by Chritos Zoulas can see the pattern, this seems to be an organized effort not so much pro NetBSD but anti other BSDs. There is really no need for that kind of campaigning, it gives a bad name to all BSDs. All software has some merit, just state the facts and let the users decide what they want. I agree with you on almost all the other points you addressed (journaling being an exception - I would make it optional, not mandatory) as I have stated pretty much the same things myself in my previous posts, so I will not further comment on that, but I would like to ask your opinion on the matters I raised about introducing the following changes to GBDE: 1. Introducing a sysctl variable to control how often (after how many writes) the random key is regenerated: kern.geom.bde.random_key_regeneration_cycle The way it works now would correspond to the value being 1 with regeneration happening on every write. Setting this higher would improve the performance and people could decide for themselves what value fits their needs. 2. Backporting to 4.x - this has more or less come to the point that I would rather write the whole thing from scratch, similar to vncrypt (ports/security/vncrypt), only implementing the main principles found in GBDE. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FUD about CGD and GBDE
In message [EMAIL PROTECTED], ALeine writes: 1. Introducing a sysctl variable to control how often (after how many writes) the random key is regenerated: kern.geom.bde.random_key_regeneration_cycle The way it works now would correspond to the value being 1 with regeneration happening on every write. Setting this higher would improve the performance and people could decide for themselves what value fits their needs. I don't really think you would gain any performance, but I am open to benchmarks proving me wrong. 2. Backporting to 4.x - this has more or less come to the point that I would rather write the whole thing from scratch, similar to vncrypt (ports/security/vncrypt), only implementing the main principles found in GBDE. I wouldn't bother. 4.x is nearing the EOL and you wouldn't get much useful lifetime out of it. It wouldn't be too much work to do it however. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: backporting GEOM to the 4.x branch
In message [EMAIL PROTECTED], ALeine writes: I find using a single key for the whole disk less secure and not very practical when one wants to change the key because it takes a very long time to re-encrypt the entire disk. However, having a separate per-sector key which is changed on every write seems to go too far in the opposite direction, so IMHO the best solution would be to use the same key for a definable number of sectors (set at initialization) and then having a sysctl variable to control after how many writes you want the key changed. This would speed things up quite a bit and users would be allowed to decide how much assumed security they are willing to sacrifice for noticable speed. This would also make it possible to implement my key shadow sector idea without a performance penalty in comparison to the current implementation of GBDE. I confess that I still don't see the threat model here. What sort of cryptanalytic breakthrough would make this a requirement? I will state categorically that I know of no threat to AES that would be addressed by this, but wouldn't require replacing AES entirely. The canonical example is encrypting too much data with the same key. That can be a real concern. With DES or 3DES (or any other cipher with a 64-bit blocksize), one should never encrypt more than 8*2^32 bytes -- about 32G -- with a single key if you're using CBC mode. The corresponding figure for AES is 16*2^64 -- a *much* larger number, and one well beyond any conceivable disk drive. Historically, there have been ciphers that were attackable with lots of traffic, but typically the issue was repetition of the key stream. That's not going to happen here. I leave as an exercise for the reader computing just how unlikely it is -- but it's *very* unlikely. Remember that we're dealing with 128-bit input blocks. It is, of course, conceivable that someone will find a way to use hundreds of gigabytes of data encrypted with one key to find some shortcut attack on AES -- perhaps 2^112 trials instead of 2^128. Given the reaction in the cryptographic community to the SHA1 attack, which cuts the time to 2^69 from 2^80, I'm quite confident of what would happen: a replacement for AES. That said, if you were concerned there's a very simple solution: to encrypt block B with master key K, calculate some cryptographic function F(K, B) -- ECB encryption is the obvious choice -- and use that as the block key. Use F'(B) or F'(K, B) to get the per-block IV. Add any wrinkles you want, such as caching F and F' values, or having F apply to a range of blocks. I see no need to rekey the disk. I do see a need to change the user-specified key, but that can be handled by a layer of indirection. If there were some sort of compromise that made you want to rekey the entire disk, having per-block keys won't help; you still need to read, decrypt, re-encrypt, and rewrite each block, since any likely compromise scenario would involve compromise of the key block as well. There's a school of cryptographic design that tosses in mechanisms on the vague hunch that there's threat out there. Unless you understand the threats and the tradeoffs, though, you're likely to make matters worse, not better. Often, there is no perfect solution, but if you don't understand the *real* threats you'll make the wrong tradeoffs. It's worth noting that there is a very real threat not addressed here: detecting unauthorized changes to an encrypted disk. For a very elegant solution, see http://www.isoc.org/isoc/conferences/ndss/05/proceedings/papers/storageint.pdf --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RFC: [conf/78257, PATCH] /etc/rc.d/memdisk for /dev/md* creation at startup
Hello hackers, Could you take a look at my PR which contains rc.d/ script for attaching memory disks managed with mdconfig(8) on system startup: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/78257 Comments are welcome. Best regards, -- * Wojciech A. Koszek [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Remote kernel debugging using GDB
Hello all, I want to do some remote kernel debugging using GDB on FreeBSD 5.3. I connected host and target with a null-modem cable on COM1 and made a debug kernel with options GDB, options DDB, options KDB and makeoptions DEBUG=-g and I set the port flags of sio0 to 0x80. But if I start the debug kernel on the target machine with boot -d I always get the message GDB: no debug ports present and if I want to start GDB I get The remote GDB backend could not be selected. In debug.kdb.available I only see the ddb and sysctl -w debug.kdb.current=gdb fails. Does anybody know what´s going wrong here? Any help is greatly appreciated. Thanks, Achim Leubner ICP vortex GmbH / Adaptec Inc. Phone: +49-351-8718291 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
kernel core dump
Hi, I have a Q on generating kernel core dump when the system boots up.. my kernel crashes when it tries to mount the root device, /, i.e., before it adding the swap device to the system (so there is no swap device when the system tries to generate core dump).. I am wondering is there a way to adjust this boot order, so that the system will add swap device before it mounting the root device, so hopefully the swap device is there when the kernel crashes.. Is yes, what change i should made to change that boot order? many thanks, yan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FUD about CGD and GBDE
On 1109758470 seconds since the Beginning of the UNIX epoch Poul-Henning Kamp wrote: So how about it guys: Instead of spreading FUD, lets work together and make the world an even better place ? I am hoping that the discussion will yield infomation that will allow each of us to improve our respective systems. I shall respond to the points out of order. All the talk about what happens during a powerfail/crash is rather uninformed: On any contemporary filesystem you will loose data, encrypted or not, if the system crashes before you have a zero return value from fsync(2). If fsync(2) completed successfully, your data is safe on the disk, both with GBDE and CGD. Adding journaling or before/after images to the disk encryption is totally the wrong way to address this problem since all your filesystems and disk device drivers suffer from the same issue. Let's discuss a simple example and see how it works. Let's walk through a user login, with /etc/passwd on GBDE and the filesystem mounted with mtime. Now: 1. A user logs in, /etc/passwd is consulted, 2. mtime of /etc/passwd is updated, 3. the file system over GBDE at some point decides to rewrite /etc/passwd's inode, 4. a new key is randomly generated for the inode sector, 5. the key-key sector is regenerated and written, and 6. the newly encrypted inode sector is written. Now, if the power is cut or the operating system crashes between steps 5 and 6, you have now lost the inode for /etc/passwd (and a few more files). Contemporary filesystems generally do not lose data when a file is read. But, unless there is some logic under GBDE or in FFS which I have failed to see, this is possible with FFS over GBDE. This has nothing to do with the semantics that fsync(2) guarantees. It is a matter of the atomicity assumptions that the filesystem expects a disk (or pseudo disk) to provide, and as I stated earlier the requirement is that if the sector contains A and I try to write A' then after a crash the sector will contain either A or A' but not A''---the decryption of A with the A' key. Now, what about GBDE or FFS makes this situation impossible? With respect to the dictionary attack. The _real_ key of GBDE is either 512 bits (changeable, for each of the four keys) or 2176 bits static, depending on where you decide to attack. I have not heard of any realistic dictionary attacks of that size, mostly due to shortage of atoms in the universe. Now, currently the 512 bits are derived by running whatever the user provides through SHA2, and if the user provides password, then a dictionary attack is indeed very feasible. That, however, is not a problem in GBDE, that is a problem in the users key-handling. A dictionary attack refers specifically to the process of guessing passphrases. It is not a generic brute force attack on the whole key space, and it uses the fact that passphrases have substantially weaker security properties than random bags of bits. Under the assumption that my USB dongle is generally an average of 20 feet from my laptop (because I take both of them with me most places), I normally have to assume that the 2-factor authentication that I use will help but the system _must_ be secure in the face of compromise of both the dongle and the laptop. With that in mind, the attacker will simply guess passphrases using reasonably well known and reasonably effective techniques of generating the kinds of passphrases that people use. Given that the human memory is not expanding at nearly the same rate as computer processing power, something needs to be done about this vector. It is all well and good for both of us to talk about 2^256 and 2^2176 and 2^128 * 2^30, etc. But, a dictionary attack is likely to be a lot closer to 2^35 or 2^40. This is, I think, in the general use case the real threat. It is the low hanging fruit. With GBDE, the dictionary attack can be performed half offline because the SHA2/512 is not salted. And, after you get to the online portion, it basically comes down to a simple AES setkey and encrypt to verify whether the passphrase is valid. My laptop can perform abut 100k of these operations per second (if it is plugged into the wall) and it is not exactly a fast computer. That means that I can run through about 2^30 guesses in 2.5 hours. This will obtain naive user's passphrases within the first few days. More savvy users may take a bit longer, but it is all within the realm of the very possible without any advances in cryptography---unlike cracking CGD' AES256 or GEOM's AES128 on the sectors. The claim that CGD can change the passphrase without reencrypting they entire disk falls flat on its face: One cannot seriously claim to have changed the passphrase if the 256 bit key used for the entire disk remains constant. The static master key needs to be at least 1024 bits to satisfy the contemporary security policies I have been given access to.
Re: sched_4BSD
Wouldn't a multi threaded program potentially need more cpu time than vi? Multithreaded apps are created to do a lot of computation or because they have a lot of concurrent activity that might block right? On Mar 1, 2005, at 2:49 PM, Julian Elischer wrote: If you make 1000 threads, you get 1000 slots on the scheduler. (last time I looked.. Let me know if I'm wrong). The guy next to you with 'vi' gets 1 slot.. who gets more cpu? Lucas Holt [EMAIL PROTECTED] FoolishGames.com (Jewel Fan Site) JustJournal.com (Free blogging) FoolishGames.net (Enemy Territory IoM site) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sched_4BSD
--- Lucas Holt [EMAIL PROTECTED] wrote: Wouldn't a multi threaded program potentially need more cpu time than vi? No. That is not a given. Multithreaded apps are created to do a lot of computation or because they have a lot of concurrent activity that might block right? Threads are meant to take advantage of concurrency. Maybe the freebsd implementation should implement NPTL in entirety. On Mar 1, 2005, at 2:49 PM, Julian Elischer wrote: If you make 1000 threads, you get 1000 slots on the scheduler. (last time I looked.. Let me know if I'm wrong). depends on whether it is defined to execute in system scope or not. regards -kamal = Kamal R. Prasad UNIX systems consultant [EMAIL PROTECTED] In theory, there is no difference between theory and practice. In practice, there is:-). __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dynamically Linked Library Problem (maybe)
On Mon, Feb 28, 2005 at 11:48:14PM +0200, Cole wrote: Hey. I have a Freebsd server running freebsd-4.9-stable. I cvsupped the ntop src last week for 3.1.1. I then had no problems what so ever building ntop, except for the xml plugin saying it was not built, cause it cannot find xmlversion.h, even though I have libxml installed, and specified the right paths to the .h. But that is not the problem. Ntop runs and works fine on this box, not a single problem that I can see. The problem is that, I have a few other servers, that I want to copy ntop too, but dont want to build it on all those boxes. I created a tar with all the ntop binaries, as well as all the libraries that its linked too, as well as all the plugins that ntop uses from both the /usr/local/lib directory as well as the plugins from the /usr/local/lib/ntop/plugins directory. I rebuilt all the symbolic links for all the libraries and plugins and all the files that ntop was linked too. I have also checked all the permissions on all the files and they are all the same. One other thing, the boxes that I am copying ntop to, are almost exact duplicates of the first box that I built ntop on, and where it works fine. The problem is, when running ntop on the boxes that I copied it to, after checking all the permissions and links and everything, I get these errors with regards to the plugins. Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/icmpPlugin.so' entry function [Invalid shared object handle 0x29a14000] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/snmpPlugin.so' entry function [Invalid shared object handle 0x29a16400] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/sflowPlugin.so' entry function [Invalid shared object handle 0x29a19800] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/rrdPlugin.so' entry function [Invalid shared object handle 0x29a1bc00] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/pdaPlugin.so' entry function [Invalid shared object handle 0x2bcae400] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/netflowPlugin.so' entry function [Invalid shared object handle 0x2d862800] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/lastSeenPlugin.so' entry function [Invalid shared object handle 0x2d866c00] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/xmldumpPlugin.so' entry function [Invalid shared object handle 0x2f697000] I have absolutely no idea how this has happened, and I have had this problem before, and not a single other person was able to help me in any regards what so ever. I was hoping maybe someone would at least know what this error even means, so that I have some idea of what I am meant to be doing to fix this. If anyone has any idea, I would gladly apprecaite any suggestions. It seems to me error messages mean one thing - those plugins were corrupted in some way. It is also not clear from your message - are you using net/ntop from ports tree or you are building it from sources manually? In case of problems when building from a port you'd better ping port maintainer. -ip -- You are never given enough time or money. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: retricted environment
On Tue, 1 Mar 2005, Matt wrote: When providing a shell environment for a larger number of users, what is the best way to retrict access to commands/resources? I've already setup quotas. I don't want users playing with system commands. I've read something about a retricted shell, but can't find any details. Sorry if this is a little too late but your best bets are of (chmod,chown,chflags) also in (/etc/login.conf). Besides that it doesnt matter in a normal environment if a reg'd user messes with system commands, they wont beable to change anything with the system anyway and even if you didnt resitrict the commands that they can execute they just might report to syslog that the $UID was trying to use them and give you a heads up on trying to keep track of the user at hand. Best of luck: for more great info on FreeBSD and its options check out freebsd.org/handbook /faq and http://draenor.org/securebsd/secure.txt Best of luck --c0ldbyte This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sched_4BSD
Lucas Holt wrote: Wouldn't a multi threaded program potentially need more cpu time than vi? Multithreaded apps are created to do a lot of computation or because they have a lot of concurrent activity that might block right? Isn't that what nice is for? if (only) two processes are using all the cpu they can get, and one is written using 1000 threads, then why should it get 1000/1001 of the cpu? On Mar 1, 2005, at 2:49 PM, Julian Elischer wrote: If you make 1000 threads, you get 1000 slots on the scheduler. (last time I looked.. Let me know if I'm wrong). The guy next to you with 'vi' gets 1 slot.. who gets more cpu? Lucas Holt [EMAIL PROTECTED] FoolishGames.com (Jewel Fan Site) JustJournal.com (Free blogging) FoolishGames.net (Enemy Territory IoM site) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sched_4BSD
Kamal R. Prasad wrote: --- Lucas Holt [EMAIL PROTECTED] wrote: Wouldn't a multi threaded program potentially need more cpu time than vi? No. That is not a given. Multithreaded apps are created to do a lot of computation or because they have a lot of concurrent activity that might block right? Threads are meant to take advantage of concurrency. Maybe the freebsd implementation should implement NPTL in entirety. NPTL? New Pthreads Library from Library? isn't that GPL'd? On Mar 1, 2005, at 2:49 PM, Julian Elischer wrote: If you make 1000 threads, you get 1000 slots on the scheduler. (last time I looked.. Let me know if I'm wrong). depends on whether it is defined to execute in system scope or not. I presume you have looked at it recently then.. I have not looked at the linux scheduler in a while.. how do they stop 100o threads from getting 1000 shots at the scheduler? regards -kamal = Kamal R. Prasad UNIX systems consultant [EMAIL PROTECTED] In theory, there is no difference between theory and practice. In practice, there is:-). __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
truss bug + PATCH, pls review
Can someone review this? I think 'u' is incorrectly added to instead of assigned to. This causes the initial calculation to be garage based and screws up displaying poll information. I'd like this to be MFC'd before 5.4 if possible. Index: syscalls.c === RCS file: /home/ncvs/src/usr.bin/truss/syscalls.c,v retrieving revision 1.45 diff -u -r1.45 syscalls.c --- syscalls.c 5 Sep 2004 05:27:30 - 1.45 +++ syscalls.c 2 Mar 2005 21:19:13 - @@ -414,7 +414,7 @@ (POLLIN | POLLPRI | POLLOUT | POLLERR | POLLHUP | POLLNVAL | \ POLLRDNORM |POLLRDBAND | POLLWRBAND | POLLINIGNEOF) - u += snprintf(tmp + used, per_fd, + u = snprintf(tmp + used, per_fd, %s%d 0x%hx%s%s%s%s%s%s%s%s%s , i 0 ? : , pfd[i].fd, -- - Alfred Perlstein - Research Engineering Development Inc. - email: [EMAIL PROTECTED] cell: 408-480-4684 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FUD about CGD and GBDE
In message [EMAIL PROTECTED], Roland Dowdeswell wri tes: Let's discuss a simple example and see how it works. Let's walk through a user login, with /etc/passwd on GBDE and the filesystem mounted with mtime. These days, on the majority of low cost disks used in enduser configurations you risk looking an entire track if the disk were writing when you pulled power. (People complain about this, but doesn't seem to be willing to pay to avoid it.) So the cummulative increase of risk from using GBDE doesn't really register on the radar for people. And therein lies a very important lesson for you: It may not be a 100% theoretical ironclad guarantee, because few people are prepared to pay for that in the first place. Contemporary filesystems generally do not lose data when a file is read. ... unless they operate on contemporary products for data storage. A dictionary attack refers specifically to the process of guessing passphrases. As I said in so many words: GBDE does not in any way shape or form address this problem. GBDE provides a simple model for authentication on which many different key handing schemes, can be built. There is no problems left in crypto research except key-handling, and I (or anybody else) would be very wrong if we claimed to have the EndlÖsung for that problem. The important feature in this situation is to be able to work with whatever keyhandling scheme the user (or administrator) wants to implement, not to ram our preference down their throat. It is all well and good for both of us to talk about 2^256 and 2^2176 and 2^128 * 2^30, etc. But, a dictionary attack is likely to be a lot closer to 2^35 or 2^40. This is, I think, in the general use case the real threat. It is the low hanging fruit. Yes, absolutely. The difference between CGD and GBDE in this area is that for CGD it is not convincibly shown that it is the only feasible attack (because you use the same key for all sectors thus exposing the ciphers possible weaknesses big time), for GBDE everybody so far agrees that the key is the only feasible attack. With GBDE, the dictionary attack can be performed half offline because the SHA2/512 is not salted. Sure, but if the dictionary includes guessing the 1KB of random bits on my USB gadget, you are more than welcome to do so. If you as a user are worried about dictionary attacks, then you obviously will employ a key handling method which mitigates it. My preference is a storage gadget with a large slap of bits which are one part of the passphrase, other people have other preferences. GBDE supports them all. But there are also users who are rightly not worried about dictionary attacks: People transmitting data via CDroms in envelopes. They ship the bulk of thier data that way (and I mean BULK! in the case I'm thinking about. BofA could learn something here BTW!), but the GBDE key is generated from a PRNG and emailed using PGP. The entire process is automated. With GBDE the keys used to encrypt each of the key-key sectors remain static. So, like CGD there is no effective way to revoke access to the disk from wily and intelligent insiders who at some point had access to the disk, except by re-encrypting the whole thing. With both systems, the `master key' remains static and hence if you can calculate it once you have it. That is a non-problem which GBDE doesn't claim to address: The vily insider is very likely to already have taken a copy of the data he wanted. While we are at it, I do not believe that having a key that is larger than 1024 bits necessarily guarantees that the effort required to crack it is commensurate with its size. That obviously depends on the attack method and direction. E.g. given the bit-blender approach of GBDE [from 7.4 of your paper], if you know the salt then you can use a divide-and-conquer strategy to tease the master key out in a ``reasonably short'' time. Less than 2^128 steps certainly, if I look at things correctly. I don't think you do. 2^128 will give you only one data sector. Then you need 2^128 to bruteforce the key encryption. Then you need 2^128 inverse MD5 operations, however much effort we assign that it is not zero, it will take you at least one clock cycle for each to store the result. By the time you've done that, you know 16 byte values which appear in the master key, but you do not know their indices in the master key There are between (256!/(256-16)!) and 256^16 (= 2^127...2^128) different possibilities for those sixteen indices and you won't know which it is until you know how many, if any, of those 16 values are identical. You may have a detection mechanism for the data sector which allows you to stop as soon as you have a hit, but there is no detection mechanism to let you know when you have a hit for the key encryption (or the MD5 unless MD5^-1 is truly found), so you will be forced to operate with all 2^128 possibilities for the key-key, and spend some effort on the inverse MD5 for all of
Re: sched_4BSD
--- Julian Elischer [EMAIL PROTECTED] wrote: Kamal R. Prasad wrote: --- Lucas Holt [EMAIL PROTECTED] wrote: Wouldn't a multi threaded program potentially need more cpu time than vi? No. That is not a given. Multithreaded apps are created to do a lot of computation or because they have a lot of concurrent activity that might block right? Threads are meant to take advantage of concurrency. Maybe the freebsd implementation should implement NPTL in entirety. NPTL? New Pthreads Library from Library? Yes. isn't that GPL'd? No -it is a standard. The linux implementation of nptl is gpl'ed. regards -kamal = Kamal R. Prasad UNIX systems consultant [EMAIL PROTECTED] In theory, there is no difference between theory and practice. In practice, there is:-). __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
