Re: RFC: backporting GEOM to the 4.x branch
[EMAIL PROTECTED] wrote: This does not work. The problem is that in GBDE for sector n which is written, there are two operations: 1. change the key by which sector n is encrypted, and 2. write sector n ecnrypted with the new key. If one of these fails, how could the write be ignored? If one of the two completes but not both, then one is left in the situation of either: 1. trying to decrypt the old sector with the new encryption key, or No. 2. trying to decrypt the new sector with the old encryption key. Yes, the data sector is written first and then the key sector. Since, as you pointed out, GBDE is more susceptible to dictionary attacks than CGD one can then use this advantage (it's a feature, not a design flaw!) to recover the lost key so no data is lost. :- Seriously, how can one make writing atomic without breaking compatibility with existing GBDE volumes? Which approach does CGD use to solve the problem of atomic writing? How about changing GBDE in a backwards-incompatible way by adding one key shadow sector for every n key sectors (n would be chosen at volume initialization)? The key shadow sector would hold the xor of the last encrypted key in the zone to be replaced and its replacement key, a 32 byte status chunk to indicate the status of the operation: all zeros (0x0) would indicate the new key has not been written to the key sector yet (but it is present in xor-ed form in the key shadow sector), all ones (0xFF) would indicate the new encrypted data sector has been written successfully and random garbage would indicate that both the new key and the encrypted data have been successfully written to disk. Then the relative offset of the key sector from the key shadow sector would follow and then the offset of the key within the key sector. The rest of the sector would also be padded with random garbage which would be regenerated every x writes (this value could be tunable via sysctl, kern.geom.bde.garbage_recycle_freq). The whole write procedure would look something like this: 1. read old key from key sector 2. xor-ed key = new key ^ old key 3. pad xor-ed key with: - status chunk: 32 0x0 characters - relative offset of key sector from key shadow sector (chosen at volume initialization, 8 bytes by default) - relative offset of key within key sector (8 bytes by default) 4. write padded xored key to key shadow sector 5. encrypt data with new key 6. write encrypted data to disk 7. set status chunk in key shadow sector to 0xFF 8. write new key to key sector 9. if (number of key writes % kern.geom.bde.garbage_recycle_freq == 0) then overwrite control chunk in key shadow sector and the rest of sector with random garbage else overwrite only control chunk in key shadow sector with random garbage (not to waste entropy) endif Either way, the sector has been lost. Neither the original contents of the sector nor the new contents can be recovered without breaking AES-128. Fsck(8) does not contain this functionality (and it would be rather impressive if it did.) The solution I proposed always provides consistent atomic writes. If only the encrypted data sector gets written and the key does not get written to the key sector, you can recover the new key by xor-ing the xor-ed key from the key shadow sector with the old key. That way fsck(8) would only need to walk through all the key shadow sectors and check for 0xFF status chunks and recover new keys automatically. Zero control chunks would have to be handled by the user since fsck(8) would have no way of telling whether a zero chunk means the newly encrypted data got written to disk (and the plug was pulled just before the control chunk was to be set to 0xFF) or not (the new key just got written to disk in xor-ed form, but the existing key and data are unchanged). The simplest way would be to let fsck(8) report and record all zero chunks in the form which could be fed to a utility which would set the key directly. The input (output generated by fsck(8)) for such a utility would consist of the device name, relative offset and the key. Both options would always be listed and then the user could try all the alternatives and see which key is the right one. There would be a performance hit, but I would like to see this implemented to see just how big the difference would be. What do you guys think of this solution? 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: RFC: backporting GEOM to the 4.x branch
On 1109628121 seconds since the Beginning of the UNIX epoch ALeine wrote: Yes, the data sector is written first and then the key sector. Since, as you pointed out, GBDE is more susceptible to dictionary attacks than CGD one can then use this advantage (it's a feature, not a design flaw!) to recover the lost key so no data is lost. :- Seriously, how can one make writing atomic without breaking compatibility with existing GBDE volumes? Which approach does CGD use to solve the problem of atomic writing? You would need to maintain some sort of journal. With CGD, I specifically avoided any strategy which tied the write of one sector to the write of another sector for this reason. And so, I use one key to encrypt the disk rather than storing randomly generated keys upon every write. GBDE already explodes a single sector write into two sector writes, which makes its performance quite suboptimal. Adding a journal would make it even worse. I do not think that maintaining a different key for each sector actually provides enough benefit to justify this. How about changing GBDE in a backwards-incompatible way by adding one key shadow sector for every n key sectors (n would be chosen at volume initialization)? The key shadow sector would hold the xor of This is basically implementing a journal. It adds a lot of complexity for IMO very little gain over moving to a simpler solution such as CGD. The whole thing (GBDE) is already pretty brittle, i.e. hard to change without breaking. This would make it more so. And, GBDE is obviously already less secure than a simpler approach such as CGD with AES-256 (which is around twice as fast). Many rather dubious claims have been made about GBDE such as in: http://www.bsdcan.org/2004/papers/gbde.pdf PHK claims that it will take O(2^384) to crack GBDE if the lock sector is destroyed. Perhaps my maths is a little rusty, but it perplexes me how it could possibly take 2^384 steps to individually crack 2^30 sectors that are encrypted with 128 bit AES. That comes out to a [not at all strict] upper bound of 2^158 steps to entirely crack a 512GB disk. So, already it is less secure than CGD using 256 bit AES. But, obviously you'd just crack the ``key-key sectors'' which would knock another 5 bits off. Now, consider that really an attacker doesn't really care about the whole disk. By chasing directory structures, etc., they could find what they wanted in very little more than O(2^128). So, what's the point of all of the gymnastics... a few bits. 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. I do not believe that it has had an appropriate amount of peer review to be considered trustworthy, and I have seen some pretty obvious weaknesses that I've been meaning to write up but haven't quite found the time that would knock a few more bits off. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ ___ 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
Hi, How does Linux handle this ? Any idea ? Thanks, Sarat On Mon, 28 Feb 2005 00:26:10 -0800, Julian Elischer [EMAIL PROTECTED] wrote: Ashwin Chandra wrote: I wanted to get some clarification about the 4BSD scheduler. I am sort of confused why there are two forms of scheduling, one done between processes and another done between threads in a process. The priority calculations seem to be done only with processes and I assume that the global run queue holds processes, not threads. Also why is there only 1 run queue for 1 CPU. What happens to blocked processes and ready to be runned processes? Part of the challenge of adding threads to a system is to make it hard for a threaded process to flood the system run queues so that other processes get no cpu time. The scheme in the current freeBSD schedulers is a crude method, by which only a limitted number of threads per process are allowed to be added to the system run queue. RUnnable hreads fo r aprocess are kept on a run queue for the process and only the highest N prioriy hreads are actually put on the system run queue. This is by no means the best way, but rather the easiest way. I am hoping that some PhD candidate somewhere will decide that thread scheduling is his topic and will figure out a better way of doing this. both run queues hold threads. This is still a place wjere a lot of work can be done. :-) Ash ___ 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] ___ 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
Sarath Kamisetty wrote: Hi, How does Linux handle this ? Any idea ? 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? Thanks, Sarat On Mon, 28 Feb 2005 00:26:10 -0800, Julian Elischer [EMAIL PROTECTED] wrote: Ashwin Chandra wrote: I wanted to get some clarification about the 4BSD scheduler. I am sort of confused why there are two forms of scheduling, one done between processes and another done between threads in a process. The priority calculations seem to be done only with processes and I assume that the global run queue holds processes, not threads. Also why is there only 1 run queue for 1 CPU. What happens to blocked processes and ready to be runned processes? Part of the challenge of adding threads to a system is to make it hard for a threaded process to flood the system run queues so that other processes get no cpu time. The scheme in the current freeBSD schedulers is a crude method, by which only a limitted number of threads per process are allowed to be added to the system run queue. RUnnable hreads fo r aprocess are kept on a run queue for the process and only the highest N prioriy hreads are actually put on the system run queue. This is by no means the best way, but rather the easiest way. I am hoping that some PhD candidate somewhere will decide that thread scheduling is his topic and will figure out a better way of doing this. both run queues hold threads. This is still a place wjere a lot of work can be done. :-) Ash ___ 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] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
smbfs install option for sysinstall
I modified the installer a while back to be able to install from a smb share. http://futurebsd.sourceforge.net/freebsd/smbfs/ It needs a little work though. I'm looking for some feedback although I have tested it recently. I have done a recent install from a Windows XP machine joined to a domain using a share that required domain admin credentials. Here are a couple of issues that should be fixed. 1. I am not sure how to get the smbfs kernel support into the installer without also putting it into the GENERIC kernel of the release. 2. If a user uses is prompted for a password, then the output will make sysinstall look kinda funny, although the user can enter the password properly. There is probably a way to intercept the stdin and stdout of mount_smbfs and have it display in a menu? This should work similar to the root password change option? 3. This may add too much space to the floppy installer? 4. The English used in the menus could be better. Regards, David Yeske __ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
retricted environment
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. ___ 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 Tuesday 01 March 2005 21:22, 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. I am not sure a restricted shell is the best sollution for interactive setups, but one is availale from src/contrib/sendmail/smrsh. See README for usage and build information. This, however, is more a thing for cvs-wrappers or stuff like that. For interactive environments you can use the normal group/user permissions and of course jail(8)s. -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgp9qqWd70yjS.pgp Description: PGP signature
Re: TDF_NEEDRESCHED when extending pcb on x86
On Monday 28 February 2005 07:06 pm, Peter Wemm wrote:
On Monday 28 February 2005 02:57 pm, Denis Ustimenko wrote:
Hi, there!
I've tried s3switch utility from ports on 5.2.1 and found that
i386_set_ioperm syscall doesn't work properly. The next code illustrates
the problem. It will get SIGBUS with very high probability.
#include sys/types.h
#include machine/sysarch.h
#include machine/cpufunc.h
int main()
{
if ( i386_set_ioperm( 0x80, 1, 1)) {
perror(XXX);
return 1;
}
inb( 0x80);
return 0;
}
Now I have no 5.3 or CURRENT system but brief looking on code shows that
it should give the same result on them.
The problem occurs when we extend pcb and set TDF_NEEDRESCHED bit hoping
that thread will be rescheduled and new TSS will be loaded. But
sched_switch function skips cpu_switch when thread was not changed and
ltr is not executed.
I think it would be better to fix the semantics of TDF_NEEDRESCHED. I was
thinking that mi_switch could negate the cpu_switch optimization if
TDF_NEEDRESCHED was set. That would avoid duplicating the internal
knowledge of the pcb/tss/etc handling in this code.
Forcing a context switch is a rather round-about way of getting ltr to be
executed though. We already have intimate knowledge of TSS, etc. in this
file anyway, so I wonder if just doing the ltr() directly is the better
approach?
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve = http://www.FreeBSD.org
___
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
Max Laier wrote: On Tuesday 01 March 2005 21:22, 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. I am not sure a restricted shell is the best sollution for interactive setups, but one is availale from src/contrib/sendmail/smrsh. See README for usage and build information. This, however, is more a thing for cvs-wrappers or stuff like that. For interactive environments you can use the normal group/user permissions and of course jail(8)s. Thanks, I'll look at that. To allow retricted access using groups/users, is the normal procedure to remote o+rwx permissions from the selected commands/directories? Hmm. I thought the kernel secure level setting which helped restrict users. I've much to learn. ___ 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
Julian Elischer wrote: Sarath Kamisetty wrote: Hi, How does Linux handle this ? Any idea ? 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? And how is that different from forking 1000 processes and use shared memory to communicate? I'll tell you: the thread option will be better for every user in that machine, so let's promote threads. IMHO, a thread should have the same privilege as a full processes, and it should count as a process for resource limits. Thanks, Sarat On Mon, 28 Feb 2005 00:26:10 -0800, Julian Elischer [EMAIL PROTECTED] wrote: Ashwin Chandra wrote: I wanted to get some clarification about the 4BSD scheduler. I am sort of confused why there are two forms of scheduling, one done between processes and another done between threads in a process. The priority calculations seem to be done only with processes and I assume that the global run queue holds processes, not threads. Also why is there only 1 run queue for 1 CPU. What happens to blocked processes and ready to be runned processes? Part of the challenge of adding threads to a system is to make it hard for a threaded process to flood the system run queues so that other processes get no cpu time. The scheme in the current freeBSD schedulers is a crude method, by which only a limitted number of threads per process are allowed to be added to the system run queue. RUnnable hreads fo r aprocess are kept on a run queue for the process and only the highest N prioriy hreads are actually put on the system run queue. This is by no means the best way, but rather the easiest way. I am hoping that some PhD candidate somewhere will decide that thread scheduling is his topic and will figure out a better way of doing this. both run queues hold threads. This is still a place wjere a lot of work can be done. :-) Ash ___ 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] ___ 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]
Re: RFC: backporting GEOM to the 4.x branch
[EMAIL PROTECTED] wrote: You would need to maintain some sort of journal. With CGD, I specifically avoided any strategy which tied the write of one sector to the write of another sector for this reason. And so, I use one key to encrypt the disk rather than storing randomly generated keys upon every write. GBDE already explodes a single sector write into two sector writes, which makes its performance quite suboptimal. Adding a journal would make it even worse. I do not think that maintaining a different key for each sector actually provides enough benefit to justify this. 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. This is basically implementing a journal. It adds a lot of complexity for IMO very little gain over moving to a simpler solution such as CGD. The whole thing (GBDE) is already pretty brittle, i.e. hard to change without breaking. This would make it more so. Well, it does not need to be very complex and I am more interested in getting this kind of functionality in 4.x, so I think that porting GBDE would be more work than writing my own implementation from scratch and just using the same principles, only adapted and implemented in a way to suit my ideas and needs. And, GBDE is obviously already less secure than a simpler approach such as CGD with AES-256 (which is around twice as fast). I believe it is not less secure because eventhough it might require less steps to brute force a sensitive part of the filesystem (some directory structure), the impact is completely localized and can't be used to leverage a wider compromise, while that is not the case with CGD. As I said, I believe the speed of GBDE could be greatly improved by implementing my ideas, but AFAIK there seems to be very little you can do to improve the speed of CGD beyond how fast it is now because it is already using the most simple approach and any additional optimization attempts would only increase the complexity, which is something you seem to want to avoid at all cost. Many rather dubious claims have been made about GBDE such as in: http://www.bsdcan.org/2004/papers/gbde.pdf PHK claims that it will take O(2^384) to crack GBDE if the lock sector is destroyed. Perhaps my maths is a little rusty, but it perplexes me how it could possibly take 2^384 steps to individually crack 2^30 sectors that are encrypted with 128 bit AES. That comes out to a [not at all strict] upper bound of 2^158 steps to entirely crack a 512GB disk. So, already it is less secure than CGD using 256 bit AES.But, obviously you'd just crack the ``key-key sectors'' which would knock another 5 bits off. Now, consider that really an attacker doesn't really care about the whole disk. By chasing directory structures, etc., they could find what they wanted in very little more than O(2^128). So, what's the point of all of the gymnastics... a few bits. I believe PHK's calculations are based on the fact that even if you want to brute force a GBDE volume, you have to assume it's encrypted using GBDE and then try to break the structured multilayered mechanism, because otherwise you can only hope to brute force a very minimal part of the disk that would do you no good in leveraging that knowledge to break the encryption of the rest of the disk. 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. I do not believe that it has had an appropriate amount of peer review to be considered trustworthy, and I have seen some pretty obvious weaknesses that I've been meaning to write up but haven't quite found the time that would knock a few more bits off. I believe PHK is well aware of the threats, he even commented on them in the code itself and his papers, his choice of SHA2/512, for example, shows that he is planning for those advances that pose a threat. I am sure there is room for a lot of improvement in GBDE and eventhough not that many reputable cryptographers have reviewed GBDE so far, those who have are very well respected, like Lucky Green, for example. I hope you will find the time to write an
Re: TDF_NEEDRESCHED when extending pcb on x86
John Baldwin wrote: On Monday 28 February 2005 07:06 pm, Peter Wemm wrote: On Monday 28 February 2005 02:57 pm, Denis Ustimenko wrote: The problem occurs when we extend pcb and set TDF_NEEDRESCHED bit hoping that thread will be rescheduled and new TSS will be loaded. But sched_switch function skips cpu_switch when thread was not changed and ltr is not executed. I think it would be better to fix the semantics of TDF_NEEDRESCHED. I was thinking that mi_switch could negate the cpu_switch optimization if TDF_NEEDRESCHED was set. That would avoid duplicating the internal knowledge of the pcb/tss/etc handling in this code. Forcing a context switch is a rather round-about way of getting ltr to be executed though. We already have intimate knowledge of TSS, etc. in this file anyway, so I wonder if just doing the ltr() directly is the better approach? Yes, John, I think it's better to load TR directly. Usage of TDF_NEEDRESCHED for loading TR is the only platform specific resort of this bit, so elimination of it makes design more clear and we do not need drop out cpu_switch optimization. -- Best regards Denis ___ 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
[EMAIL PROTECTED] wrote: 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. Thank you for taking the time to write that insightful post, I have read a number of your books and let me say it's an honour to hear your comments on this. :-) Regarding the threat model - imagine an attacker sending you a number of large ( 128kb), specially crafted emails and then getting hold of your CGD encrypted disk with those emails stored on that encrypted disk. Let's also assume the attacker would be roughly familiar with the disk layout on your computer and could locate the 4 Mb block on the disk inside which his emails are located. This would make CGD an easier target to a kind of known plaintext attack than if the emails were stored in chunks encrypted with different keys, as that is the case with GBDE. Algebraic attacks on AES show that AES may indeed be broken sooner than we would hope, at least according to the information at: http://www.cryptosystem.net/aes/ quote In a recent paper (Asiacrypt 2002), Nicolas Courtois and Josef Pieprzyk show that Rijndael can be written as an overdefined system of multivariate quadratic equations (MQ). For example authors show that for 128-bit Rijndael, the problem of recovering the secret key from one single plaintext can be written as a system of 8000 quadratic equations with 1600 binary unknowns. Thus the security of Rijndael requires that there are no efficient algorithms for solving such systems. In a paper published at Eurocrypt 2000 Shamir et al. describe an algorithm called XL (or/and FXL) able to solve efficiently many such systems of equations. Attacking AES/Rijndael by such a method requires only a few known plaintexts to succeed. If this method can be made to work in practice, it is a major revolution in cryptanalysis: all classical attacks on block ciphers such as linear/differential and other approximation attacks require a number of plaintexts that is very big and grows exponentially in the number of rounds. In practice the algorithm XL fails (quite miserably) to break Rijndael. However the system obtained from Rijndael is not random, and has many special properties: it is overdefined, sparse and very structured. From this, in a recent paper, Nicolas Courtois and Josef Pieprzyk investigate how to improve XL and adapt it to such special systems. They propose a new class of attacks, attack, called XSL attacks. There is no doubt that attacks such as XL and XSL do work in many interesting cases. Unfortunately they are heuristic, and their behaviour is not well understood. There are examples where these or similar attacks do behave in practice as it is predicted, and there are examples where they don't. This is how the security of AES became a hot topic. /quote 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. That is roughly what I had in mind. 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. Agreed, the user-specified key would be used to encrypt keys
Re: RFC: backporting GEOM to the 4.x branch
On 1109641515 seconds since the Beginning of the UNIX epoch ALeine wrote: And, GBDE is obviously already less secure than a simpler approach such as CGD with AES-256 (which is around twice as fast). I believe it is not less secure because eventhough it might require less steps to brute force a sensitive part of the filesystem (some directory structure), the impact is completely localized and can't be used to leverage a wider compromise, while that is not the case But, I said that it requires less steps to brute force the entire disk not just some parts of the filesystem. Every last sector of a 512GB disk can be brute forced in 2^158 steps using the most naive method. All of the key-key sectors can be brute forced in 2^153 steps. This is much less than 2^256 which is what it would take to brute force 256 bit AES. So, until someone can crack 256 bit AES in (2^25 * O(AES128)) steps, yes it is less secure. Or, one should say 256 bit AES with a lot of known plaintext in less than 2^25 * O(AES128). with CGD. As I said, I believe the speed of GBDE could be greatly improved by implementing my ideas, but AFAIK there seems to be very little you can do to improve the speed of CGD beyond how fast it is now because it is already using the most simple approach and any additional optimization attempts would only increase the complexity, which is something you seem to want to avoid at all cost. I am not against adding complexity, just against adding needless complexity which has every appearance of introducing new methods of attacking the disk without appreciably increasing the cost of brute forcing it. CGD does contain a reasonable amount of complexity in some areas: 1. it has a modular mechanism for defining crypto algorithms, these do not need to be restricted to AES vs DES but could include things like ``GBDE'', 2. it takes care to turn passphrases into keys properly, and 3. it allows for the addition of new mechanisms to do (2). 4. etc. But, I also believe that one should solve first things first. That's why I put most of my effort into defeating dictionary attacks and making the sytem modular, etc. There is no point in worrying about what happens if someone breaks AES next year if you are putting out a system this year which can be compromised in months with a dictionary attack. Focus on the weakest links first and right now AES is not the weakest link. There is little point in replacing your front door with a steel reinforced door if all of your windows are open. I believe PHK's calculations are based on the fact that even if you want to brute force a GBDE volume, you have to assume it's encrypted using GBDE and then try to break the structured multilayered mechanism, because otherwise you can only hope to brute force a very minimal part of the disk that would do you no good in leveraging that knowledge to break the encryption of the rest of the disk. But, you do not have to break the structured multilayered mechanism at all. You can just brute force each sector one by one in much less than 2^384 steps and hence the claim is both trivially and obviously false. Or just crack one key-key sector in 2^128, reverse the MD5 in 2^128 to obtain the salt and get the rest of the disk in 2^128, for a grand total of O(2^129). Together these methods seem to indicate that 2^384 is a little exaggerated. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ ___ 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
On 1109715311 seconds since the Beginning of the UNIX epoch Steven M. Bellovin wrote: 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 I thought about this a little when I was writing CGD and decided that since it would involve changing the block size or updating multiple blocks when one block was modified that it would be handled much better at the file system layer than at the disk layer. E.g. right now LFS uses a checksum to determine if a segment write has fully completed upon recovery from a crash. It would be easy to modify that checksum into an HMAC. That would provide integrity protection almost for free. If we did it at the disk level, then we would be in the game of trying to make 2 disk writes appear atomic which would be a serious performance problem. On the other hand Thor Lancelot Simon made an interesting suggestion recently, which was one could reformat the underlying disk to have 522 byte blocks but have CGD present 512 byte blocks to the layers above it and still maintain the appropriate atomicity while gaining a 160 bit HMAC for each block. I think that the integrity checking has a more limited threat model, namely only removable media (for NetBSD, at least). If someone is able to steal my laptop and return it, they could just bug the keyboard much more quickly than figure out how to change my encrypted partitions in a non-obvious way. Or they could circumvent the boot blocks, reflash the BIOS, etc. etc. So, I think that this only matters for media which is more likely to pass out of my direct control than my laptop---or as in the article NAS/SAN architectures, where the storage is not nec. coresident with the computer. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ ___ 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
João Carlos Mendes Luís wrote: Julian Elischer wrote: Sarath Kamisetty wrote: Hi, How does Linux handle this ? Any idea ? 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? And how is that different from forking 1000 processes and use shared memory to communicate? I'll tell you: the thread option will be better for every user in that machine, so let's promote threads. It's not different, but in that schenario there is no way the programmer can AVOID being nasty. with process scope threads as mentioned before the process itself is limitted so that iti doesn't unfairly peanalise other users for not using threads. IMHO, a thread should have the same privilege as a full processes, and it should count as a process for resource limits. Thanks, Sarat On Mon, 28 Feb 2005 00:26:10 -0800, Julian Elischer [EMAIL PROTECTED] wrote: Ashwin Chandra wrote: I wanted to get some clarification about the 4BSD scheduler. I am sort of confused why there are two forms of scheduling, one done between processes and another done between threads in a process. The priority calculations seem to be done only with processes and I assume that the global run queue holds processes, not threads. Also why is there only 1 run queue for 1 CPU. What happens to blocked processes and ready to be runned processes? Part of the challenge of adding threads to a system is to make it hard for a threaded process to flood the system run queues so that other processes get no cpu time. The scheme in the current freeBSD schedulers is a crude method, by which only a limitted number of threads per process are allowed to be added to the system run queue. RUnnable hreads fo r aprocess are kept on a run queue for the process and only the highest N prioriy hreads are actually put on the system run queue. This is by no means the best way, but rather the easiest way. I am hoping that some PhD candidate somewhere will decide that thread scheduling is his topic and will figure out a better way of doing this. both run queues hold threads. This is still a place wjere a lot of work can be done. :-) Ash ___ 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] ___ 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] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: smbfs install option for sysinstall
David Yeske wrote: I modified the installer a while back to be able to install from a smb share. It needs a little work though. I'm looking for some feedback although I have tested it recently. I have done a recent install from a Windows XP machine joined to a domain using a share that had domain admin credentials. http://futurebsd.sourceforge.net/freebsd/smbfs/ Here are a couple of issues that should be fixed. 1. I am not sure how to get the smbfs kernel support into the installer without also putting it into the GENERIC kernel of the release. Probably not a big deal, unless it presents a security risk by default. I don't know enough about smbfs to say. 2. If a user uses is prompted for a password, then the output will make sysinstall look kinda funny, although the user can enter the password properly. There is probably a way to intercept the stdin and stdout of mount_smbfs and have it display in a menu? This should work similar to the root password change option? Probably easiest to do it this way. Sysinstall isn't pretty, but making it uglier with misformatted dialogs isn't good either. 3. This may add too much space to the floppy installer? No longer a problem now that the splitfs support is in. 4. The English used in the menus could be better. Regards, David Yeske Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
