init troubles with custom install
Hello. I have been endeavoring to create my own livecd which will mount a remote share from which to run scripts installing a ghost image onto a local hard drive. I realize this may be more trouble than it's worth, but I am doing it to easily assimilate new machines into a Beowulf cluster... so I think it is. I have done everything I can think of to do this properly: 1) I used the process defined in the bsdlabel man page for setting up the slices/partitions/labels/etc. (search for dd in the man page) 2) I extracted the ghost images, in the form of tarballs, to the /, /usr, and /var slices. There is a partition for /tmp, but empty. I also setup a 1Gb swap slice. These slices are setup to mirror how they would be if I were to use the standard fbsd install cd. Now, here's the problem.. the kernel loads, and I start getting a list of the devices it detects, and it reaches the point of 'Mounting root from ufs:ad0s1a', then locks up. Either init is not being called, or is stalling somewhere. I have disabled pnp in my BIOS settings, and I have a single 16G IDE hard disk to which these operations are being performed. I have tried the various options in the boot menu (single user, safe mode, verbose logging, etc.) and the only useful information I get is when in verbose logging mode, it reaches the halt point, and additionally says: start_init: trying /sbin/init then halts. Could anyone shed some light on this for me? I can provide whatever additional information may be necessary. Thanks! William ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: truss bug + PATCH, pls review
On Thu, 2005-03-03 at 07:32 -0700, Scott Long wrote: Alfred Perlstein wrote: 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, While you're on the subject of Trussburger, perhaps someone can comment on this Problem Report Meal. A McPatch is included. http://www.freebsd.org/cgi/query-pr.cgi?pr=71749 PS. It really is a McPatch. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
FW:FreeBSD hiding security stuff
Whats the intention behind the FreeBSD developers policy? -- Weitergeleitete Nachricht Von: Theo de Raadt [EMAIL PROTECTED] Datum: Fri, 04 Mar 2005 03:51:42 -0700 An: [EMAIL PROTECTED] Betreff: FreeBSD hiding security stuff A few FreeBSD developers apparently have found some security issue of some sort affecting i386 operating systems in some cases. They have refused to give us real details. A promise is now being made. If a bug is found in OpenSSH, which we believe to have security consequences, we wil inform FreeBSD last. Fair is fair. I really wish it was not this way, but after a week of trying to get the policy to be fixed, we are changing our policy as well. Without immediate action from them to repair their polcy, and a public apology for this, that policy will stand. -- Ende der weitergeleiteten Nachricht ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FW:FreeBSD hiding security stuff
[I'm adding a CC: to freebsd-security, since I'm sure this thread will get reposted there if I don't. For those not subscribed to -hackers: Jonathan forwarded the an email Theo wrote to openbsd-misc: http://marc.theaimsgroup.com/?l=openbsd-miscm=110993373705509w=2 ] Jonathan Weiss wrote: Whats the intention behind the FreeBSD developers policy? Quoting from secteam's TODO list for advisories: 1. Check if security officers need to be contacted at OpenBSD, NetBSD, OS X, or DragonFlyBSD. Yes, that's item #1 on our list. :-) In this case, I wasn't sure if OpenBSD was affected, so I emailed Theo asking for certain details which would allow me to make this determination. Theo wrote: A few FreeBSD developers apparently have found some security issue of some sort affecting i386 operating systems in some cases. s/A few FreeBSD developers/One FreeBSD developer/ I discovered this issue in December; until a few days ago I was working on it to determine whether it could be exploited. They have refused to give us real details. Theo, in one of several replies, indicated that I should provide the details to Ted Unangst (tedu@). I contacted Ted and provided him with the details; he agreed with me about how and when it should be handled by OpenBSD. A promise is now being made. If a bug is found in OpenSSH, which we believe to have security consequences, we wil inform FreeBSD last. Fair is fair. I really wish it was not this way, but after a week of trying to get the policy to be fixed, we are changing our policy as well. Without immediate action from them to repair their polcy, and a public apology for this, that policy will stand. The policy of the FreeBSD security team is to notify other vendors and work with them to co-ordinate a disclosure schedule. It is also the policy of the FreeBSD security team to avoid disclosing security issues to anyone who does not need to know about them (i.e., anyone other than other affected vendors, admins@, and in some cases re@). I will make no apology for either of these, and I doubt anyone else (either from the security team, or the security officer himself) will do so either. Colin Percival ___ 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], Perry E. Metzger writes: The best I can say, however, is that the US government has approved the use of AES with 256 bit keys for very highly secure communications, and they have a very demanding user community. (There is a big difference in what crypto you need for communications, storage, and archiving.) My philosophy in this, (as implemented in GBDE), is to trust the algorithms to do their job, but to not offer an attacker any more leverage against them than I absolutely have to. It has been said by various people that there are [currently] no cause to think that using the same key for many millions of sectors is a problem. I belive that is a fair and balanced summary, and I trust the people to know what they talk about and I belive them. Nontheless, I do not consider it good engineering to expose the algorithm to unnecessary stress, even if we currently belive we have a 220 bits margin of safety, if by trivial means, I can avoid that stress on the algorithm and maintain 256 bits of margin. Exactly where the line is between overkill and conservative engineering is always subject to individual preference and taste. I don't seriously think that either of CGD or GBDE will be broken through any other path than guessing or otherwise obtaining the passphrase. But in the case something unforeseen happens, I know that GBDE will yield its secrets only one sector at a time and CGD will spill all the eggs at once because it has only one basket. (Hans Christian Andersen wrote quite amuzingly about this 150 years ago in the story The woman with the eggs.) As for making user selectable ciphers and keysizes I decided against it for two reasons. The first reason is that it adds complexity. The second is that it offers complexity. Adding complexity in the implementation is wrong for all the reasons we all agree on. To justify that complexity, a benefit must be proven. In all my interviews and talks with people, I found nobody who wanted that level of flexibility. Everybody, almost in unison sang from the AES is the annointed king and 128 bit is the his key size. hymn. That surprised me initially. It transpired that people had a very simple and prosaic reasoning: Anything else will give us footnotes during audits. Different ciphers will make the auditor write the standard AES should have been used even if the cipher used is agreed by everybody to be stronger. A longer keylength will result in a note about unneccessary overkill and waste of resources. The other complexity is for the user. The more questions the user has to determine the correct answer to, the less likely he is to get it all right if he is not a subject matter specialist. My favourite question from a UNIX installer was something like: Do you want this system configured according the the regulations set forth in [45 character of legal reference] ? [yes/no] _ And as you can guess, it didn't even offer a default to hint what one should choose. (As it later transpired, the option would disable the support for a locally connected printer.) Offering options in a situation where users will generally not dare using anything but the default is not only quite pointless, it is down right detrimal to user experience, and, probably, security. It used to be that I, as a UNIX wizard of some renown, knew what happened when a user logged into a FreeBSD box. But today, between ssh, opie, PAM, access.conf and what else gets in the way, I have to say that unless all settings are the default, it will take me considerable time to determine that no holes have been opened. I fully agree that we have gained fantastic flexibility through all these features, but I am not always convinced that they are a net improvement of security when measured over the set of all FreeBSD machines in the world. So I made the choice to structure the source code and the crypto path so that other algorithms could be slotted in by any minimally competent programmer, and stuck to the choice of algorithm which seems to be the king of the hill these days. If the wind or the king changes, the source code will adapt in less than a day. Finally, on keying schemes: I didn't put a keying scheme on GBDE because I belive in the tools not policies dogma. The gbde(8) userland program should be (but isn't quite) flexible enough to support any keying scheme people decide to use. And I also belive in the many hands make light work, so I sort of hoped that people who knew more about public key crypto than me would produce scripts or frontends which implement sound keying schemes for GBDE based on these technologies. Poul-Henning PS: Will you be at BSDcan ? It would be a good chance to corner a whiteboard and some beer. -- 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
Re: FUD about CGD and GBDE
In message [EMAIL PROTECTED], Jari Ruusu writes: Early versions of loop-AES were FUBARed, true. But why do you insist on ranting about fuckups that were fixed long time ago? I don't :-) The topic at hand was why I made certain choices for GBDE the way I did, what loop-AES did subsequent to that time is not really relevant. -- 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: FUD about CGD and GBDE
On Thu, Mar 03, 2005 at 05:58:49PM -0500, Roland Dowdeswell wrote:
Disklabels for example have a checksum. The checksum might not be
terribly strong, but the chance that two different valid disklabels
could even be decrypted with different keys is small, I would
imagine. The checksum takes off 2^32 seemingly valid disklabels
and what about the rest of the fields? There's lots of redundant
information in there that could be cross referenced.
Actually this is the argument from PHK which I consider bogus and
which makes the claims about the secure of GBDE bogus as well.
I do believe that GBDE is stronger than CGD when both use the same
algorithms, simple because there is more work to extract the
interesting data from GBDE (more keys to crack).
The whole argument of PHK why GBDE is so much stronger is based on the estimated
number of collisions in the detection of likely good plain texts. As you
mentioned, certain key structures of the disc indeed have a very high
structure. As far as I know, tests for the distribution of the inverse
encryption [ AES^{-1}{key} data ] are not very common, with the exception
of known or choosen plaintext where input and output are known.
IMO it would be a potential attack verctor as well, if you have a large
number of such collisions, since that would mean the structure of the input
is reflected in the structure of the output.
Just to start with the claim of 2^384 (as random number) for a brute
force attack and an average number of 17 sectors to decode until
getting to the interesting data, we get sqrt^{17}{2^256} ~= 34131
collisions. Without a backing theory, I don't trust that number at all.
I have no reason to believe that any but the correct key passes the
test for a super block or whatever data structure there is. Not for a
key length of 128 bit (or 256 bit for that matter). Situation changes
with higher key length of course.
Joerg
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FW:FreeBSD hiding security stuff
It's Theo, he's a drama queen. Probably best not to feed the troll. --Peter Jonathan Weiss wrote: Whats the intention behind the FreeBSD developers policy? -- Weitergeleitete Nachricht Von: Theo de Raadt [EMAIL PROTECTED] Datum: Fri, 04 Mar 2005 03:51:42 -0700 An: [EMAIL PROTECTED] Betreff: FreeBSD hiding security stuff A few FreeBSD developers apparently have found some security issue of some sort affecting i386 operating systems in some cases. They have refused to give us real details. A promise is now being made. If a bug is found in OpenSSH, which we believe to have security consequences, we wil inform FreeBSD last. Fair is fair. I really wish it was not this way, but after a week of trying to get the policy to be fixed, we are changing our policy as well. Without immediate action from them to repair their polcy, and a public apology for this, that policy will stand. -- Ende der weitergeleiteten Nachricht ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
sched_ule, runqueues, priority, and O(1) sheduling question
Hi folks. I wander how O(1) sheduling works in ULE. In ule.pdf Jeff wrote: Threads are picked from the current queue in priority order until the current queue is empty. As far as I understand the algorithm is O(n) where n - number of READY TO RUN processes, not all processes isn't it? thanks, Andriy. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
generic network protocols parser ?
Hi all, I am wondering if any one knows about a generic parser which takes a packet (mbuf) of a certain protocol (e.g RSVP ) as input and generates some data structre representing the packet ? I've been searching for a while and found that ethereal and tcpdump for example use specific data structres and functions to dissect each protocol packets. Is this the only approach possible ? My supervisor suggested using a TLV (Type/Length/Value) approach instead. Any opinions about that? If no such a parser exists is there any practical reason why ? Thanks, Aziz ___ 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 Thu, Mar 03, 2005 at 01:18:45PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bernd Walter writes: No matter what disk you take - writes never have been atomic. The major difference I see is that you get a read error back in the disk failure case, while such a crypto failure produces more or less random data without any error. Mounting unclean filesystems rw for bg_fsck can be considered dangerous with such unexpected data corruption. And how would you know that a restore from backup is required for a damaged file? 100% true. The trouble is that it would cost a lot in performance and a doubling in metadata to protect yourself against this. No, it would not. What it _would_ take would be an abandonment of the adamant position that your home-grown cryptosystem is superior to simply encrypting the disk with 256-bit AES. After all, cgd doesn't diminish the atomicity of writes; it's only your key-key blocks that create this problem. Generally, complexity is not considered a desirable property in cryptosystems. GBDE violates this rule in spades. There are _reasons_ why complexity is not good: to begin with, a very complex cryptographic construct will require detailed analysis (which it does not appear GBDE has had by anyone but its author until Roland started looking at it) in order that we may know that it is even as secure as the underlying algorithmic building blocks it uses. Furthermore, with a very complex cryptographic construct it is easy to persuade oneself that the complexity actually has security benefits which it does not, and thus go forth into the dangerous world unprotected from _other_ attacks that one overconfidently ignores. I'd say that is certainly going on here as well (e.g. the continual minimization of how GBDE's implementation makes dictionary attacks easier). I have often observed the phenomenon that engineers who build extremely complicated software systems insist vigorously that, due to their very complexity (or perhaps due to the amount of time they've spent building them) they _must_ be better than simpler systems that are easier to implement and maintain. One might characterize this as the love of one's own big ideas. The best antidote to this is to ask not do I believe that all this complexity could plausibly have some benefit but rather is there some shortcoming in the simple system that could plausibly justify all this complexity; in other words, to begin from the assumption that complexity is bad. In the case of CGD and GBDE I think the answer is plainly no, there is not. To believe that I wanted something better, I'd essentially have to believe that AES256 were vulnerable to, at best, a chosen- plaintext attack. The key derivation is solid (and standard); the encryption is solid (and standard); and it is a strong point in the system's favor that it does not _try_ to give me more than I want from it. Compare to GBDE, where a massively complicated construct using double-encryption -- and MD5! -- is used to splat keys all over the disk but no attention is paid to key derivation at all. That this conversation has degenerated to the point that GBDE's proponents are claiming that it _would be_ more secure _if_ only someone knew how to break 256-bit AES is to me a pretty good indicator of why GBDE is not encryption software that I want to use. -- Thor Lancelot Simon [EMAIL PROTECTED] The inconsistency is startling, though admittedly, if consistency is to be abandoned or transcended, there is no problem.- Noam Chomsky ___ 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 Thu, Mar 03, 2005 at 05:31:34PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], ALeine writes: Not necessarily, if one were to implement the ideas I proposed I believe the performance could be kept at the same level as now. I gave up on journalling myself because IMO it complicates things a lot and the problem it solves is very very small. The impact in disk seeks is non-trivial to predict, but it is very hard to argue that it will not lead to an increase in disk seeks. (This is really a variant of the age old argument between jounaling filesystems and traditional filesystems) I can only recommend that you try :-) We need more ideas and more people trying out ideas. I could not disagree more. When it comes to nonstandard homebrewed cryptosystems foisted off on unsuspecting users with a bundle of claims of algorithm strength that they're not competent to evaluate for themselves, we do not need more ideas, nor more people trying out ideas; we need less. Standard, widely analyzed cryptographic algorithms are good. -- Thor Lancelot Simon [EMAIL PROTECTED] The inconsistency is startling, though admittedly, if consistency is to be abandoned or transcended, there is no problem.- Noam Chomsky ___ 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], Thor Lancelot Simon writes: On Thu, Mar 03, 2005 at 05:31:34PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], ALeine writes: Not necessarily, if one were to implement the ideas I proposed I believe the performance could be kept at the same level as now. I gave up on journalling myself because IMO it complicates things a lot and the problem it solves is very very small. The impact in disk seeks is non-trivial to predict, but it is very hard to argue that it will not lead to an increase in disk seeks. (This is really a variant of the age old argument between jounaling filesystems and traditional filesystems) I can only recommend that you try :-) We need more ideas and more people trying out ideas. I could not disagree more. When it comes to nonstandard homebrewed cryptosystems foisted off on unsuspecting users with a bundle of claims of algorithm strength that they're not competent to evaluate for themselves, we do not need more ideas, nor more people trying out ideas; we need less. Standard, widely analyzed cryptographic algorithms are good. What Thor said. It's instructive to quote from Vol. 2 of Knuth: With all the precautions taken in Algorithm K, doesn't it seem plausible that it would produce at least an infinite supply of unbelievably random numbers? No! In fact, when this algorithm was first put onto a computer, it almost immediately converged to the 10-digit value 6065038420, which---by extraordinary coincidence---is transformed into itself by the algorithm (see Table 1). With another starting number, the sequence began to repeat after 7401 values, in a cyclic period of length 3178. The moral to this story is that *random numbers should not be generated with a method chosen at random*. Some theory should be used. And Knuth was talking about a situation without an adversary. I don't claim that there's a flaw. I do assert that that I haven't seen a threat model that would justify extra complexity. Let me go one step further. The cryptographic literature is full of examples of broken protocols. My favorite is the flaw in the original Needham-Schroeder protocol, from 1978, that went unnoticed until 1996, when an automated tool found it. I should add that once pointed out, the flaw is blindingly obvious -- but it went unnoticed for 18 years, in the oldest protocol in the open literature. Btw, in modern terms this protocol is 3 lines long. One more quote, this time a remarkably prescient one from that Needham and Schroeder: Finally, protocols such as those developed here are prone to extremely subtle errors that are unlikely to be detected in normal operation. The need for techniques to verify the correctness of such protocols is great, and we encourage those interested in such problems to consider this area. ___ 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 Thu, Mar 03, 2005 at 06:48:51PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Steven M. Bellovin writes: And Knuth was talking about a situation without an adversary. If the component (well respected etc etc) algorithms I have used in GBDE contains flaws so that they become individually less intrinsicly safe because their input is the output of another such algorithm, then the crypto-world has problems they need to work on. The algorithms in question are evaluated _for a particular purpose_. It is absurd to claim that because those algorithms are generally considered suitable for one (or more) particular purposes, it is reasonable to consider them suitable for all purposes. It is plainly possible to use even well-understood algorithms that are indeed acceptably secure for their design purposes in ways that in fact do not provide the security one naively claims. Steve's Needham-Schroeder example is a good case: should we claim that the flaw in question cannot exist unless there is some fundamental flaw in DES? I note that GBDE uses a number of algorithms in ways that are not consistent with their design purposes. For instance, it truncates a non-keyed hash (SHA512); the fact that this is not necessarily a good idea is one of the major motivators for the design of HMAC. It also uses MD5 in a way that I would characterize as not exactly ordinary -- leaving aside that using MD5 at all is a questionable proposition these days. Indeed, the large number of algorithms used in the keying and encryption process for any block in GBDE does not necessarily increase its security: in fact, certain kinds of flaws in any one of those algorithms could in fact make the decryption of any particular block _more_ likely -- and Roland has pointed out how the design of GBDE allows such failures to cascade through the entire set of encrypted data. In other words, unless you are very, very careful about design (the TLS PRF is one example of this) using more algorithms may well make you less secure, not more secure: you may inherit vulnerability to flaws in _any_ of the algorithms you use. Considering the protection periods people asked for, I could convince neither myself nor any of the, (often very clued) people I talked to, that just taking a current standard algorithm and applying it using the same keymaterial to each sector of the media would be safe for a sufficient amount of time. Fine. You don't believe that AES256 will be sufficiently resistant to known- (or perhaps chosen-) plaintext attacks for the next several decades. The question is, what rational warrant do you have for believing that your cryptosystem will be more secure than AES256 would be. The very complexity of your system makes it very, very difficult to evaluate just how secure it is, and you seem to think that that is a benefit: comparing the incommensurables I don't believe and I don't know, but I suspect, you land on the side of I suspect. Somehow I do not find that terribly persusasive. Thor ___ 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
Poul-Henning Kamp [EMAIL PROTECTED] writes: We need more ideas and more people trying out ideas. There is a profession called cryptographer out there. They are the folks who try out these new ideas, and they fill lots of conference proceedings with their new ideas, including things like crypto modes designed specifically for disk encryption. People who are members of this profession spend many years learning what is and is not likely to work when it comes to various cryptographic schemes, and they often learn the hard way that most new ideas in cryptography fail under scrutiny. Even the best of them are very leery of recommending the use of their own new schemes in the real world before they have been heavily reviewed. Even if you are Ron Rivest or Don Coppersmith, you make mistakes, and sometimes bad ones. Were you a cryptographer, and were you proposing, in a theoretical way, a new cryptographic mode for doing disk encryption, and were you presenting it in a paper at Crypto or some such, well, that would be perfectly fine. People could then review it, tear it apart (or fail to) etc, and no one would be harmed. Instead, however, what is happening is that you are implementing your ideas, which do not appear to be very well founded in the experience the crypto community has gained at great price, and they're being tested first on actual users before any peer review of your design. You are hardly the first to do this of course. You follow in a long tradition. The 802.11 folks who designed WEP, the people who designed the security for Bluetooth, the authors of numerous PC security products, and many others, have all rolled their own crypto without being cryptographers and handed it off to unsuspecting users. The results range from unfortunate to downright deadly. WEP was a particularly amusing case, because, like you, its designers thought that it was safe to use an existing encryption algorithm in ways that they never even realized were new and potentially damaging. They didn't understand what they were doing, and so the results were very bad. Let me also mention that everyone who does crypto work hears, at intervals, what horrid insular people cryptographers are and how little respect they have for outsiders. Actually, nothing could be further from the truth. The crypto community is very open -- but it is a meritocracy, and merit is not demonstrated by throwing lots of stuff to the wall and seeing what sticks. Perry ___ 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 Wednesday 02 March 2005 21:15, ALeine wrote: [EMAIL PROTECTED] wrote: I gave up on journalling myself because IMO it complicates things a lot and the problem it solves is very very small. If only hardware manufacturers were to equip hard drives with a mechanism to ensure atomic writes. A capacitor large enough to hold enough energy to flush the cache upon detecting the power supply was cut would be sufficient. This has come up many times. In reality, no, that's nowhere near sufficient, because you might have to employ error correction during the write. In addition, in modern disks, the emphasis at power loss is on getting the heads off the disk as fast as possible -- if you don't, the disk is dead -- so any power available is devoted to that. ___ 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 Thu, 3 Mar 2005, Poul-Henning Kamp wrote: At the time where I wrote GBDE, the best that was offered was CGD (and similar) and users (not cryptographers!) didn't trust it Could you back up this claim, insofar that users did not trust cgd? I haven't seen any distrust of cgd -- in fact, I've seen quite a bit of welcome acceptace of cgd by both users *and* cryptographers. -- -- Todd Vierling [EMAIL PROTECTED] [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: FUD about CGD and GBDE
On Thu, Mar 03, 2005 at 08:25:18PM +0100, Poul-Henning Kamp wrote: At the time where I wrote GBDE, the best that was offered was CGD (and similar) and users (not cryptographers!) didn't trust it and history have so far repeated. To quote David Hume, Never an ought from an is. That users (who are they? how many of them? What criterion or criteria of trust do they apply?) _did_ not trust X says precisely nothing about whether users _should_ not trust X. You seem to deny that there is a particular domain of expertise that is cryptography, or perhaps more rightly two domains, one being largely a subset of the other: how to design good cryptographic algorithms and how to use good cryptographic algorithms safely. Personally, I think that you ought to know better, and that your insistence that there is no such expertise and that arbitrary users (or programmers guided by the sentiment of such users) should feel just as warranted to make recommendations about what other arbitrary users should do, in this domain, is grossly irresponsible. If you found out that most army ordnance officers believe that ball powder is superior to IMR powder as a propellant in small-caliber rifle cartridges, would you ignore the advice of the engineer who designed and tested your new rifle that ball powder would cause the weapon to jam? A lot of people in Vietnam got dead that way: sometimes experts do know what they're talking about, you know, and sometimes giving uninformed advice can have extremely negative consequences. You call Roland's criticisms of GBDE handwaving. It is very hard to see how his specific refutations of the numerical claims of security that you made in your GBDE paper should be rightly considered as such, or why, on the basis of those false claims, you should continue to feel confident that your advice on disk security is good advice. Thor ___ 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
Poul-Henning Kamp [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED], Perry E. Metzger writes: There is a profession called cryptographer out there. They are the folks who try out these new ideas, and they fill lots of conference proceedings with their new ideas, including things like crypto modes designed specifically for disk encryption. There is a world out here that's called the IT industry. Yes, there is. They routinely deploy bad security because they don't get people who know what they are doing involved. See WEP, for example, or a thousand other things. When they badly needed a new password scrambler nobody from that cryptographic discipline could be bothered with a problem already long since solved in their academic journals and the task fell to a more or less random programmer in the end. I have no idea what you're talking about, but if it is the original password hash algorithm in Unix, it was written by Bob Morris Sr., who went on to become one of the top technical guy at the NSA. If you're talking about MD5 which is used in many modern Unixes, it was done by Ron Rivest, and even though he's really good, it has recently been (quite badly) broken. At the time where I wrote GBDE, the best that was offered was CGD (and similar) and users (not cryptographers!) didn't trust it and history have so far repeated. I have no idea what you are talking about here. Can you find me a significant number of users who had CGD available and didn't want to use it? It was only available on NetBSD so far as I know, and it was adopted pretty quickly once it appeared. I can add another property of the elite society of cryptographers: if you are not a card carrying member of their society, the majority of their members can not even be bothered to reply to an email from an outsider. This does hamper communiation a bit. Actually, you can show up at any crypto conference you like, and you'll likely be taken seriously so long as you know what you're talking about even if the people talking to you have no idea who you are. As with most gatherings of geeks, the only real ticket you need is competence. There are also plenty of places to send email to cryptographers where you will be inundated with replies. If you had forwarded a description of your disk protection work to cryptography@metzdowd.com, you would have gotten plenty of responses. The same is probably true of sci.crypt and lots of other places. Maybe the problem is that cryptographers, like true computer scientists, write in nothing less portable than pencil number two ? It is rare to see a new algorithm show up from someone like Ron Rivest without some C code also appearing. That's pretty common in the crypto world. When the Chinese team that cracked a bunch of hash algorithms last summer presented their work, they had worked examples of their stuff. However, how is this relevant? Would you deride your doctor for not programming? Do you write medical diagnostic software without so much as reading a medical journal or talking to a doctor? There is no shame in admitting that there may be other fields than software engineering that have valuable information to share with you. If some card-carrying member of the cryptographic establishment were to offer the Open Source operating systems an implementation which were approved by all (or some qualified quorum of) the high priests of their brother hood, then I am sure that it would be received with praise and thanks of no end. I think you don't quite get it the point. 1) No one claims that you need to be a cryptographer to write something like GBDE. What is being claimed is that you should not have invented your own cryptographic modes, and that you might have wanted to ask some professionals about your approach. 2) CGD *has* been looked at by a bunch of people, and was written to carefully use standard algorithms in a standard way. If you don't like using NetBSD code because NetBSD people have cooties, fine -- I don't care, write your own. However, you should at least pay the same attention to conservative use of cryptographic algorithms and having people review your work is a good idea, too. 3) You've made some very bizarre claims about the security of your system. Some of these claims have already been shown on their face to be incorrect, such as your claimed work factor for breaking your new improved crypto modes. Some of your claims are harder to disprove but none the less seem suspicious. Other comments have been made to the effect that you have ignored certain threat models. Now, when Phil Zimmermann was criticized for inventing Bass-o-Matic for PGP v1 and for otherwise not designing things right, he could have dug in his heels and said I don't see why I should do anything differently. Instead, he admitted his mistakes and wrote a version 2. Are your users better served by you digging in your heels and saying
Re: FUD about CGD and GBDE
Poul-Henning Kamp [EMAIL PROTECTED] writes: Don't let peole like Thor scare you away, progress happens when people try to follow their ideas, even if told that they are fools by people who (think they) know better. They laughed at Fulton. They also laughed at Bozo the Clown. There is nothing wrong with innovation, but there is nothing wrong with reading the literature, either. Perry ___ 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
ALeine [EMAIL PROTECTED] writes: There is a profession called cryptographer out there. They are the folks who try out these new ideas, and they fill lots of conference proceedings with their new ideas, including things like crypto modes designed specifically for disk encryption. You are mistaking people who design cryptographic algorithms and those who design cryptographic systems which integrate those algorithms into functional systems. No, I am not. PHK invented new cryptographic modes for his work. The fact that he does not understand this is part of the problem. People who are members of this profession spend many years learning what is and is not likely to work when it comes to various cryptographic schemes, and they often learn the hard way that most new ideas in cryptography fail under scrutiny. Even the best of them are very leery of recommending the use of their own new schemes in the real world before they have been heavily reviewed. Even if you are Ron Rivest or Don Coppersmith, you make mistakes, and sometimes bad ones. Would you care to explain what qualifies Roland as a more competent cyrptographic system designer than PHK? Roland didn't try to do anything that wasn't already heavily understood in the literature. He invented no cryptographic modes. He used only algorithms that have been pre-vetted. He also asked a bunch of people who know better than he does to check his work. Thus, you don't have to trust Roland at all. He didn't invent any new way of using any of the algorithms. You have to trust only the designers of the block cipher you choose to use (I'd suggest AES) and the password algorithm you choose to use (though the PKCS stuff is very good already). In order to permit even greater defense against key cracking, he put in a very standard and straightforward mechanism to permit N factor authentication. Were you a cryptographer, and were you proposing, in a theoretical way, a new cryptographic mode for doing disk encryption, and were you presenting it in a paper at Crypto or some such, well, that would be perfectly fine. People could then review it, tear it apart (or fail to) etc, and no one would be harmed. The papers are there, the code is there, review it, analyze it, talk about it on TV. Just because it was not done in the way academics like to do it does not mean it has any less merit. Heck, I would love to see Erez Zadok's NCryptFS, but the academic process seems to be so slow that we'll be lucky to see anything before 2006. If PHK took that road we'd be looking forward to GBDE in FreeBSD 7. Somehow, Roland managed to write CGD without any real trouble. That's because rather than innovating, he used well understood primitives in well understood ways. Instead, however, what is happening is that you are implementing your ideas, which do not appear to be very well founded in the experience the crypto community has gained at great price, and they're being tested first on actual users before any peer review of your design. There is a reason everything happens so slowly in the academic circles. Everyone is trying to cover their asses and trying so hard not to be wrong that they analyze everything ad nauseum. No. You Do Not Understand. Cryptography is *brittle*. This has nothing to do with academic sloth. The point is that the best designers routinely have their work smashed to little bits. Are you as good a cryptographer as Ron Rivest? I certainly am not. Somehow, however, MD5 has been crushed anyway. This is not unusual. Cryptographic algorithms are not like sorting algorithms or graph traversal algorithms. When you're doing 3DES, it is not obvious that doing the CBC on the outside instead of between the rounds is critical to good security -- indeed it wasn't obvious even to trained cryptographers. If you aren't as good as Ron Rivest, then why are you expecting to design a new cryptographic mode on your first try without any issues arising? WEP was a particularly amusing case, because, like you, its designers thought that it was safe to use an existing encryption algorithm in ways that they never even realized were new and potentially damaging. They didn't understand what they were doing, and so the results were very bad. WEP relies on RC4 and has a 24-bit IV which means the key stream will definitely get reused after 5 hours of heavy traffic. WEP is even weaker than its design. That is because its designers did not know what they were doing. Inventing new cryptographic modes is dangerous. Let me also mention that everyone who does crypto work hears, at intervals, what horrid insular people cryptographers are and how little respect they have for outsiders. Actually, nothing could be further from the truth. The crypto community is very open -- but it is a meritocracy, and merit is not demonstrated by throwing lots of stuff to the wall and seeing what sticks. Everyone who has the proper education from one of the
Re: FUD about CGD and GBDE
Poul-Henning Kamp [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED], Todd Vierling writes: On Thu, 3 Mar 2005, Poul-Henning Kamp wrote: At the time where I wrote GBDE, the best that was offered was CGD (and similar) and users (not cryptographers!) didn't trust it Could you back up this claim, insofar that users did not trust cgd? I haven't seen any distrust of cgd -- in fact, I've seen quite a bit of welcome acceptace of cgd by both users *and* cryptographers. Some of the people I talked to were very unhappy about the same key being used for all sectors on the disk. Now, was that in the first day after cgd was committed or the second? As I recall, you committed GBDE 48 hours after CGD was committed in NetBSD. I'd be curious to hear about how much you changed your design in that period in response to feedback on cgd. (Please correct me if I'm wrong about the time gap.) However: Some of the people I talked to were very unhappy about the same key being used for all sectors on the disk. Even a small weakness in the cipher becomes a big hole because of the amount of data this offers for analysis. I think we've already established that this fear, though understandable, is not a reasonable one under the circumstances. See several postings already made. You are better off just using AES with a longer key than the GBDE mechanism. Perry ___ 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 Thu, Mar 03, 2005 at 09:41:53PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Thor Lancelot Simon writes: On Thu, Mar 03, 2005 at 08:25:18PM +0100, Poul-Henning Kamp wrote: To quote David Hume, Never an ought from an is. I'm Danish by birth so english is only my second language, so I apologize for mangling it. To be clear, the question is hardly one of linguistics. Perhaps if I call the reasoning mistake in question the naturalistic fallacy it will be more familiar to you than if I just use the common paraphrase from Hume? What I am trying to get across is that you argued from what some (poorly-specified) group of people _do_ believe (that cgd, though it had existed for precisely two days when you checked GBDE into the FreeBSD source tree, so this seems unlikely in the extreme, was not secure) to what everyone _should_ believe (that in fact it is not secure). That's not a kind of reasoning I find very persuasive. But in difference from everybody else (it seems) I also asked users and administrators what they needed and wanted from a cryptographic disk facility. Unfortunately, you seem to assume that users and administrators were, in general, capable of correctly turning their abstract goals about avoiding risk into concrete principles of cryptosystem design. I would submit, in fact, that this is precisely the expertise that you do not acknowledge exists. And then I tried very hard to engage somebody with the right union-card to do a review for me, and despite the fact that funding were available under the DARPA contract nobody would bite. That surprises me, since I didn't see any such attempt at engagement in any of the usual places where such experts communicate (I will leave your crypto-clergy and union-card rhetoric aside). Did you solicit review on the cryptography mailing list? On sci.crypt? At conferences or in journals? You say that experts told you that they were concerned about the amount of data being encrypted with a single key in prior-art cryptosystems. Did it occur to you that, at the time, almost all such cryptosystems used algorithms with a 64 bit block size, and that that precise concern motivated the increase in block size in newer ciphers, including AES? Thor ___ 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
This looks like a linux thing to me... http://en.wikipedia.org/wiki/NPTL If its a spec, i'd like to know how. On Thu, 3 Mar 2005, Julian Elischer wrote: Kamal R. Prasad wrote: --- 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 so how does that differ from what we have ... a native pthreads library? = 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]
Re: FUD about CGD and GBDE
On Thu, 3 Mar 2005, Poul-Henning Kamp wrote: And if CGD is _so_ officially approved as you say, then I can not for the life of me understand how it can use the same key to generate the IV and perform the encryption. At the very least two different keys should have been used at the expense of making the masterkey 512 bits instead of 256. Technically, two different keys are used. The IV is generated from the block number (although it's pluggable for other IV generation methods, should one be desired; take a look!). This makes part of the extended 320-bit (256 + 64 bit off_t) key a known quantity *for a given ciphertext block*, but not the whole disk. This makes attacks a little more difficult than standard 256-bit symmetric AES, as the ciphertext is salted differently depending on the number of the test block. -- -- Todd Vierling [EMAIL PROTECTED] [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: FUD about CGD and GBDE
On Thu, Mar 03, 2005 at 10:15:55PM +0100, Poul-Henning Kamp wrote: And if CGD is _so_ officially approved as you say, then I can not for the life of me understand how it can use the same key to generate the IV and perform the encryption. At the very least two different keys should have been used at the expense of making the masterkey 512 bits instead of 256. Why should two different keys have been used? It is possible that I misunderstand the underlying theory, but so far as I do understand it the only real requirement for IVs is that the Hamming distance between any two used with the same encryption key be large. Are you concerned about a key recovery attack? If so, can you give an outline of how it would work? -- Thor Lancelot Simon [EMAIL PROTECTED] The inconsistency is startling, though admittedly, if consistency is to be abandoned or transcended, there is no problem.- Noam Chomsky ___ 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 Thu, Mar 03, 2005 at 10:45:34PM +0100, Poul-Henning Kamp wrote: Since the attacker know the block number the IV generation doesn't add strength. In fact expose any weakness in the algorithm even more because it offers two-way leverage on the algorithm. It also adds a very efficient hit-detector for a brute force attack. It would have been much better to use a different key to generate the IV. And did he salt the block number at all ? I don't think so... I think there's a misunderstanding here. Why do you think secrecy (unpredictability?) is an important property of an IV for a block cipher used in CBC mode? It's not an encryption key, it's an IV. It just has to have a large Hamming difference from any _other_ IV used with the same cipher key. -- Thor Lancelot Simon [EMAIL PROTECTED] The inconsistency is startling, though admittedly, if consistency is to be abandoned or transcended, there is no problem.- Noam Chomsky ___ 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 Wed, Mar 02, 2005 at 05:55:50PM -0800, ALeine wrote: He designed GBDE to always be harder than and never easier to break than the cryptographic algorithms it relies on. Some very well-intentioned (and plenty smart) people at MIT designed the PCBC cipher mode to always be harder than and never easier to break than the cryptographic algorithms it relies on. Don Coppersmith designed the CBCM mode to always be harder than and never easier to break than the CBC mode of the 3DES algorithm. Unfortunately, all these well-intentioned and very intelligent people were wrong. The novel cryptographic modes they designed to always be harder to break were in fact sometimes -- in fact, in the case of PCBC, pretty much always -- easier to break than the boring, ordinary, pedestrian constructions they were meant to replace. And after all those well meaning and clever people got burned over the years, the consensus of the community of experts (as I percieve it, anyway) gradually became that novel cryptographic constructions should not be used in implementations until they had been extensively studied over a period of many years by experts. Those who do not know the mistakes of the past are doomed to repeat them. Thor ___ 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
I'm not going to defend what Thor said, nor do I even think it's worth discussing as it largely amounts to an appeal to privileged knowledge. However, this is some extremely sloppy thinking in your writing. To wit: On Thursday 03 March 2005 02:43, ALeine wrote: At any time half of all the people are wrong about something, it's only a matter of time when your time will come to be in the wrong half or rather the right half to be wrong. That's a false dichotomy. There are many subjects on which the vast majority of people agree (such, as, I'll wager, the roundness of the Earth). Just because there is a tendency for new cryptographic systems to be broken does not mean this applies to GBDE, otherwise anything new would be considered wrong and we might as well stop even trying to innovate. Give GBDE a chance. It is being given a chance. Giving it a chance does not mean stepping back and ignoring it until someone publishes an exploit. At least one weakness has been identified -- namely, using a weaker encryption mode for the key-key blocks can reduce the strength of the entire system. Or to put it metaphorically, an algorithm is only as strong as its weakest link. GBDE is not replacing anything because there was nothing like it to replace in the first place. That's purely false. There are several other disk encryption systems around. ___ 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
Poul-Henning Kamp [EMAIL PROTECTED] writes: I have a better idea: Why don't we get the cryptographers to show up at computer science conferences ? They do. Perhaps you might want to listen to them. I remember a certain talk at BSDCon where someone criticized the design of the kernel RNG during the talk on it. He mentioned that the person giving the presentation had stated a few inaccurate things, such as claiming that there was a proof of security for Schneier's Yarrow algorithm and a few other howlers. As I recall, he was thoroughly criticized for mentioning these things. As I also recall, when said person brought the topic up with a certain person named PHK, he said I don't want to hear about it. 1) No one claims that you need to be a cryptographer to write something like GBDE. What is being claimed is that you should not have invented your own cryptographic modes, and that you might have wanted to ask some professionals about your approach. You have not actually studied GBDE yet, right ? I read your paper. You don't actually know if I invented my own cryptographic modes or not, do you ? You did. 2) CGD *has* been looked at by a bunch of people, and was written to carefully use standard algorithms in a standard way. If you don't like using NetBSD code because NetBSD people have cooties, fine -- I don't care, write your own. However, you should at least pay the same attention to conservative use of cryptographic algorithms and having people review your work is a good idea, too. Even if I were alone in the world with the sentiment, I would never call CGDs use of the same key for all sectors conservative. You are entitled to your opinion. It is easy to break things in attempting to make them more secure. I'm reminded of inner-CBC 3DES. It is not obvious why inner CBC would be a problem and outer CBC is not -- and yet inner CBC is a problem. Generally speaking, you are best off talking to someone who knows what they are doing and asking them for help first rather than inventing. The cryptography mailing list would be happy to discuss anything you need ideas on. So would sci.crypt and other fora. 3) You've made some very bizarre claims about the security of your system. Some of these claims have already been shown on their face to be incorrect, such as your claimed work factor for breaking your new improved crypto modes. Sorry, they have only been disproved in a significantly larger universe than the one my users inhabit. That doesn't count to me. Being stubborn on this isn't going to help your users. The math is pretty obvious here. Sure a brute force isn't practical -- but neither is a brute force of AES-256. The point is if you are going to claim a higher work factor than AES-256, you have to justify it, and if someone points out an obvious flaw in your logic and shows the work factor is lower than that for AES-256, the gentlemanly thing to do is say you are correct, I was mistaken. Instead, he admitted his mistakes and wrote a version 2. Any qualified, factually correct critique of GBDE will be taken very serious by me. I am very much looking forward to it. What Roland has provided is not it. Roland's criticism is reasonable. Rather than getting angry, why don't you consider it? You don't have to adopt CGD -- build something else if you like. You could go off and try to discuss the algorithms you are using openly and see what people in the field have to say. Being openminded, by the way, includes not assuming in advance that having a different key for every block is a good idea or similar things. It means listening to the experts, and if you don't understand something, learning what they know so you have an informed basis for comment. -- Perry E. Metzger[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: FUD about CGD and GBDE
Poul-Henning Kamp [EMAIL PROTECTED] writes: I think we've already established that this fear, though understandable, is not a reasonable one under the circumstances. See several postings already made. You are better off just using AES with a longer key than the GBDE mechanism. I'm sorry, I reached the exact opposite conclusion. The work that was referred to earlier of defactorizing AES into a very large number of equations would be exactly the kind of attack I would worry about if I have 80 million sectors with the same key. That attack was shown to be bogus. It is highly unlikely that any such attack will ever show up, given the structure of AES. I would not be shocked if an attack on AES *did* show up, but it would likely not be of this sort, and it would likely make no difference in that context whether you encrypt the whole disk with one key or not even if such an attack appeared. If that attack comes through, but relies on some partiular bit combination being present on the plaintext or ciphertext of the algoritm, I see no reason why I would want to improve the attackers odds by a factor of 80 million. Again, it would do no such thing even if the bogus attack was real. And if CGD is _so_ officially approved as you say, then I can not for the life of me understand how it can use the same key to generate the IV and perform the encryption. The IV doesn't matter. So long as the IV is different for each block you are fine. Any function that produces a decent shuffle would be acceptable. (Well, not quite *any*. For various reasons you may want the hamming distance between successive IVs to be large on average, but this achieves that.) -- Perry E. Metzger[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: FUD about CGD and GBDE
ALeine [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: You are mistaking people who design cryptographic algorithms and those who design cryptographic systems which integrate those algorithms into functional systems. No, I am not. PHK invented new cryptographic modes for his work. The fact that he does not understand this is part of the problem. He designed GBDE to always be harder than and never easier to break than the cryptographic algorithms it relies on. I have no doubt that was the intent. The question is, did he achieve it? Would you care to explain what qualifies Roland as a more competent cyrptographic system designer than PHK? Roland didn't try to do anything that wasn't already heavily understood in the literature. He invented no cryptographic modes. He used only algorithms that have been pre-vetted. He also asked a bunch of people who know better than he does to check his work. Thus, you don't have to trust Roland at all. He didn't invent any new way of using any of the algorithms. You have to trust only the designers of the block cipher you choose to use (I'd suggest AES) and the password algorithm you choose to use (though the PKCS stuff is very good already). In order to permit even greater defense against key cracking, he put in a very standard and straightforward mechanism to permit N factor authentication. MD5 was believed to be heavily understood in literature. It was well established. Look at what happened to it. Yup. And Roland made the algorithm you use for encrypting your disk *pluggable*. That way, if AES is broken, you can replace it with the next big thing and move on with your life. Now, if AES is indeed broken, GBDE is in serious trouble, but CGD is not. Specific users of CGD have to change their drives, but the framework continues to work as advertised. The fact that Roland did not invent any new ways of using algorithms does not mean that CGD is more secure. It does, however, mean right from the get-go that the standard analysis you use for looking at this works right out of the box. You don't have to invent anything new to figure out if it works right. In fact, IMHO it is less secure because it uses the same key for the entire disk and because it reuses the same key for IV generation and encryption. Do you know enough about cryptography to have an opinion, humble or not? For example, if I handed you something encrypted in a polyalphabetic cipher and asked you to tell me the key length, off the top of your hand would you know how to use the index of coincidence to do that? If I asked you to explain the difference between the security of inner and outer CBC 3DES, could you tell me? Could you explain what a characteristic is and how it is used in differential cryptanalysis? I'm not saying, by the way, that you should take my opinion or anyone else's as gospel. Argument from authority is worthless. At crypto conferences you will find differing opinions -- merely understanding crypto doesn't mean you are right. You should learn enough to form your own opinion. However, that implies that you must first learn enough that you have a basis on which to form it. If you don't know anything about medicine, do you have any good basis for telling your anesthesiologist to use a different drug in your surgery? So you say that to you, using one key for the entire disk is a bad idea. Very good. On what basis do you say this? Now it *is* true that you shouldn't use a key for too much data, and we have some ways these days of calculating how much data too much is. Do you understand how that calculation is performed? You have to trust Roland to integrate the well known and understood algorithms in a correct way, trusting the algorithms alone is not enough. His code did indeed have some bugs to begin with. It was reviewed and they were fixed. I am not designing cryptographic algorithms, what PHK did with GBDE cannot be compared to inventing MD5, snap out of it, you are starting to sound like a broken record. But the problem is that he crossed a line, so it *can* be compared to things like inventing MD5. He isn't merely using existing algorithms in well known ways. He is, in fact, using algorithms in modes that they having been used in before and making very very specific claims of work factors to break these new modes. WEP is even weaker than its design. That is because its designers did not know what they were doing. I assure you PHK knows very well what he is doing I've read his paper. I must respectfully disagree. and I think you should not mention his name in the same breath along with the names of the designers of WEP. The comparison seems to be perfectly apt -- people competent in one field assuming that another very complicated field is trivial, and extending their work into that other field, in which they are no longer competent. Inventing new cryptographic modes is dangerous. Living is dangerous, today you
Re: FUD about CGD and GBDE
Roland Dowdeswell [EMAIL PROTECTED] writes: I realise that PHK has been claiming that you might get false positives, and that you somehow have to maintain a matrix of past this and that. It is a lot simpler than this really. Of course, given that the unicity distance is much less than the text encrypted under one block. For each key--key sector you are brute forcing, there are 2^128 different keys to try. Now, the key--key sector protects 32 disk sectors which contain 32 * 512 * 8 = 131072 bits. That means that there are 2^131072 possibilities for what can be in those 32 sectors. So, I think that we can see where I am going here? Yes. Small unicity distance, vanishingly low chance of false positive. Now, granted not the entirety of the 32 sectors will be recognisable, or necessarily even used---but a fair percentage will. Enough to come up with numbers that may not be so astronomically small, are still staggeringly small---a staggeringly small possibility that such a false positive generating key actually exists at all. There is a good paper by Dave Wagner and Steve Bellovin on how to detect that you have the right plaintext, btw, even without needing things that can actually understand what they are looking at. Disklabels for example have a checksum. The checksum might not be terribly strong, but the chance that two different valid disklabels could even be decrypted with different keys is small, I would imagine. The checksum takes off 2^32 seemingly valid disklabels and what about the rest of the fields? There's lots of redundant information in there that could be cross referenced. You don't even need that. A very cheap statistical test will show that you have the right key with very good probability. However, given checksums, you pretty much have the plaintext nailed. -- Perry E. Metzger[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: FUD about CGD and GBDE
On Fri, Mar 04, 2005 at 12:42:33AM +0100, Poul-Henning Kamp wrote: The fact that you just need to break one single sector in CGD before you get the entire disk contents gives a disadvantage to CGD of 2^26 before we even consider the nature of the attack. That is not conservative when it could have been trivially avoided. The mechanisms gbde takes to avoid it are far from trivial. -- Dan. pgpuBboqV56p6.pgp Description: PGP signature
Re: FUD about CGD and GBDE
Thor Lancelot Simon [EMAIL PROTECTED] writes: I think there's a misunderstanding here. Why do you think secrecy (unpredictability?) is an important property of an IV for a block cipher used in CBC mode? It's not an encryption key, it's an IV. Indeed. The IV can (subject to some constraints) be anything you like. Not having it public at very, very best denies one block from the ciphertext to the attacker -- ultimately not very useful in this application to prevent cracking given the low unicity distance. -- Perry E. Metzger[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: FUD about CGD and GBDE
Thor Lancelot Simon [EMAIL PROTECTED] writes: On Wed, Mar 02, 2005 at 05:55:50PM -0800, ALeine wrote: He designed GBDE to always be harder than and never easier to break than the cryptographic algorithms it relies on. Some very well-intentioned (and plenty smart) people at MIT designed the PCBC cipher mode to always be harder than and never easier to break than the cryptographic algorithms it relies on. Don Coppersmith designed the CBCM mode to always be harder than and never easier to break than the CBC mode of the 3DES algorithm. FYI, Don Coppersmith has forgotten more crypto than most people in the world in the field have ever known. Among other things to his credit was this little algorithm called DES that he helped bring to life. He too makes mistakes. Perry ___ 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
Poul-Henning Kamp [EMAIL PROTECTED] writes: If the component (well respected etc etc) algorithms I have used in GBDE contains flaws so that they become individually less intrinsicly safe because their input is the output of another such algorithm, then the crypto-world has problems they need to work on. The crypto world is a world of very brittle materials developed by humans with finite capacities. We do our best, but we make mistakes. Combining algorithms in such a way that the result is unexpectedly weak has been seen on several occasions. The reason cryptographers are very cautious is because they have been burned repeatedly. Despite my best efforts to get people interested in reviewing GBDE, it doesn't seem to have succeeded in getting any attention until now, and I am very much looking forward to the competent review and input this will generate. If you wish to hear my suggestions on how to get review, feel free to contact me offline. Perry ___ 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
Poul-Henning Kamp [EMAIL PROTECTED] writes: You don't actually know if I invented my own cryptographic modes or not, do you ? You did. I did ? Cool, I should patent them! :-) I would encourage it. It will keep others from wanting to use them. Sorry, they have only been disproved in a significantly larger universe than the one my users inhabit. That doesn't count to me. Being stubborn on this isn't going to help your users. The math is pretty obvious here. Sure a brute force isn't practical -- but neither is a brute force of AES-256. No, not right now. And if a break was found, it isn't clear that all your you would actually protect against it very effectively. The simpler and safer solution is to have the ability to replace your algorithm easily. But do we know that a brute force attack is unfeasible on AES-256 tens years from now ? No, we don't. What we do know is that it seems pretty unlikely that the general *mechanism* of CGD is flawed given the security of its components. Since the components may be flawed, the system permits easy selection of other algorithms. My strong suggestion for you is that you adopt a similar approach -- build a good framework that, given good algorithms, will provide security, and make it easy for users to change over if an algorithm falls. When we were designing IPSec, there was a very interesting proposal called SKIP, which had as its main flaw that we could never really alter algorithms if we picked it. That alone damned it. As it turns out, our decision was a good one. And are we sure that the reuse of key material which happens in CGD will not materially aid any attacks that may be developed in the next decade ? I will never say never, but the reuse is for IVs. Now, if you examine what it means for something to be an IV in a CBC context, you will see that you are, in a very real sense, not using the key any differently than it is used elsewhere. That is to say, you are encrypting a piece of data under the key and then using the output as a value to xor with another piece of data. That is pretty much the definition of CBC mode. Essentially what you have is prepended the block number to each block and then run CBC over the whole block using a zero IV. That of course means that the first block is now theoretically vulnerable in reuse, but since it isn't secret and is never reused and isn't even placed on the disk, we don't really care. It is possible that this usage is subtly bad, but it has been studied in many other contexts, such as in cryptographic network protocols, and it is likely reasonable. Again, I will never say never, just as I would never claim AES is safe forever. The fact that you just need to break one single sector in CGD before you get the entire disk contents gives a disadvantage to CGD of 2^26 before we even consider the nature of the attack. I disagree with your analysis, but lets consider what you are saying. You are claiming, in essence, that AES 256 isn't good enough for you, and that you need a better cipher. If it isn't good enough for you, I suggest that rather than bandaid AES 256, what you should do is actually find a better cipher to use. The goal for GBDE is to give credible denial of access for up to 25 years, Well, so is stock AES 256. I don't see why I should assume your construction is any better. What do you know that the NIST/NSA review of AES did not know? -- Perry E. Metzger[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: FUD about CGD and GBDE
Poul-Henning Kamp [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED], Perry E. Metzger writes: MD5 was believed to be heavily understood in literature. It was well established. Look at what happened to it. Yup. And Roland made the algorithm you use for encrypting your disk *pluggable*. That way, if AES is broken, you can replace it with the next big thing and move on with your life. Now, if AES is indeed broken, GBDE is in serious trouble, but CGD is not. Specific users of CGD have to change their drives, but the framework continues to work as advertised. Gee Perry, now you're spreading FUD. You know perfectly well that it would take less than one hour to substitute another algorithm in the GBDE source code. But you aren't built for that from the get-go. I would strongly suggest you change that -- make your cipher a user configurable component. I also very strongly suggest that the biggest real threat you face isn't someone cracking AES but key management issues. CGD is in some sense largely a framework for letting you do all sorts of neat things with key management in a disk encryption context. You may want to add similar features -- the most practical attack against your system as it stands is a dictionary attack. -- Perry E. Metzger[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: FUD about CGD and GBDE
In message [EMAIL PROTECTED], Poul-Henning Kamp writes: I have studied the AES papers and in particular the attacks and critisisms of it very carefully, and they have proven a whole lot of things to be impossible, but they have not proven that there are not more that needs to be proven impossible. When DES was designed, nobody knew that differential attacks existed. No, no one in the open sector new. DES was specifically designed to resist differential cryptanalysis. The best source for information on how DES was designed is Don Coppersmith's paper The Data Encryption Standard (DES) and its strength against attacks, IBM Journal of Researchand Development, Vol. 38, n. 3, pp. 243-250, May 1994. It's worth noting that in the ~30 years since DES was designed, exactly *one* attack significantly better than brute force was found: linear cryptanalysis. Coppersmith's paper shows how that could have been prevented, too. A few years ago, Biham came up with a 2^79 attack against a slightly-weakened version of Skipjack, an NSA cipher. I mentioned that to a friend who has -- let's say connections. He smiled and said 2^79 complexity against an 80-bit cipher? I don't call that an attack, I call that good engineering. Since then, I've heard other statements from well-connected people that boil down to this: NSA has a deep understanding of how strong a cipher is. In that vein, I'll note that 256-bit AES is approved for Top Secret traffic. Shortly after AES was gold-plated the earlier mentioned attack method where it is decomposed into a massive number of equations was presented. As noted, that attack is discredited. --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]
Re: FUD about CGD and GBDE
In message [EMAIL PROTECTED], Thor Lancelot Simon writes:
On Thu, Mar 03, 2005 at 10:15:55PM +0100, Poul-Henning Kamp wrote:
And if CGD is _so_ officially approved as you say, then I can not
for the life of me understand how it can use the same key to generate
the IV and perform the encryption. At the very least two different
keys should have been used at the expense of making the masterkey
512 bits instead of 256.
Why should two different keys have been used? It is possible that I
misunderstand the underlying theory, but so far as I do understand it
the only real requirement for IVs is that the Hamming distance between
any two used with the same encryption key be large.
On this point, I tend to agree with phk -- it's generally a bad idea to
use the same key in two different contexts, because there can be
interactions. I'd be happier if a different mechanism were used to
generate the IV, such as HMAC of the key and block number, or
encryption of the block number with a hash of the key, or by stretching
the input key to a longer output key per PKCS#5 and using the two
halves for different purposes. While I don't see a real attack to
worry about here, in some situations there's a possibility of a chosen
plaintext attack: I write 0s to block #k; the ciphertext of the first
16 bytes of that block will be encryption of k under the same key. I
hasten to add that that's *not* even close to a real attack for lots of
reasons, not the least of which is that AES was designed to resist
chosen plaintext attacks in far more devastating circumstances.
The other change I think is important for cgd is to provide a
key-changing mechanism. That is, I'd like to have a key from
/dev/random or /dev/urandom used for the actual encryption, but have
that key encrypted via the PKCS#5-converted password. That's a small
change to cdgconfig; another change would be needed to provide the
password-changing code. Again, phk is right about this point, though
his paper misstates the reason: it's not that all security policies
we have ever seen, contain a rule which says 'passwords must be
changed every N {days,weeks,months}'. This is sound thinking, and
GBDE should support it. -- such policies tend to be rather stupid,
in fact. Rather, it's addressing the crucial weakness of any of these
schemes: users pick bad passwords.
A more interesting, and to me open, question is whether or not
one needs to worry about encrypting too much data with one key.
AES in CBC mode does have a limit of 2^64 blocks, or 2^68 bytes.
If we assume you can buy a 1 TB (i.e., 2^40 byte) disk today, and
we assume that disk capacity is doubling every year, we'll hit that
limit in 28 years. Of course, assuming that doubling will continue for
28 years is a stretch, but one can always use RAID to build bigger
file systems. The real question, though, is whether or not there's
a limit significantly smaller than 2^64 blocks. Note, too, that such
a development doesn't affect the security of data written to today's
smaller disks.
But this discussion has degenerated into name-calling. I suggest that
a pointer to the gbde paper be posted to the cryptography mailing
list. Yes, Perry is the moderator; no, that's not a problem even
for those he disagrees with. He does a clean, fair job. Besides, that
list is one place where members of the Cryptographers' Guild do interact
with real programmers -- the list has quite a collection of each,
plus some people who live in both worlds. That latter category
includes me (I don't design cipher algorithms; I do design -- and
attack -- cryptographic protocols), David Wagner, Hugo Krawczyk (one of
the inventors of HMAC), and many others.
You can subscribe to that list by sending 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: FUD about CGD and GBDE
Poul-Henning Kamp [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED], Perry E. Metzger writes: My strong suggestion for you is that you adopt a similar approach -- build a good framework that, given good algorithms, will provide security, and make it easy for users to change over if an algorithm falls. If you actually look at GBDE, you will see that any and all of the algorithms can be changed. They are used only in their most basic capability. This was part of the design from the start: not to rely on any single-source algorithm. I understand that, but the point is to make it user friendly. CGD lets you pick a number of crypto systems right now in its configuration. You can pick multiple key lengths, methods of deriving the key, etc. I've read through things like the GBDE command man page, how-tos, etc., and I found nothing that allows you to do stuff like change cipher with GBDE. I also don't find support for things like multi-factor authentication. All that could be added, of course, and I encourage you to do it -- but my point is that it isn't there now and you should look at doing it. If I can pick any one of several ciphers and key lengths already or specify things like multi-factor authentication, my apologies. In any case, please understand that my goal is not to tell your users that FreeBSD is garbage or anything like that. My goal is to get you to improve what you have done. If you want to tell me I'm an idiot or what have you, feel free, but I don't think that will serve your users particularly well. Well, so is stock AES 256. I don't see why I should assume your construction is any better. What do you know that the NIST/NSA review of AES did not know? That neither the authors of Rinjdael, its reviewers, nor NIST are willing to offer a 25 year warranty on it. No one rational will give a warranty on *any* encryption system for *any* length of time. The best I can say, however, is that the US government has approved the use of AES with 256 bit keys for very highly secure communications, and they have a very demanding user community. Assuming that you can brute force a bit or two more key per year, and assuming that better cryptanalytic techniques doubled that somehow, you would still have many many years before 256 bit AES became a real issue. Anyone rational attacking you will look at other flaws in your system first. -- Perry E. Metzger[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: FUD about CGD and GBDE
Poul-Henning Kamp wrote: I am being a bit unfair here because I am lumping CGD in with the equally defficient code in Linux (Loop-AES etc). It was mostly the linux code I talked to people about, but CGD makes the same exact mistake. Loop-AES for Linux has improved a lot since v1.X versions. Please take a look at recent v3.X versions which include security features that even your GBDE doesn't have. It appears to me, that the people who designed CGD and the Linux Loop-AES and similar focused very hard on the box that said AES without giving much consideration to where the arrows between the boxes went. Early versions of loop-AES were FUBARed, true. But why do you insist on ranting about fuckups that were fixed long time ago? -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
sched_ule, runqueues, priority, and O(1) sheduling question
Hi folks. I wander how O(1) sheduling works in ULE. In ule.pdf Jeff wrote: Threads are picked from the current queue in priority order until the current queue is empty. As far as I understand the algorithm is O(n) where n - number of READY TO RUN processes, not all processes isn't it? thanks, Andriy. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: generic network protocols parser ?
On Fri, Mar 04, 2005 at 11:07:34AM -0500, Aziz KEZZOU wrote: Hi all, I am wondering if any one knows about a generic parser which takes a packet (mbuf) of a certain protocol (e.g RSVP ) as input and generates some data structre representing the packet ? I've been searching for a while and found that ethereal and tcpdump for example use specific data structres and functions to dissect each protocol packets. Is this the only approach possible ? My supervisor suggested using a TLV (Type/Length/Value) approach instead. Any opinions about that? If no such a parser exists is there any practical reason why ? Thanks, Aziz You can only go so far with generic parsing. Eventually you will want some protocol specific value to be extracted and your parser will have to know about what the packet looks like. What are you trying to do, exactly? -- Bosko Milekic [EMAIL PROTECTED] [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: FUD about CGD and GBDE
Any chance some part of this discussion can be taken off-line? Or to freebsd-sec? -Dan ___ 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
would people mind not bcc'ing freebsd-hackers? I've been deleting this thread from my inbox for a couple of days because it's not filtered into my bsd folders :) On Thu, 2005-03-03 at 15:52 -0500, Perry E. Metzger wrote: Poul-Henning Kamp [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED], Todd Vierling writes: On Thu, 3 Mar 2005, Poul-Henning Kamp wrote: At the time where I wrote GBDE, the best that was offered was CGD (and similar) and users (not cryptographers!) didn't trust it Could you back up this claim, insofar that users did not trust cgd? I haven't seen any distrust of cgd -- in fact, I've seen quite a bit of welcome acceptace of cgd by both users *and* cryptographers. Some of the people I talked to were very unhappy about the same key being used for all sectors on the disk. Now, was that in the first day after cgd was committed or the second? As I recall, you committed GBDE 48 hours after CGD was committed in NetBSD. I'd be curious to hear about how much you changed your design in that period in response to feedback on cgd. (Please correct me if I'm wrong about the time gap.) However: Some of the people I talked to were very unhappy about the same key being used for all sectors on the disk. Even a small weakness in the cipher becomes a big hole because of the amount of data this offers for analysis. I think we've already established that this fear, though understandable, is not a reasonable one under the circumstances. See several postings already made. You are better off just using AES with a longer key than the GBDE mechanism. Perry ___ 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 status report.... status!
All, Thanks to the help of Max Laier and Tom Rhodes, the FreeBSD status reports are alive and will be much more regular. However, in the interest of not over-burdening the developers who submit reports, we've decided to switch from a bi-monthly cycle to a quarterly cycle. So, we will not be soliciting submissions this month, but we will solicit them next month. That will also coincide nicely with the release of FreeBSD 5.4, so we'll be looking for a lot of reports that highlight 5.x improvements. Thanks, Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: generic network protocols parser ?
At Fri, 4 Mar 2005 11:07:34 -0500, Aziz KEZZOU wrote: Hi all, I am wondering if any one knows about a generic parser which takes a packet (mbuf) of a certain protocol (e.g RSVP ) as input and generates some data structre representing the packet ? I've been searching for a while and found that ethereal and tcpdump for example use specific data structres and functions to dissect each protocol packets. Is this the only approach possible ? My supervisor suggested using a TLV (Type/Length/Value) approach instead. Any opinions about that? If no such a parser exists is there any practical reason why ? You might want to look at libnet and libnet-ng. Start here: http://www.packetfactory.net/libnet/ Perhaps not exactly what you want but the beginnings are there. Later, George ___ 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
[CC list pruned] On Wed, 2005-Mar-02 13:15:49 -0800, ALeine wrote: If only hardware manufacturers were to equip hard drives with a mechanism to ensure atomic writes. A capacitor large enough to hold enough energy to flush the cache upon detecting the power supply was cut would be sufficient. I'm not sure thus is readily practical at the drive level. Based on some back-of-envelope calculations using figures in a Seagate Barracuda manual (which I happened to have handy): - Random seek is 9.5 msec. - Rotational period is 8.3msec - Power consumption at 50% R/W, 50% seek is 0.82A @ 12V + 0.68A @ 5V A single random seek + track write will take 17.8 msec. This translates to an electrical charge of 0.015C @ 12V and 0.012C @ 5V. Assuming the drive is designed to allow the supply rails to droop 20% whilst functioning correctly during this shutdown phase (which is a significantly bigger drop than the standard specifications), a single random seek + track write would require the drive to include a 6000µF capacitor on the 12V rail and a 12000µF capacitor on the 5V rail. As a first order approximation all Unix disk operations are writes (reads can be satisfied from the buffer cache). Given the size of current generation drive caches, it's more likely that there are around 50 writes cached - which requires capacitors 50 times as large - which would make them significantly larger than the drive itself. They could even use a battery the status of which could be monitored via S.M.A.R.T., I don't see how implementing something like that could possibly make the cost noticably higher. Batteries (and standard supercaps) are generally designed to release their energy over an extended period - several minutes is the lower realistic limit. It would make sense to build a battery backup system which maintained power for (say) 5 minutes. It's not realistic to build a battery backup system that can release all it's available energy in 1 second. If you're going to the effort of building a battery backup system, you might as well backup the entire computer. These are available off the shelf and have the added advantage of allowing users and the system to clean up before the power goes away. -- Peter Jeremy ___ 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 Sat, Mar 05, 2005 at 05:37:47AM +1100, Peter Jeremy wrote: [CC list pruned] On Wed, 2005-Mar-02 13:15:49 -0800, ALeine wrote: If only hardware manufacturers were to equip hard drives with a mechanism to ensure atomic writes. A capacitor large enough to hold enough energy to flush the cache upon detecting the power supply was cut would be sufficient. I'm not sure thus is readily practical at the drive level. Based on some back-of-envelope calculations using figures in a Seagate Barracuda manual (which I happened to have handy): - Random seek is 9.5 msec. - Rotational period is 8.3msec - Power consumption at 50% R/W, 50% seek is 0.82A @ 12V + 0.68A @ 5V A single random seek + track write will take 17.8 msec. This translates to an electrical charge of 0.015C @ 12V and 0.012C @ 5V. Assuming the drive is designed to allow the supply rails to droop 20% whilst functioning correctly during this shutdown phase (which is a significantly bigger drop than the standard specifications), a single random seek + track write would require the drive to include a 6000µF capacitor on the 12V rail and a 12000µF capacitor on the 5V rail. As a first order approximation all Unix disk operations are writes (reads can be satisfied from the buffer cache). Given the size of current generation drive caches, it's more likely that there are around 50 writes cached - which requires capacitors 50 times as large - which would make them significantly larger than the drive itself. This is not what anyone is asking to achieve. What is being asked is not to lose a whole track just because one sector on the track was being written upon power loss. Dealing with many in-order writes being lost (in order), upon power loss, is something the filesystems are already written to assume, and the fsync(2) semantics are designed to work with. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: generic network protocols parser ?
Aziz KEZZOU wrote: Hi all, I am wondering if any one knows about a generic parser which takes a packet (mbuf) of a certain protocol (e.g RSVP ) as input and generates some data structre representing the packet ? you might look at DPF (a packet filter/classifier).. it has an interesting filter description language. I've been searching for a while and found that ethereal and tcpdump for example use specific data structres and functions to dissect each protocol packets. Is this the only approach possible ? My supervisor suggested using a TLV (Type/Length/Value) approach instead. Any opinions about that? If no such a parser exists is there any practical reason why ? Thanks, Aziz ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net 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: generic network protocols parser ?
On Fri, Mar 04, 2005 at 11:07:34AM -0500, Aziz KEZZOU wrote: Hi all, I am wondering if any one knows about a generic parser which takes a packet (mbuf) of a certain protocol (e.g RSVP ) as input and generates some data structre representing the packet ? I've been searching for a while and found that ethereal and tcpdump for example use specific data structres and functions to dissect each protocol packets. Is this the only approach possible ? My supervisor suggested using a TLV (Type/Length/Value) approach instead. Any opinions about that? If no such a parser exists is there any practical reason why ? Ethereal uses TLV... -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
quagga and OSPFD and point-to-point tunnels.
Here is an odd situation. If I start quagga ospfd after creating gre, tun, or gif devices, ospfd recognises them as point-to-point interfaces and everything works. However, if I start quagga and then create interfaces afterwards, the interfaces are not recognised as point-to-point interfaces and OSPF packets only travel in one direction (into the box). I'm not sure if the problem lies solely with quagga or FreeBSD or a little of both. For one, does the GRE device not have the POINTOPOINT flag set immediately? Has someone banged their head against this problem? It appears to cover all versions of FreeBSD, but I'm using 5.3-RELEASE-p5 to test. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: init troubles with custom install .. perhaps a kernel bug?
On Thu, 3 Mar 2005 22:25:37 -1000, William Bierman [EMAIL PROTECTED] wrote: Hello. I have been endeavoring to create my own livecd which will mount a remote share from which to run scripts installing a ghost image onto a local hard drive. I realize this may be more trouble than it's worth, but I am doing it to easily assimilate new machines into a Beowulf cluster... so I think it is. I have done everything I can think of to do this properly: 1) I used the process defined in the bsdlabel man page for setting up the slices/partitions/labels/etc. (search for dd in the man page) 2) I extracted the ghost images, in the form of tarballs, to the /, /usr, and /var slices. There is a partition for /tmp, but empty. I also setup a 1Gb swap slice. These slices are setup to mirror how they would be if I were to use the standard fbsd install cd. Now, here's the problem.. the kernel loads, and I start getting a list of the devices it detects, and it reaches the point of 'Mounting root from ufs:ad0s1a', then locks up. Either init is not being called, or is stalling somewhere. I have disabled pnp in my BIOS settings, and I have a single 16G IDE hard disk to which these operations are being performed. I have tried the various options in the boot menu (single user, safe mode, verbose logging, etc.) and the only useful information I get is when in verbose logging mode, it reaches the halt point, and additionally says: start_init: trying /sbin/init then halts. Could anyone shed some light on this for me? I can provide whatever additional information may be necessary. I have done some extra tinkering with this. I have inserted debug statements in init_main.c and kern_init.c to figure out where the halt occurs, however it seems that the kernel process terminates succesfully after its execve() call. I also inserted a print statement at the start of init, which does not get displayed. I used warning() in init.c. I don't know the kernel back to front, but it seems the problem is in the handoff between the kernel and init. Again, any additional information can be provided (including the modifications I made to give debug statements to the kernel and init). Thanks! William ___ 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 Sat, 5 Mar 2005, Peter Jeremy wrote: [CC list pruned] On Wed, 2005-Mar-02 13:15:49 -0800, ALeine wrote: If only hardware manufacturers were to equip hard drives with a mechanism to ensure atomic writes. A capacitor large enough to hold enough energy to flush the cache upon detecting the power supply was cut would be sufficient. I'm not sure thus is readily practical at the drive level. Based on some back-of-envelope calculations using figures in a Seagate Barracuda manual (which I happened to have handy): - Random seek is 9.5 msec. - Rotational period is 8.3msec - Power consumption at 50% R/W, 50% seek is 0.82A @ 12V + 0.68A @ 5V A single random seek + track write will take 17.8 msec. This translates to an electrical charge of 0.015C @ 12V and 0.012C @ 5V. Assuming the drive is designed to allow the supply rails to droop 20% whilst functioning correctly during this shutdown phase (which is a significantly bigger drop than the standard specifications), a single random seek + track write would require the drive to include a 6000µF capacitor on the 12V rail and a 12000µF capacitor on the 5V rail. As a first order approximation all Unix disk operations are writes (reads can be satisfied from the buffer cache). Given the size of current generation drive caches, it's more likely that there are around 50 writes cached - which requires capacitors 50 times as large - which would make them significantly larger than the drive itself. They could even use a battery the status of which could be monitored via S.M.A.R.T., I don't see how implementing something like that could possibly make the cost noticably higher. Batteries (and standard supercaps) are generally designed to release their energy over an extended period - several minutes is the lower realistic limit. It would make sense to build a battery backup system which maintained power for (say) 5 minutes. It's not realistic to build a battery backup system that can release all it's available energy in 1 second. If you're going to the effort of building a battery backup system, you might as well backup the entire computer. These are available off the shelf and have the added advantage of allowing users and the system to clean up before the power goes away. -- Peter Jeremy I must be missing something, but I'll succumb to the temptation and ask: Why not put a flash chip into the drive's onboard electronics, of the same size as the drive's cache, or the max possible size of all outstanding cached writes? If power dies, park the heads immediately. Use your last-gasp energy source of choice to commit the write cache contents into nonvolatile storage. Next time it's powered up, the drive firmware could flush the outstanding write requests to real storage before coming ready to the operating system. At least some modern drives (seen this on HP/Compaq servers, etc) already have flash-upgradeable firmware. It's just a matter of adding a little more. You would use it only when power fails, so it's not like you would wear it out. Surely this would require far less power than spinning and seeking the disk for the required amount of time? It might take longer based on the flash chip's write speed, but that's probably a feature, since a small battery would be able to supply much less current over time. Cost should be reasonably low since this stuff is in all sorts of consumer devices. Jason Young, CCIE #8607 (RS, Voice), MCSE Consulting Engineer e-velocity technical consulting, llc. (513)677-6223 x108___ 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
[EMAIL PROTECTED] wrote: I'm not going to defend what Thor said, nor do I even think it's worth discussing as it largely amounts to an appeal to privileged knowledge. However, this is some extremely sloppy thinking in your writing. You do not understand what was said. To wit: On Thursday 03 March 2005 02:43, ALeine wrote: At any time half of all the people are wrong about something, it's only a matter of time when your time will come to be in the wrong half or rather the right half to be wrong. That's a false dichotomy. There are many subjects on which the vast majority of people agree (such, as, I'll wager, the roundness of the Earth). Have you ever heard of statistical probability distribution and the logical principle of bivalence (tertium non datur)? If at any time there are x people then exists (vertically mirrored E) such a proposition P that for at least x/2 of the people the proposition R x is wrong about P holds true. The people who are wrong and the proposition(s) are dynamic and change with time but that property remains true at all times in a system with sufficient propositions and a large enough number of people. Q.E.D. It is being given a chance. Giving it a chance does not mean stepping back and ignoring it until someone publishes an exploit. Giving it a chance does not mean spreading FUD about it and shouting around It's new, it must be bad! I have not even read the papers or looked at the code myself, but I will criticize it because I like NetBSD better! If you want to really be constructive do something that is constructive, analyze GBDE, write a paper, improve the code. You're just adding noise to the discussion, you may have as well commented on my punctuation marks. At least one weakness has been identified -- namely, using a weaker encryption mode for the key-key blocks can reduce the strength of the entire system. Or to put it metaphorically, an algorithm is only as strong as its weakest link. You really don't know what you're talking about, do you? GBDE is not replacing anything because there was nothing like it to replace in the first place. That's purely false. There are several other disk encryption systems around. You're right, IIRC PKZIP v1.10 had DES encryption back in 1990, someone should have told PHK! :-P Please, get a clue, read PHK's papers. 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]
Fw: Libre Software Meeting 2005 : Call for contributions
I haven't seen this forwarded to the FreeBSD list, so I thought I'd take the liberty of forwarding it here. Warner ---BeginMessage--- CALL FOR CONTRIBUTIONS Libre Software Meeting 2005 --- Operating system design and implementation The Libre Software Meeting (LSM) has been one of the most important Free Software events in France since the year 2000 [0]. This year, the meeting will take place from July 5th to July 9th in Dijon, to the East of France. The Libre Software Meeting aims at allowing designers and developers of free software projects [1] from different places to meed and and share their ideas and experiences. LSM is also an opportunity to discuss societal issues. Technical conferences cover a wide range of topics, from high-level programming languages to databases, through security concerns. The operating system design and development topic is looking for speakers to present free software projects. Technical topics include (but are not limited to): * design and implementation of operating systems: architecture, services, libraries, use of high-level languages and advanced programming techniques such as AOP, dynamic reconfiguration, etc.;= * kernel subsystems: schedulers, I/O schedulers, virtual memory management, etc.; * filesystem implementation: journalized, distributed filesystems, etc.; * realtime extensions to free operating systems; * virtualization tools (i.e. Xen, User-Mode-Linux, etc.); * kernel development tools : debuggers, performance evaluation, etc.= ; * distributed operating systems; * embedded systems development. Programs of previous years are available online [2]. The program for 2005 is being defined and a tentative program is available online [3]. There is no programme committee (it is not a scientific conference) and selection process is expected to remain as lightweight as possible. Volunteers should contact Thomas Petazzoni [EMAIL PROTECTED] and Ludovic Court=E8s [EMAIL PROTECTED] by June 2005. Speakers= are encouraged to write a small paper (6 to 12 A4 sheets) summarizing their presentation (in an open format such as PostScript or PDF). Ludovic Court=E8s and Thomas Petazzoni. [0] http://lsm2000.abul.org , http://lsm2001.abul.org , http://lsm2002.abul.org , http://lsm2003.abul.org , http://lsm2004.abul.org . [1] http://www.gnu.org/philosophy/free-sw.html [2] http://wiki.ael.be/rmll2003/index.php/ThemeOperatingSystem , http://lsm2002.abul.org/program/topic06/topic06.php3 , http://lsm2000.abul.org/program/topic06_en.html . [3] http://www.rencontresmondiales.org/sections/conference/noyau_et_sys= teme -- = PETAZZONI Thomas - [EMAIL PROTECTED] http://thomas.enix.org - Jabber: [EMAIL PROTECTED] KOS: http://kos.enix.org/ - SOS: http://sos.enix.org Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E 1624 F653 CB30 98D3 F7A7 ---End Message--- ___ 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
[EMAIL PROTECTED] wrote: I have no doubt that was the intent. The question is, did he achieve it? You seem to be making claims to the contrary, but at the same time you do not even know some basic facts about GBDE. Have you really read even the gbde(8) man page? If so, how come you missed that big notice in bold at the very top, informing users that GBDE should be considered a slightly suspect experimental facility. It was not encrypted, so I'm sure you could have read it. But no, you come running and start spreading FUD about GBDE and making claims about GBDE being promoted as the perfect solution. For someone who talks a lot about merit your words and actions show very little of it. Yup. And Roland made the algorithm you use for encrypting your disk *pluggable*. That way, if AES is broken, you can replace it with the next big thing and move on with your life. Now, if AES is indeed broken, GBDE is in serious trouble, but CGD is not. Specific users of CGD have to change their drives, but the framework continues to work as advertised. GBDE can easily be extended to be modular in that way. AFAIK PHK does not see a need for that because he does not want to increase the complexity, but it might be implemented at some point, it's just not a priority. If AES is broken, can CGD re-encrypt the entire drive using the new replacement algorithm on the fly, without requiring any additional storage? If not, having such modularity is a bit of a joke, it gives users a false sense of security. The fact that Roland did not invent any new ways of using algorithms does not mean that CGD is more secure. It does, however, mean right from the get-go that the standard analysis you use for looking at this works right out of the box. You don't have to invent anything new to figure out if it works right. Sometimes the biggest mistakes hide in simplicity, I believe SMB demonstrated that point quite aptly with the Needham-Schroeder protocol flaw that was totally obvious, but went unnoticed for 18 years. When a 3 line protocol can be so obviously flawed and the flaw goes unnoticed for such a long time I hope you are not overly confident about CGD working right. Do you know enough about cryptography to have an opinion, humble or not? For example, if I handed you something encrypted in a polyalphabetic cipher and asked you to tell me the key length, off the top of your hand would you know how to use the index of coincidence to do that? If I asked you to explain the difference between the security of inner and outer CBC 3DES, could you tell me? Could you explain what a characteristic is and how it is used in differential cryptanalysis? Have you actually read any of my posts or do you have a template of questions that you send to anyone you feel is welcome to join the crypto community? You speak of the openness and merit and how the crypto community undeserverdly has a bad reputation for being elitist and dismissive of outsiders, yet you are only reinforcing that very same stereotype in the worst way. Your condescending tone is not welcome, but in case you seriously expected an answer I suggest you take a course in cryptography, you may even get help from someone at sci.crypto, I hear they are really friendly there and you should be able to find the right pair for your kind of character(istic) there. :- I'm not saying, by the way, that you should take my opinion or anyone else's as gospel. Argument from authority is worthless. At crypto conferences you will find differing opinions -- merely understanding crypto doesn't mean you are right. You should learn enough to form your own opinion. However, that implies that you must first learn enough that you have a basis on which to form it. If you don't know anything about medicine, do you have any good basis for telling your anesthesiologist to use a different drug in your surgery? After what I've seen from you I would hardly call you an author, let alone an authority on anything. You contradict yourself at least twice a day, you make unsubstantiated claims, you talk down to people and the chip on your shoulder is one of the biggest I've seen. Worst of all, you have the time to keep wasting people's time with your noise. If you are bored take up a hobby, perhaps hosting a radio show might be fun? So you say that to you, using one key for the entire disk is a bad idea. Very good. On what basis do you say this? On the same basis that I prefer to wear a jacket with many pockets rather than a bag. You, of course, have read all my previous posts in this discussion and know what I am talking about, that's why you had to ask me about something I already explained. Now it *is* true that you shouldn't use a key for too much data, and we have some ways these days of calculating how much data too much is. Do you understand how that calculation is performed? Are you sure it would be OK for me to answer that question? After all, I'm not a member of
Re: FUD about CGD and GBDE
[EMAIL PROTECTED] wrote:
It is a serial attack that is:
for (i=0; i n; i++) {
crack the i'th key--key block;
}
So it is actually where $n$ is the number of key--key sectors:
[ ASCII art removed and sent to the museum of modern arts :- ]
So, for a disk with 2^30 key--key sectors it would be
2^30 * 2^128 = 2^158
I realise that PHK has been claiming that you might get false
positives, and that you somehow have to maintain a matrix of past
this and that. It is a lot simpler than this really.
Your assumption is wrong. First of all, the first sector of the
encrypted image does not necessarily start at the beginning of
the disk, nor does the last sector have to be the last sector
of the disk. At initialization first_sector, last_sector and
total_sectors can be set so that the encrypted image is placed
at an offset from both sides of the disk. If you also use
random_flush that free space (padding) is filled with random
garbage automatically, so one cannot detect where the encrypted
image actually begins or ends.
I would like to see some statistics regarding the distribution
of superblock, inode and directory structures, but I believe
the attack you are describing cannot be automated to the point
of being practical.
You also completely ignored the fact that the smallest logical data
sector size is 512 bytes, but that it can also be set to any
reasonable 2^n size (as PHK already pointed out, 2kb is the
recommended size on FFS). You can only guess as to the size
of the logical sector.
You also have to take into acount the fact that there are at
least 4 512 byte lock sectors (regardless of the size of the
logical sector) which will thwart your automated brute forcing
attempt further. Lock sectors can be anywhere, their location is
picked randomly at initialization and everything else has to map
around them, so you cannot assume anything about their location
or know that you stumbled upon them.
If you take into account that you cannot be sure that you got a
complete zone or that you are indeed looking at a single logical
data sector things become complicated quickly, so your estimate
is way too optimistic.
BTW, since you claim to have studied the papers, you may want to
start using the correct terminology, there is no such thing as a
key-key sector, there are only key sectors, data sectors, lock
sectors, the master key, generated key-keys and sector keys.
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
[EMAIL PROTECTED] wrote: Your disk has 2^128 sectors? Where can I buy one of those? In the same movie I referenced in the post you took that from. :- Either there or in the dream I referenced a bit later. :- 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
On Fri, 2005-Mar-04 16:37:05 -0600, Jason Young wrote: Why not put a flash chip into the drive's onboard electronics, of the same size as the drive's cache, or the max possible size of all outstanding cached writes? That seems to be a better idea. ISTR that once upon a time, vendors made chips that had RAM shadowed by EEPROM which gave you the non-volatility of EEPROM with the read/write performance of RAM. Since the EEPROM was written at once, you only needed 10-20 msec hold-up to preserve your RAM. At least some modern drives (seen this on HP/Compaq servers, etc) already have flash-upgradeable firmware. It's just a matter of adding a little more. You would use it only when power fails, so it's not like you would wear it out. I think that most modern drives have very little firmware in ROM - just a bootstrap - with most of the firmware stored on the disk itself. -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 4.11-RELEASE SACK
Greetings, I posted this question on freebsd-question list yesterday, but no replies. So I am just trying my luck here. Thanks in advance. I've installed the standard FreeBSD 4.11-RELEASE and have realized that the sysctl option for enabling SACK in TCP is not available (net.inet.tcp.do_sack). Additionally, the tcp_sack.c file is not in the /usr/src/sys/netinet so I'm guessing this indicates that I need a patch. Hoping to be able to use SACK in FreeBSD 4.11-RELEASE, I wanted to ask : 1) Is my guess correct (Do I need a patch)? Or is my kernel configuration file missing an option? 2) Assuming I need a patch, what patch is generally recommended for using SACK under TCP in FreeBSD 4.11-RELEASE? Any help would be most appreciated. Thanks, ken ___ 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
[EMAIL PROTECTED] wrote: The principle of bivalence merely states that every proposition is either true or false. Tertium non datur is the law of the excluded middle, which is not the same. Furthermore, neither one says anything about half the population falling on one side or the other; you're either making that up or confusing it with something else. I refer you to: http://en.wikipedia.org/wiki/Bivalent http://en.wikipedia.org/wiki/Law_of_excluded_middle You are wrong, tertium non datur is the law of the exclusion of the THIRD possibility (it stems from Latin and means the third is not given), meaning that any statement can only be either true or false. Some of us have learned mathematics at school, you should try that too, eventhough Wikipedia can be informative, I'm sure. :- You really don't know what you're talking about, do you? Hey, you're the one who argued that it's 2^384 to break. Even PHK's own paper on GBDE puts the effort to break it at 2^129. Who is it that hasn't read the paper? Roland argued against 2^384, I argued against Roland's underestimate of 2^158, not for 2^384 specifically. Please learn to pay attention. You're right, IIRC PKZIP v1.10 had DES encryption back in 1990, someone should have told PHK! :-P Please, get a clue, read PHK's papers. And yet more nonsense. PKZIP isn't even a disk encryption system. And you know very well that CGD and Loop-AES both predate GBDE. Claiming that there is nothing like it is objectively false. Now, if you'd care to stop making ad hominem attacks, perhaps there can be some useful discussion. Perfer et obdura, dolor hic tibi proderit olim. :-)) Go check if that is in Wikipedia. :-)) You can email me for the translation if you cannot find it online. :- 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
Thor Lancelot Simon wrote this message on Thu, Mar 03, 2005 at 16:01 -0500: [.. ] (that cgd, though it had existed for precisely two days when you checked GBDE into the Just because I am tired of incorrect information (repeated) when it is freely available on the respective websites: CGD: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/cgd.c Revision 1.1 / (download) - annotate - [select for diffs], Fri Oct 4 18:22:35 2002 UTC (2 years, 5 months ago) by elric BDE: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/geom/bde/g_bde.c Revision 1.1 / (download) - annotate - [select for diffs], Sat Oct 19 17:02:16 2002 UTC (2 years, 4 months ago) by phk So, according to this, CGD existed in NetBSD's source tree 15 days before GBDE was committed... And it took me all of one minute to find this. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sched_ule, runqueues, priority, and O(1) sheduling question
I haven't looked at it, but could it just be referring to retrieving a thread from the queue. Just pulling something off a queue is a O(1) operation. The order it places things in the queue probably is not. :) On Mar 4, 2005, at 11:15 AM, Andriy Tkachuk wrote: Hi folks. I wander how O(1) sheduling works in ULE. In ule.pdf Jeff wrote: Threads are picked from the current queue in priority order until the current queue is empty. As far as I understand the algorithm is O(n) where n - number of READY TO RUN processes, not all processes isn't it? thanks, Andriy. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] 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: FreeBSD 4.11-RELEASE SACK
Kan Cai wrote: Greetings, I posted this question on freebsd-question list yesterday, but no replies. So I am just trying my luck here. Thanks in advance. I've installed the standard FreeBSD 4.11-RELEASE and have realized that the sysctl option for enabling SACK in TCP is not available (net.inet.tcp.do_sack). Additionally, the tcp_sack.c file is not in the /usr/src/sys/netinet so I'm guessing this indicates that I need a patch. Hoping to be able to use SACK in FreeBSD 4.11-RELEASE, I wanted to ask : 1) Is my guess correct (Do I need a patch)? Or is my kernel configuration file missing an option? 2) Assuming I need a patch, what patch is generally recommended for using SACK under TCP in FreeBSD 4.11-RELEASE? the people who contributed the SACK code contrinuted it only to the 5.x or later relases. It would be up to someone else to the the back port to 4.x. Any help would be most appreciated. Thanks, ken ___ 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]
filedesc struct in filedesc.h
Hello, all, I have a Q on filedesc.h: i am wondering whether the order of the field in struct _filedesc_ (in sys/filedesc.h) matters? I added a field to _filedesc_ struct in filedesc.h. It is a dynamically allocated list, just as fd_ofiles, or fd_ofilefalgs. I put my new added list right after fd_fileflags, and allocate/initialize it just as fd_ofiles or fd_ofileflags. Even if I put little of my extra code in except this data field, and codes to allocate and initialize it ( i put it in fdgrowtable(), just as the existing kernel initialize fd_ofiles, or fd_ofileflgs. (i believe i did this allcaotion/initialization part right:) the problem i had is page fault and then crashes the kernel. If I put my extra data fields at the end of _filedesc_ or _filedesc0_ struct, it then works.. My Q is: is there places in the kernel that not directly use the field name to access a member of filedesc struct, but implicitly assuming the ordering of the fields in strcut filedesc, e.g., they may use offset to access a field? so then my new added field may mess up the original code? I found one such place in fdgrowtable() in kern_descrip.c there is one such line: -- nfileflags = (char *)ntable[nnfiles]; -- so it allocates and assumes that fd_ofileflags is right after fd_ofiles in _filedesc_ struct. I am curious is there other places in the kernel that implicitly use the info on the order that those fields are defined? i hope my Q makes sense.. 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: sched_ule, runqueues, priority, and O(1) sheduling question
I haven't looked at it, but could it just be referring to retrieving a thread from the queue. Just pulling something off a queue is a O(1) operation. The order it places things in the queue probably is not. :) You rihgt - just pulling something off a queue is a O(1) operation, but before pulling algorithm is finding the thread with highest priority, with it have to pull - this is not the O(1) operation. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
