Re: [gentoo-user] new timezone data requires setting a symlink by hand
Helmut Jarausch [EMAIL PROTECTED] at Thursday 31 July 2008, 13:27:24 Hi, am I doing something wrong? Whenever I emerge a new sys-libs/timezone-data I need to do afterwards rm -f /etc/localtime ln -s /usr/share/zoneinfo/Europe/Berlin /etc/localtime (This is with baselayout-2.0.0) Many thanks for a hint, Why don't you just create /etc/timezone with Europe/Berlin as content? -- Freedom is always the freedom of dissenters. (Rosa Luxemburg) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] kernel 2.6.25-r6 oddities; is this kernel really ready for stable?
Kevin O'Gorman [EMAIL PROTECTED] at Thursday 24 July 2008, 03:26:26 On Wed, Jul 23, 2008 at 5:06 PM, Volker Armin Hemmann [EMAIL PROTECTED] wrote: On Mittwoch, 23. Juli 2008, Kevin O'Gorman wrote: I run gentoo x86 stable, so that I usually avoid this sort of thing. This kernel, however, looks balky to me, because it's reporting warnings and other oddities during compilation. I don't like warnings at any time, and with the kernel's make wrappers cleaning up the output they tend to stand out. Here's what I get: -- various type/attribute warnings harmless. -- reports of deprecated elements even more harmless -- a report of section mismatches, and instructions to use make CONFIG_DEBUG_SECTION_MISMATCH=y to find details. completly harmless. All three 'problems' can be safely ignored. So do it. And how would I know they're harmless. No offense, but I don't know enough about you to evaluate your skill or knowledge. I have seen lots of build problems over the decades, but these are new to me. What I see is that for some time now, kernel builds have been utterly clean, admirably free from the tedious command-line echoes that obscure any real information from compiler/linker/whatever build tools. You were ever able to built a kernel without warnings?! You certainly must have some magic in your hands ;) Kernel developers always had a dismissive attitude towards compiler warnings, non-serious warnings are rarely fixed. So what's a poor user to do? Believe the first poster responding with (apparent) authority? Maybe. I'm just going to stay away for a while and see what shakes out. Obviously, despite all the warnings, a proper kernel binary was created. You wouldn't stop using a software just because of all the warnings, that are issued by a normal emerge, so why to are you taking warnings during a kernel build so much more serious? All that being said, the compilation completes, and I can boot it. I don't know the cause, but I have been unable to get vmware-server running on it, and I'm going back to the previous kernel for that reason. complain to vmware - it's their closed source crap that doesn't work. I have less clout with vmware than I have with the kernel team, I would guess, because I don't pay either one, but at least the kernel team are not in business to get money from me. But reasonable virtualization is essential to some of my own projects, and I have to stick with it. If I have to, I'll learn a different tools set, but it's not something I take up lightly. And what are the kernel developers supposed to do regarding vmware? And should a closed source software, that's most likely only used by a minority of Gentoo users, really stop all the other users from profiting from a newer and probably faster and more stable kernel? -- Freedom is always the freedom of dissenters. (Rosa Luxemburg) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] kernel 2.6.25-r6 oddities; is this kernel really ready for stable?
Dale [EMAIL PROTECTED] at Wednesday 23 July 2008, 19:09:45 Kevin O'Gorman wrote: I run gentoo x86 stable, so that I usually avoid this sort of thing. This kernel, however, looks balky to me, because it's reporting warnings and other oddities during compilation. I don't like warnings at any time, and with the kernel's make wrappers cleaning up the output they tend to stand out. Here's what I get: -- various type/attribute warnings -- reports of deprecated elements -- a report of section mismatches, and instructions to use make CONFIG_DEBUG_SECTION_MISMATCH=y to find details. All that being said, the compilation completes, and I can boot it. I don't know the cause, but I have been unable to get vmware-server running on it, and I'm going back to the previous kernel for that reason. SNIP You are not alone if having issues with this kernel. When I tried to run it recently, I noticed a serious slow down in KDE, especially when logging into KDE. My usual login time is about 7 to 8 seconds but with this kernel, try about 30 seconds. My mouse was jerky and even Seamonkey was very slow to switch tabs. Nothing changed but the kernel. I didn't test to long because it was so annoying. Don't forget to mention, that sun darkened and rain was coming, once you had booted 2.6.25 ... Compile issues are one thing, but putting all these application issus on the kernel seems a bit unfair, especially, when admitting, that you didn't test long. I have seen my KDE login or tab switching in firefox delayed, too, but not because of any kernel upgrade, but because updatedb was taking action right when I was logging in, or because a forgotton compile process on TTY1 took CPU power away. I for my part didn't have any problems with 2.6.25-r6, neither at compile time nor at runtime -- Freedom is always the freedom of dissenters. (Rosa Luxemburg) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] OT Calenders
James [EMAIL PROTECTED] at Wednesday 23 July 2008, 19:43:16 Hello, I currently use Korganizer. I was wondering if there is a way to enhance the calender with know public holidays. For example, say I wan to get the Holidays for the USA, Canada and Jamaica onto my KOrganizer? KOrganizer supports standard ICal-Files. Googleing for usa holidays ical gets me to http://www.icalworld.com/holidays.html There are files for Canada and the USA. I didn't verify their completeness, since I'm not living in any of the mentioned countries, and don't know about any US holiday save Independence Day and Halloween ;) -- Freedom is always the freedom of dissenters. (Rosa Luxemburg) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] My last words on cryptology and cryptography.
Steven Lembark [EMAIL PROTECTED] at Thursday 26 June 2008, 23:52:17 I submit that brute forcing an AES key of reasonably length is currently impossible in an amount of time that would matter to the human race. On average yes. As already pointed out, however, there is nothing to prevent the first guess from matching a key and cracking one particular example of the cipher in 0.0001 seconds. A probability of something like 1 / 5 to die in a car accident does not one prevent from driving a car. But a probability of 1 / (2^256) of finding the first key right away at the first guess is easily held up against key security of AES ... now that's a very strange mismatch. Apparently you consider the security of your life much, much less worth than security of your encrypted hard disk ... -- Freedom is always the freedom of dissenters. (Rosa Luxemburg) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Loop-AES versus DM-Crypt versus ???
7v5w7go9ub0o [EMAIL PROTECTED] at Friday 27 June 2008, 05:41:15 Chris Walters wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Sorry if this subject has been hashed and rehashed again, but I was wondering which Gentoo partition encryption scheme is considered the best, in terms of: 1. Security Another thing: If I remember correctly, LUKS keeps the actual key on the encrypted disk, itself encrypted with a passphrase. Naturally this means that an attacker only has to break the passphrase, which gets him the key Naturally ... if the user wants to use passphrases, the key needs to be related to the passphrase somehow, whether by it being derived from the passphrase through hashing or it being encrypted with a second key, that is derived from the passphrase. But a decent hard disk encrpytion system should be able to store the key file on a USB stick or on a smart card. Beside a increased security, because there is weak passphrase, it provides increased comfort: You don't have to enter a silly passphrase on every boot ;) -- Freedom is always the freedom of dissenters. (Rosa Luxemburg) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] h
kashani [EMAIL PROTECTED] at Friday 27 June 2008, 02:28:21 Here's a reference to the interesting meet-in-the-middle attack which reduced 3DES key space down to 112 bits from 192. 3DES always had an effective key size of 112 bits, because it uses the original DES algorithm applied in the following scheme E1(D2(E1(M)) with two different 56-bit DES keys. 3DES never had 192 bit keys. The meet-in-the-middle attack has nothing to do with 3DES. In fact, 3DES was designed the way it works now to _prevent_ meet-in-the-middle attacks. Such attacks can be applied to ciphers, that apply a single algorithm with two different keys: E1(E2(M)) Mathematical, the key size of the latter cipher is equal to 3DES: 56+56 = 112. But the latter cipher is vulnerable to meet-in-the-middle attacks, which is why 3DES uses the second key to apply the DES decryption function with a different key right between the consecutive DES encryptions. Obviously that was unknown when 3DES was built. I doubt. If meet in the middle was unknown at the time of 3DES development, we wouldn't have 3DES today, but 2DES, being as simple as E1(E2(M)). -- Freedom is always the freedom of dissenters. (Rosa Luxemburg) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] My last words on cryptology and cryptography.
Alan McKinnon [EMAIL PROTECTED] at Thursday 26 June 2008, 10:54:43 The calculation is quite simple - measure how quickly a specific computer can match keys. Divide this into the size of the keyspace. The average time to brute force a key is half that value. AFAIK this still averages out at enormous numbers of years, even at insane calculation rates like what RoadRunner can achieve. According to Wikipedia RoadRunner is designed for 1.7 petaflops in peak. Assuming for the sake of simplicity, that decryption can be performed within a single flop: (2^256) / (1.7 * 10^15) / 2 ~= 3.5 * 10^61 In years: 3.5 * 10^61 / 3600 / 24 / 356 ~= 10^54 Correct me if I'm wrong, but it seems impossible to me, to reduce this get the required amount somewhere near to the life time of a human being ;) -- Freedom is always the freedom of dissenters. (Rosa Luxemburg) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] loop-aes + extra-ciphers...
Chris Walters [EMAIL PROTECTED] at Wednesday 25 June 2008, 17:14:20 | Rumor has it that the three-letter agencies (CIA, KGB, M.A.V.O. [2], | etc) can break those algorithms relatively easy. On the other hand even | weaker algorithms can protect your data against laptop thieves. You had better used the acronym FUD instead of the word rumor. US government itself has declared Rijndael 256 sufficient for classified information up to top secret. This level of security is shared among all AES finalists like RC6 or Serpent. That's more than a rumor. Another three letter agency (NSA) has networks of supercomputers that can brute force a passphrase is little time. Bruteforcing a _passphrase_ is not the same as bruteforcing a key. An both of these don't have nothing to do with the algorithm itself. They are side-attacks ... a weak passphrase is user idiocity, not a cipher weakness. It is not that I'm terribly paranoid about people getting my data, I just want to make it a little harder. What's the point in making the impossible even harder? Of course, it is always possible to insert code that will send the unencrypted data, once you've logged on - not easy for the casual user, but for the guru, an easy thing. That's operating system security and has nothing to do with cryptology. Someone having only your hard disk can't inject a rootkit into the system. -- Freedom is always the freedom of dissenters. (Rosa Luxemburg) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] loop-aes + extra-ciphers...
Chris Walters [EMAIL PROTECTED] at Wednesday 25 June 2008, 22:25:18 Are you a cryptology expert? Are you then? The only thing that cryptography attempts to do is reduce the **probability** of cracking the key and gaining access to the data as low as possible. No news. That's, why cryptology defines security not as being impossible to crack, but as being sufficiently improbable to crack. The only cipher, that can't be brute-forced, is the OTP, which is considered perfectly secure. As for brute forcing a passphrase: Since most implementations of AES (Rijndael) use a hash of the passphrase to form the key, it amounts to the same thing, in practice, as cracking the key. First of all, you can perform hard disk encryption _without_ a passphrase. You can store keyfiles on smart cards, usb sticks, etc. In this case, you can generate a _truely random_ key. Using a passphrase is the most insecure approach, but still, with a sufficiently random passphrase, you can gain a level of security, that even the NSA will find difficult to come around. The randomness of a 30-char passphrase does of course by far not match the randomness of a 256-bit key, so there is a real chance, that it can be guessed by brute force. Still it will take much cpu time, which is not endless, even to the NSA. In such a case, the question is, if the data, you ciphered, is really worth the effort of putting a super computer into work for a long time to try any possible passphrase. Cryptology is, at least partly about finding the weakest link, because that is what is likely to be attacked in any cryptosystem. Of course, absolutely true. Hard disk encryption is by far not perfect, just look at the cold boot attacks that gained public interest in the last time. But you didn't talk of _cryptosystems_ in your previous posts, you did talk about _algorithms_. Summarizing, the modern ciphers themselves are secure, as there is mostly no way to crack them save a brute-force attack on the key. On the other hand, cryptosystems built around these algorithms can of course contain weaknesses and holes, like weak passphrases, unsecure key storage, etc. The US Government only keeps classified information on non-networked computers in secure environments, so the cipher used does not matter as much as the other security measures taken to ensure that the data does not fall into the wrong hands. May be. I do not know, which restrictions apply to US classified data, I only know about official statements, the US government made towards the security of AES. A final thought: It is a fact that both the US Navy and the NSA are *very* interested in cryptology and data security. The NSA also does have large networks of supercomputers that, using parallel, distributed or concurrent computing principles can crack keys more quickly than you may think. You can use simple mathematics to find out, that even the largest super computers, having one peta flop, needs millions of years to perform an exhaustive search through AES key space. Anyway, you may believe, what you want to believe, I'm just reflecting, what real experts like Bruce Schneier have been telling for years: It's wrong to trust into simple ciphers, but it's equally wrong, to believe, that anything can be broken. my 2 cents -- Freedom is always the freedom of dissenters. (Rosa Luxemburg) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] loop-aes + extra-ciphers...
Jason Rivard [EMAIL PROTECTED] at Wednesday 25 June 2008, 23:53:23 The only thing that cryptography attempts to do is reduce the **probability** of cracking the key and gaining access to the data as low as possible. No news. That's, why cryptology defines security not as being impossible to crack, but as being sufficiently improbable to crack. The only cipher, that can't be brute-forced, is the OTP, which is considered perfectly secure. There is no such thing as perfectly secure, A OTP cannot be broken using brute force, so the term perfectly secure fits here, imho, at least a bit ;) In such a case, the question is, if the data, you ciphered, is really worth the effort of putting a super computer into work for a long time to try any possible passphrase. Mr. Walters' claim is not that they would put a single super-computer to decrypting it, but a network of supercomputers. Does that difference really matter for ciphers like AES or at least for brute-force attacks on random 256-bit keys? I truly don't think you have to worry about that occurring, unless you are deemed a danger to US National Security. Even then, AES is very hard to crack. The major weakness is the person who encrypts the data. Under questioning, most will give up their keys. Cryptology is, at least partly about finding the weakest link, because that is what is likely to be attacked in any cryptosystem. Of course, absolutely true. Hard disk encryption is by far not perfect, just look at the cold boot attacks that gained public interest in the last time. But you didn't talk of _cryptosystems_ in your previous posts, you did talk about _algorithms_. By themselves algorithms are relatively useless. It is only the application of those algorithms that make them useful. Still, there is a difference between the algorithm as such and a cryptosystem applying this algorithm. Btw, apart from general stuff like weak passphrases, that apply to most cryptosystems, really bad leaks often came from weak algorithms. Consider WEP. A final thought: It is a fact that both the US Navy and the NSA are *very* interested in cryptology and data security. The NSA also does have large networks of supercomputers that, using parallel, distributed or concurrent computing principles can crack keys more quickly than you may think. You can use simple mathematics to find out, that even the largest super computers, having one peta flop, needs millions of years to perform an exhaustive search through AES key space. Anyway, you may believe, what you want to believe, I'm just reflecting, what real experts like Bruce Schneier have been telling for years: It's wrong to trust into simple ciphers, but it's equally wrong, to believe, that anything can be broken. It is equally wrong to believe that any cipher is immune to attack I don't and I did not say so, things like the Debian disaster bring you back to reality from dreams ... -- Freedom is always the freedom of dissenters. (Rosa Luxemburg) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Loop-AES versus DM-Crypt versus ???
Chris Walters [EMAIL PROTECTED] at Monday 23 June 2008, 17:46:23 Dirk Heinrichs wrote: | Am Montag, 23. Juni 2008 schrieb ext Chris Walters: [snip] | 3. Number and type of ciphers available | | Maybe I'm wrong, but the name loop-aes tells this, right? With LUKS, | one can use (nearly?) any cipher/hash supported by the kernel. [snip] | Gentoo has support for both. Big plus of LUKS is the ability to assign | more than one key (so my wife can boot the laptop with her own key). | | HTH... | | Dirk Actually, there are extra ciphers available for use with loop-aes. Does it matter? AES is on of the best algorithms available, there is no reason to change to another. I might try LUKS. Does it have support for multi-key encryption? Yes, it has. How about random key encryption? That's not a matter of the encryption software itself, random keys should be possible with any encryption thing out there. Actually, multi-key encryption somehow requires random keys. In such a setup, there is a random master key, which itself is ciphered with the individual user keys. When adding or removing user keys, the software stores a individually encrypted copy of the random master key (or removes it). -- Freedom is always the freedom of dissenters. (Rosa Luxemburg) signature.asc Description: This is a digitally signed message part.
