I don't want people who aren't invested enough* to go to a poll to decide policies that affect my life.
(*modulo people with disabilities or who have work conflicts, but we already have mechanisms in place to account for that -- I'm talking about the general issue of lowering the bar too much)
MBGMorden (803437) wrote: > Truthfully given how limited my scope of gaming is these days Linux > could PROBABLY serve all my needs if there were a good WoW (and > Ventrilo) client for it.
For the record, I leveled a priest all the way to level 70 on WINE/Gentoo. Never had a single crash. Ventrilo on WINE works fine for me too.
I work in a corporate culture where if you are not available via instant messaging, many perceive is that you are not really working at the time. I know several people who wake up in the morning and the first thing they do is connect via the VPN to get their instant messaging client running so that their bosses and coworkers think they are working diligently. I work best by batching tasks via email messages, so I make it clear to people to just send me an email and I will get back to them within a day or so. This does not work for some people; one person in my organization will try instant messaging me and calling my office phone, but he will not bother to send me an email, and then he will later complain that he cannot communicate with me.
As a software engineer, I remain productive by having several hours of uninterrupted time to focus on a particular task at hand. When the code builds, installs, tests, and is in the repo ready for the next release, then I am ready to move on to the next task, like check my email, which I do maybe two or three times a day. I am able to give my code the due attention it deserves, and I can concentrate on not making coding mistakes by keeping the entire code context "swapped in" my head while I am working on it. During that time, invariably some project manager somewhere is panicking about a status report or some other overhead and is trying to get me to update a bug ticket or something. Usually, by the time I read his frantic email about the status report, I have already fixed the problem that he wants status on because I was able to focus on it without interruption.
Most people eventually figure out that they get good consistent work from me regardless of the fact that they cannot interrupt me freely at any time, like most other employees in my organization. I do wish that more of my coworkers would take a more proactive stance on not letting themselves get interrupted all the time, since I see first-hand the negative impact it has on their ability to function. I get annoyed when I am trying to talk to my boss during a meeting and he stammers right in the middle of an important discussion with, "Uh, wait, I just got am IM, I, uh, need to, uh, just a second, let me think..."
> introducing random jitter would go some way to subverting this, no?
Exactly. I took a few minutes to glance over the paper. Their feature extraction stage consists of two predictable attributes: packet size and time between packets. Modifying the traffic sent at the application layer (SSH itself does not even need to be touched) can trivially ambiguate the extracted features so as to throw off the classification attempt. This is simply a road bump; as soon as it gets into use, application-layer proxies will pop up to circumvent it.
They also seemed to have inventented their own home-brew statistical analysis. I was disappointed that they did not go into detail as to why they largely ignored the entire field of Machine Learning (NaiveBayes? Perceptron? kNN? Why not try using these?) when coming up with their classification model.
I just got a call from my mother last night. She is running Ubuntu on her ThinkPad, and she absolutely loves it. She spends 99% of the time at home using her own wireless network, and there are no problems at all. Running Ubuntu on her laptop solves more problems than it causes, since she is the kind of person who double-clicks on random crap people forward to her. For stuff she absolutely has to do in other operating systems, she runs KVM+QEMU. I have her system set up to SSH into my own box on the rare occasion that I have to connect remotely and install something (happens maybe once every two months).
Last night though, she was at a hotel, and she wanted to connect to the hotel's wireless network. Through many years of experience with Linux distro's and wireless devices, I told her right off the bat that she had about a 50% chance of actually connecting with a reasonable about of time and effort. The wireless device was in Roaming mode, and that obviously was not working. So, she went ahead and selected the hotel's ESSID, chose DHCP, and then activated the wireless device. Does she need a WPA key? Who knows; the interface in Ubuntu is mum on whether or not it is in the clear. Well, of course, it did not work. And of course, I was not the least bit surprised.
We both had much better things to do with our time than to struggle with iwlist, iwconfig, and ifconfig settings in an xterm over the phone, so I just told her that she would have to wait to get home to connect back up to the Internet.
The vast majority of folks out there really just want to use the web for their computing tasks. The whole computer is quite literally a "web interface" device. The desktop-ability of the device rests almost entirely on its ability to actually connect to the Internet.
My own personal experience over the years with numerous wireless devices (iwl4965, prism, atheros, etc.) has left me a bit disappointed in the vendors in terms of driver features and quality. The wireless setup utilities in Ubuntu and Fedora are okay, but they could be a little more informative about is actually going on so I do not have to drop to an xterm to dork around ("Okay, so exactly why don't I have an IP address now? Are DHCP packets actually making it out, or what?").
If I could pick any one top-priority problem still facing the entire Linux package today, it would be wireless connectivity to the Internet. My mother needs to be able to walk into a hotel, turn on her laptop, and, with little or no effort, just get a link to the Internet. She should never have to call someone to figure out how to get to her gmail account. Maybe scan the AP's on boot and have a wizard pop up when it detects a change in the wireless environment or something of the sort.
I have a friend to works at Canonical, so maybe it would be more effective to ping him on this than to rant on Slashdot. Just had to get this off my chest though.
Due to the key management issues I brought up, I disagree with using these storage devices as adequate means for protecting anything near top secret. No use putting a titanium padlock on a cardboard box.
> Two possibilities: We've seen dramatic weaknesses in md5 and sha1, > and it's not impossible that something similar could be found for > AES.
MD5 and SHA1 are one-way hashes. AES is a symmetric cipher. The weaknesses found in MD5 and SHA1 have nothing to do with AES. Weaknesses have been found in symmetric ciphers like Skipjack, however, and that would have been an appropriate example.
> A reduction from 128 bit security to ~96 or even ~64 bits of > security would be a relative disaster; 64-bit ciphers are simply not > secure anymore.
A reduction from 256 bits to 96 bits would also be a disaster. So long as we are spreading FUD about an imaginary attack against AES-128, why not go all the way to AES-256?
We have discovered absolutely no cause to be concerned about a possible reduction of the effective key length of AES, regardless of whether it is 256 bits or 128 bits. Until we get some sort of indication that perhaps this might be a possibility (we need this thing scientists like to call ``evidence''), we can say with some degree of confidence that AES-128 really provides 128-bit key protection.
> Additionally, quantum computers can theoretically break symmetric > ciphers in sqrt(n) time, which means that AES-128 could be broken > this century. Assuming both a mild algorithmic reduction and quantum > computing, AES-256 looks secure until the next century, if not > longer.
You are referring to Grover's Algorithm. You have to make up some nonexistent quantum computing device with log(n) storage capacity. We are nowhere near actually constructing such a beast; to date, we have only solved the most trivial problems relating to quantum computers. Tell me about your plan to resolve quantum decoherence (just for starters), and I will start taking your boogeyman quantum computer attack seriously. Personally, I would rather be holding my breath for cold fusion.
> Also, AES-256 really only takes 40% longer than AES-128 for > practical purposes, since AES-128 has 10 rounds and AES-256 has 14 > rounds. Finally, AES-192 and AES-256 are authorized for TOP SECRET > classification, while AES-128 is not. That's a pretty big market > Fujitsu would be cutting out by only offering AES-128.
This is the only legitimate point you have brought up: marketing. Of course, that is exactly the point I originally brought up too.
It is always good to hear of storage device manufacturers embedding encryption into their products. However, after reading this article, there are at least three concerns I am left with regarding Fujitsu's offering, along with every other offering of this sort.
Firstly, AES-256 smacks of a marketing gimmick. AES-128 is perfectly sufficient for anything that anyone wishes to protect; nobody has ever discovered a weakness in AES-128 that would be cause for concern. Using AES-256 bloats the key size while providing absolutely no additional protection above and beyond what we already get from AES-128. Whenever I hear of a crypto product advertising AES-256, I am suspicious that the company is more concerned with marketing than it is with actually providing good level-headed security.
Secondly, how "hardware-based" is this product, really? More often than not, crypto modules are implemented in firmware, and sometimes they can be attacked, up to and including replacement of the microcode. Is this an open implementation? How do we know we can trust it? Is there any kind of key escrow going on? Is the chip using CBC mode while using a predictable IV? If so, then the drive may be susceptible to a chosen-plaintext attack. On Linux, we can directly inspect the code for TrueCrypt, dm-crypt, eCryptfs, EncFS, and so forth. The users, not the manufacturers, have complete control and transparent knowledge of exactly what is going on under the covers. How can we know we can trust the "hardware-based" implementation shipping on these drives?
Thirdly, the fact that "the key does not reside in the computer's memory" does not necessarily help you much. Perhaps the symmetric key used for the bulk encryption and decryption of what goes out to the disk sectors stays on the drive's processor chip, but what does that buy you in terms of real security? The entire crypto system needs to be evaluated around its weakest point, which is almost always key management. If the BIOS has to send a passphrase to the drive to "unlock" that on-chip key, then who really cares if it is using AES-256 or if it keeps the 256-bit key on the drive? An attacker only needs to attack the passphrase, which is typically significantly weaker than the 256-bit key, and then simply ask the drive to hand over its contents.
Some crypto protection is better than no protection at all, but we also do not want people to buy these drives and then have a false sense of security. Crypto, like any other form of security, is not really something you can bundle up and sell as a stand-alone product to customers. Security needs to be integrated into the entire system, because any individual component (such as an encrypting storage device) can be rendered completely ineffective if it can be circumvented by some action elsewhere in the system.
While we are on the topic of failing drives, I think it would be appropriate to include a warning about USB drives and warranties.
I purchased a 500GB Western Digital My Book about a year and a half ago. I figured that a pre-fab USB enclosed drive would somehow be more reliable than building one myself with a regular 3.5" internal drive and my own separately purchased USB enclosure (you may dock me points for irrational thinking there). Of course, I started getting the click-of-death about a month ago, and I was unpleasantly surprised to discover that the warranty on the drive was only for 1 year, rather than the 3 year warranty that I would have gotten for a regular 3.5" 500GB Western Digital drive at the time. Meanwhile, my 750GB Seagate drive in a AMS VENUS enclosure has been chugging along just fine, and if it fails sometime in the next four years, I will still be able to exchange it under warranty.
The moral of the story is that, when there is a difference in the warranty periods (i.e., 1 year vs. 5 years), it makes a lot more sense to build your own USB enclosed drive rather than order a pre-fab USB enclosed drive.
As has been pointed out many times before on Slashdot, copyright can only protect creative expressions, not ideas. To the extent that a copyright of a particular expression would be tantamount to copyrighting the idea, then one cannot legitimately claim copyright over the expression. If the expression is primarily functional in nature and if the only reasonable alternative representations of the idea are preposterous trivial modifications (e.g., change the colors of the map, make the lines dotted rather than solid, etc.), then that is a strong indication that the expression is substantially equivalent to the idea itself and is not candidate for copyright protection under U.S. law.
(Disclaimer: IANAL, but I did take a graduate law course on IP about a year ago. This post is not intended to be legal advice. Consult a licensed attorney in your jurisdiction for legal advice before you take any actions based on the conjectures contained in this post. Have a nice day.)
I signed up for Emerson's graduate course on model checking and reactive systems a couple of years back. The first day of class, he walked in 15 minutes late and said something like, "Welcome to my class. No homework or tests. Everyone gets an 'A'. Let's see what kind of papers we can come up with." He then dived right into some intense theory as if he were casually picking up a conversation he left off the semester before. I spent the next few hours feeling like total deadweight (several other grad students just sat there silent the whole time, with expressions on their faces like deer caught in headlights). I wound up just dropping the class; it took me another year of grad courses to get all the background theory I needed to just keep pace, and I hate wasting time, even for an easy 'A'. Too bad I graduated just before he taught his class again; I would have given it another shot before leaving UT Austin.
jimicus wrote: > Seeing as ClamAV doesn't have a daemon mode
The stackable filesystem team (the ones who wrote Unionfs) put together a filesystem that uses ClamAV to perform on-access virus scanning in the kernel.
In 2.6.24, eCryptfs overhauled its I/O mechanism with the lower filesystem (check out fs/ecryptfs/read_write.c). It used to directly manipulate the lower inode address mappings, which caused problems with certain filesystems like NFS (they like to be the only filesystems directly locking, reading, and writing their own address mappings). Now it opens a persistent lower file for each and every stacked inode and uses that for all I/O with the lower filesystem. This significantly decreases the complexity of the execution path for reading and writing the lower data. Together with this patch, eCryptfs now works pretty well on networked filesystems like NFS and CIFS.
There is another patch to provide HMAC integrity enforcement, and the kernel GIT tree for eCryptfs has a branch indicating that filename encryption is being worked on.
When Google provides a Linux filesystem (either native or via FUSE), people can use eCryptfs to prevent Google from reading the contents of their files. eCryptfs stacks on top of other filesystems and encrypts the data.
There exist effective techniques that can anonymize the data in order to thwart attempts to correlate identities, while still preserving the statistical properties of the data that make it useful to researchers. They include k-anonymity and l-diversity:
The paper makes reference to a O(2^23) time to compute the previous state, given any current state. Maybe I am being a bit pedantic, but any undergraduate CS major familiar with big-O notation could tell you that O(2^23)=O(1); authors should just drop O() when they want to communicate the static (input-independent) run time of an algorithm.
Unfortunately, your value is mostly in terms of negatives. How *few* bad things happened on your watch?
* Number of minutes that network services are unavailable and/or flaky for employees (local and remote)
* Number of spams that you let through
* Number of false positives by spam detection system
* Number of hours of lost employee productivity due to overhead imposed by IT department (system software compliance, hardware inventory accounting, etc.)
* Number of kilowatts wasted due to failure to use power-saving technology
* Number of intrusions by unauthorized persons into network
* Amount of sensitive information lost due to failure to encrypt or otherwise protect data
* Amount of information (and employee time) lost due to failure to keep good backups and have a good restore procedure in place
* Amount of money wasted on licenses for software, when less expensive and equally effective alternatives are available
* Amount of time wasted on unnecessary upgrades/updates
* Amount of time wasted by dealing with virus infections
* Amount of down-time when dealing with equipment failures
* Amount of time employees had to waste working around ineffective IT policies
The IT department is there to reduce costs as much as possible throughout the organization. Failures by the IT department can largely be measured by how much employee time and effort is lost throughout the organization when the employees have to focus on something other than their actual jobs.
> As per the bug report, theres a workaround. > > ("OffscreenRenderingMode"="fbo")
fbo gives you between a 30%-80% frame rate hit compared to pbuffer, depending on the complexity of what is being rendered at any point in the game. The best game play experience can be had on release 0.9.38 with pbuffer.
chaosite wrote: > Yes, it has gotten way better. > It has support for Direct3D, tons of winapi functions, etc... It's pretty awesome at this stage, really.
Oblivion, perhaps the most widely acclaimed game from last year, runs pretty well on Wine 0.9.38. Someone made changes to the DirectX thread-related code that causes Oblivion under Wine to crash for every version since. The lesson here is that the newest version of Wine is not necessarily the best one to use for any given application.
stevedcc wrote: > University networks are not like work networks. You can't enforce > a standard set of tools and be sure that no one needs to run > anything else
If by ``work networks'' you mean industrial software development environments -- well, you also can't enforce a standard set of tools. Let me put it this way: I really hope management over at my *competitors* lock down their engineering team's tool set, since that would give my group, which has no such artificial restrictions on software tools we can use (so long as everythings's okay with the license), a significant competitive advantage.
I play Oblivion using Wine on Gentoo. With a some.ini file tweakage (all spelled out at the uesp.net wiki), I actually get a better gaming experience under Linux than Windows. Surprisingly, this is mainly due to the fact that the Linux device drivers perform better than the Windows device drivers for my hardware.
Under Windows, the audio drivers for my built-in audio chipset (ICH8) on an Intel DG965 mainboard have trouble mixing multiple channels; the audio stutters when casting spells, for instance. Also, the gameplay is smoother under Linux than it is under Windows; I suspect this may be due to the IDE block device drivers for the DG965 board's controller, since the stuttering seems to coincide with disk access (DMA problems?). None of these hardware-related issues show up under Linux; all the audio plays without stuttering, and the gameplay is much smoother. This is all using the device drivers that ship in the mainline Linux kernel; no mucking with any drivers is necessary.
Of course, there are problems with Wine. Any version past 0.9.38 either does not work at all or crashes when you're running around in an outdoor part of the game. Trees sometimes render strangely; it seems that one of the vertices of some of the leaf objects is at the bottom-left corner of the screen, so sometimes streaks of tree leaves go across the screen. Water cannot render at more than a few frames a second, and refraction effects can make everything turn puke yellow/green. Most of these issues can be worked around by disabling the effects in the.ini file, but you have to go through the trouble of setting all that up, and you have to be willing to live without a few graphics effects.
Overall, there are problems with running Oblivion under Windows and under Linux+Wine, but I would rather live with the problems I am having under Linux rather than the problems I was having under Windows. Frankly, I am amazed that the Wine folks have managed to get something like oblivion running as well as it does.
Slashdot Mirror
One tweak to maximize safety in these cases:
If other car is close behind
reduce speed in proportion to how close it is
Endif
That's the algorithm I go with when driving. It's saved my bacon a few times.
I don't want people who aren't invested enough* to go to a poll to decide policies that affect my life.
(*modulo people with disabilities or who have work conflicts, but we already have mechanisms in place to account for that -- I'm talking about the general issue of lowering the bar too much)
MBGMorden (803437) wrote:
> Truthfully given how limited my scope of gaming is these days Linux
> could PROBABLY serve all my needs if there were a good WoW (and
> Ventrilo) client for it.
For the record, I leveled a priest all the way to level 70 on
WINE/Gentoo. Never had a single crash. Ventrilo on WINE works fine for
me too.
I work in a corporate culture where if you are not available via
instant messaging, many perceive is that you are not really working at
the time. I know several people who wake up in the morning and the
first thing they do is connect via the VPN to get their instant
messaging client running so that their bosses and coworkers think
they are working diligently. I work best by batching tasks via email
messages, so I make it clear to people to just send me an email and I
will get back to them within a day or so. This does not work for some
people; one person in my organization will try instant messaging me
and calling my office phone, but he will not bother to send me an
email, and then he will later complain that he cannot communicate with
me.
As a software engineer, I remain productive by having several hours of
uninterrupted time to focus on a particular task at hand. When the
code builds, installs, tests, and is in the repo ready for the next
release, then I am ready to move on to the next task, like check my
email, which I do maybe two or three times a day. I am able to give my
code the due attention it deserves, and I can concentrate on not
making coding mistakes by keeping the entire code context "swapped in"
my head while I am working on it. During that time, invariably some
project manager somewhere is panicking about a status report or some
other overhead and is trying to get me to update a bug ticket or
something. Usually, by the time I read his frantic email about the
status report, I have already fixed the problem that he wants status
on because I was able to focus on it without interruption.
Most people eventually figure out that they get good consistent work
from me regardless of the fact that they cannot interrupt me freely at
any time, like most other employees in my organization. I do wish that
more of my coworkers would take a more proactive stance on not letting
themselves get interrupted all the time, since I see first-hand the
negative impact it has on their ability to function. I get annoyed
when I am trying to talk to my boss during a meeting and he stammers
right in the middle of an important discussion with, "Uh, wait, I just
got am IM, I, uh, need to, uh, just a second, let me think..."
> introducing random jitter would go some way to subverting this, no?
Exactly. I took a few minutes to glance over the paper. Their feature
extraction stage consists of two predictable attributes: packet size
and time between packets. Modifying the traffic sent at the
application layer (SSH itself does not even need to be touched) can
trivially ambiguate the extracted features so as to throw off the
classification attempt. This is simply a road bump; as soon as it gets
into use, application-layer proxies will pop up to circumvent it.
They also seemed to have inventented their own home-brew statistical
analysis. I was disappointed that they did not go into detail as to
why they largely ignored the entire field of Machine Learning
(NaiveBayes? Perceptron? kNN? Why not try using these?) when coming up
with their classification model.
Red Hat is making strides with adopting data-at-rest encryption. RHEL 5.2 now includes eCryptfs as a technology preview.
http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.2/html/Release_Notes/RELEASE-NOTES-U2-x86-en.html
http://ecryptfs.sf.net/
I just got a call from my mother last night. She is running Ubuntu on
her ThinkPad, and she absolutely loves it. She spends 99% of the time
at home using her own wireless network, and there are no problems at
all. Running Ubuntu on her laptop solves more problems than it causes,
since she is the kind of person who double-clicks on random crap
people forward to her. For stuff she absolutely has to do in other
operating systems, she runs KVM+QEMU. I have her system set up to SSH
into my own box on the rare occasion that I have to connect remotely
and install something (happens maybe once every two months).
Last night though, she was at a hotel, and she wanted to connect to
the hotel's wireless network. Through many years of experience with
Linux distro's and wireless devices, I told her right off the bat that
she had about a 50% chance of actually connecting with a reasonable
about of time and effort. The wireless device was in Roaming mode, and
that obviously was not working. So, she went ahead and selected the
hotel's ESSID, chose DHCP, and then activated the wireless
device. Does she need a WPA key? Who knows; the interface in Ubuntu is
mum on whether or not it is in the clear. Well, of course, it did not
work. And of course, I was not the least bit surprised.
We both had much better things to do with our time than to struggle
with iwlist, iwconfig, and ifconfig settings in an xterm over the
phone, so I just told her that she would have to wait to get home to
connect back up to the Internet.
The vast majority of folks out there really just want to use the web
for their computing tasks. The whole computer is quite literally a
"web interface" device. The desktop-ability of the device rests almost
entirely on its ability to actually connect to the Internet.
My own personal experience over the years with numerous wireless
devices (iwl4965, prism, atheros, etc.) has left me a bit disappointed
in the vendors in terms of driver features and quality. The wireless
setup utilities in Ubuntu and Fedora are okay, but they could be a
little more informative about is actually going on so I do not have to
drop to an xterm to dork around ("Okay, so exactly why don't I have an
IP address now? Are DHCP packets actually making it out, or what?").
If I could pick any one top-priority problem still facing the entire
Linux package today, it would be wireless connectivity to the
Internet. My mother needs to be able to walk into a hotel, turn on her
laptop, and, with little or no effort, just get a link to the
Internet. She should never have to call someone to figure out how to
get to her gmail account. Maybe scan the AP's on boot and have a
wizard pop up when it detects a change in the wireless environment or
something of the sort.
I have a friend to works at Canonical, so maybe it would be more
effective to ping him on this than to rant on Slashdot. Just had to
get this off my chest though.
> The NSA disagrees with you.
Due to the key management issues I brought up, I disagree with
using these storage devices as adequate means for protecting
anything near top secret. No use putting a titanium padlock on a
cardboard box.
> Two possibilities: We've seen dramatic weaknesses in md5 and sha1,
> and it's not impossible that something similar could be found for
> AES.
MD5 and SHA1 are one-way hashes. AES is a symmetric cipher. The
weaknesses found in MD5 and SHA1 have nothing to do with
AES. Weaknesses have been found in symmetric ciphers like Skipjack,
however, and that would have been an appropriate example.
> A reduction from 128 bit security to ~96 or even ~64 bits of
> security would be a relative disaster; 64-bit ciphers are simply not
> secure anymore.
A reduction from 256 bits to 96 bits would also be a disaster. So long
as we are spreading FUD about an imaginary attack against AES-128,
why not go all the way to AES-256?
We have discovered absolutely no cause to be concerned about a
possible reduction of the effective key length of AES, regardless of
whether it is 256 bits or 128 bits. Until we get some sort of
indication that perhaps this might be a possibility (we need this
thing scientists like to call ``evidence''), we can say with some
degree of confidence that AES-128 really provides 128-bit key
protection.
> Additionally, quantum computers can theoretically break symmetric
> ciphers in sqrt(n) time, which means that AES-128 could be broken
> this century. Assuming both a mild algorithmic reduction and quantum
> computing, AES-256 looks secure until the next century, if not
> longer.
You are referring to Grover's Algorithm. You have to make up
some nonexistent quantum computing device with log(n) storage
capacity. We are nowhere near actually constructing such a beast; to
date, we have only solved the most trivial problems relating to
quantum computers. Tell me about your plan to resolve quantum
decoherence (just for starters), and I will start taking your
boogeyman quantum computer attack seriously. Personally, I would
rather be holding my breath for cold fusion.
> Also, AES-256 really only takes 40% longer than AES-128 for
> practical purposes, since AES-128 has 10 rounds and AES-256 has 14
> rounds. Finally, AES-192 and AES-256 are authorized for TOP SECRET
> classification, while AES-128 is not. That's a pretty big market
> Fujitsu would be cutting out by only offering AES-128.
This is the only legitimate point you have brought up: marketing. Of
course, that is exactly the point I originally brought up too.
It is always good to hear of storage device manufacturers embedding
encryption into their products. However, after reading this article,
there are at least three concerns I am left with regarding Fujitsu's
offering, along with every other offering of this sort.
Firstly, AES-256 smacks of a marketing gimmick. AES-128 is perfectly
sufficient for anything that anyone wishes to protect; nobody has ever
discovered a weakness in AES-128 that would be cause for
concern. Using AES-256 bloats the key size while providing absolutely
no additional protection above and beyond what we already get from
AES-128. Whenever I hear of a crypto product advertising AES-256, I am
suspicious that the company is more concerned with marketing than it
is with actually providing good level-headed security.
Secondly, how "hardware-based" is this product, really? More often
than not, crypto modules are implemented in firmware, and sometimes
they can be attacked, up to and including replacement of the
microcode. Is this an open implementation? How do we know we can trust
it? Is there any kind of key escrow going on? Is the chip using CBC
mode while using a predictable IV? If so, then the drive may be
susceptible to a chosen-plaintext attack. On Linux, we can directly
inspect the code for TrueCrypt, dm-crypt, eCryptfs, EncFS, and so
forth. The users, not the manufacturers, have complete control and
transparent knowledge of exactly what is going on under the
covers. How can we know we can trust the "hardware-based"
implementation shipping on these drives?
Thirdly, the fact that "the key does not reside in the computer's
memory" does not necessarily help you much. Perhaps the symmetric key
used for the bulk encryption and decryption of what goes out to the
disk sectors stays on the drive's processor chip, but what does that
buy you in terms of real security? The entire crypto system needs to
be evaluated around its weakest point, which is almost always key
management. If the BIOS has to send a passphrase to the drive to
"unlock" that on-chip key, then who really cares if it is using
AES-256 or if it keeps the 256-bit key on the drive? An attacker only
needs to attack the passphrase, which is typically significantly
weaker than the 256-bit key, and then simply ask the drive to hand
over its contents.
Some crypto protection is better than no protection at all, but we
also do not want people to buy these drives and then have a false
sense of security. Crypto, like any other form of security, is not
really something you can bundle up and sell as a stand-alone product
to customers. Security needs to be integrated into the entire system,
because any individual component (such as an encrypting storage
device) can be rendered completely ineffective if it can be
circumvented by some action elsewhere in the system.
While we are on the topic of failing drives, I think it would be appropriate to include a warning about USB drives and warranties.
I purchased a 500GB Western Digital My Book about a year and a half ago. I figured that a pre-fab USB enclosed drive would somehow be more reliable than building one myself with a regular 3.5" internal drive and my own separately purchased USB enclosure (you may dock me points for irrational thinking there). Of course, I started getting the click-of-death about a month ago, and I was unpleasantly surprised to discover that the warranty on the drive was only for 1 year, rather than the 3 year warranty that I would have gotten for a regular 3.5" 500GB Western Digital drive at the time. Meanwhile, my 750GB Seagate drive in a AMS VENUS enclosure has been chugging along just fine, and if it fails sometime in the next four years, I will still be able to exchange it under warranty.
The moral of the story is that, when there is a difference in the warranty periods (i.e., 1 year vs. 5 years), it makes a lot more sense to build your own USB enclosed drive rather than order a pre-fab USB enclosed drive.
As has been pointed out many times before on Slashdot, copyright can only protect creative expressions, not ideas. To the extent that a copyright of a particular expression would be tantamount to copyrighting the idea, then one cannot legitimately claim copyright over the expression. If the expression is primarily functional in nature and if the only reasonable alternative representations of the idea are preposterous trivial modifications (e.g., change the colors of the map, make the lines dotted rather than solid, etc.), then that is a strong indication that the expression is substantially equivalent to the idea itself and is not candidate for copyright protection under U.S. law.
(Disclaimer: IANAL, but I did take a graduate law course on IP about a year ago. This post is not intended to be legal advice. Consult a licensed attorney in your jurisdiction for legal advice before you take any actions based on the conjectures contained in this post. Have a nice day.)
I signed up for Emerson's graduate course on model checking and reactive systems a couple of years back. The first day of class, he walked in 15 minutes late and said something like, "Welcome to my class. No homework or tests. Everyone gets an 'A'. Let's see what kind of papers we can come up with." He then dived right into some intense theory as if he were casually picking up a conversation he left off the semester before. I spent the next few hours feeling like total deadweight (several other grad students just sat there silent the whole time, with expressions on their faces like deer caught in headlights). I wound up just dropping the class; it took me another year of grad courses to get all the background theory I needed to just keep pace, and I hate wasting time, even for an easy 'A'. Too bad I graduated just before he taught his class again; I would have given it another shot before leaving UT Austin.
jimicus wrote:
> Seeing as ClamAV doesn't have a daemon mode
The stackable filesystem team (the ones who wrote Unionfs) put together a filesystem that uses ClamAV to perform on-access virus scanning in the kernel.
In 2.6.24, eCryptfs overhauled its I/O mechanism with the lower filesystem (check out fs/ecryptfs/read_write.c). It used to directly manipulate the lower inode address mappings, which caused problems with certain filesystems like NFS (they like to be the only filesystems directly locking, reading, and writing their own address mappings). Now it opens a persistent lower file for each and every stacked inode and uses that for all I/O with the lower filesystem. This significantly decreases the complexity of the execution path for reading and writing the lower data. Together with this patch, eCryptfs now works pretty well on networked filesystems like NFS and CIFS.
There is another patch to provide HMAC integrity enforcement, and the kernel GIT tree for eCryptfs has a branch indicating that filename encryption is being worked on.
> > Chuck Norris does NOT post, the threads post to Him!
> Except for Soviet Russia, where the second reversal makes things normal again.
In Soviet Russia, Chuck Norris is still Chuck Norris.
When Google provides a Linux filesystem (either native or via FUSE), people can use eCryptfs to prevent Google from reading the contents of their files. eCryptfs stacks on top of other filesystems and encrypts the data.
There exist effective techniques that can anonymize the data in order to thwart attempts to correlate identities, while still preserving the statistical properties of the data that make it useful to researchers. They include k-anonymity and l-diversity:
http://privacy.cs.cmu.edu/people/sweeney/kanonymity.html
http://www.cs.cornell.edu/~dkifer/papers/ldiversity.pdf
The paper makes reference to a O(2^23) time to compute the previous state, given any current state. Maybe I am being a bit pedantic, but any undergraduate CS major familiar with big-O notation could tell you that O(2^23)=O(1); authors should just drop O() when they want to communicate the static (input-independent) run time of an algorithm.
To have a filesystem transparently encrypt individual files for you on Linux, use eCryptfs. It's now part of every major distro.
Unfortunately, your value is mostly in terms of negatives. How *few* bad things happened on your watch?
* Number of minutes that network services are unavailable and/or flaky for employees (local and remote)
* Number of spams that you let through
* Number of false positives by spam detection system
* Number of hours of lost employee productivity due to overhead imposed by IT department (system software compliance, hardware inventory accounting, etc.)
* Number of kilowatts wasted due to failure to use power-saving technology
* Number of intrusions by unauthorized persons into network
* Amount of sensitive information lost due to failure to encrypt or otherwise protect data
* Amount of information (and employee time) lost due to failure to keep good backups and have a good restore procedure in place
* Amount of money wasted on licenses for software, when less expensive and equally effective alternatives are available
* Amount of time wasted on unnecessary upgrades/updates
* Amount of time wasted by dealing with virus infections
* Amount of down-time when dealing with equipment failures
* Amount of time employees had to waste working around ineffective IT policies
The IT department is there to reduce costs as much as possible throughout the organization. Failures by the IT department can largely be measured by how much employee time and effort is lost throughout the organization when the employees have to focus on something other than their actual jobs.
> As per the bug report, theres a workaround.
>
> ("OffscreenRenderingMode"="fbo")
fbo gives you between a 30%-80% frame rate hit compared to pbuffer, depending on the complexity of what is being rendered at any point in the game. The best game play experience can be had on release 0.9.38 with pbuffer.
chaosite wrote:
> Yes, it has gotten way better.
> It has support for Direct3D, tons of winapi functions, etc... It's pretty awesome at this stage, really.
Oblivion, perhaps the most widely acclaimed game from last year, runs pretty well on Wine 0.9.38. Someone made changes to the DirectX thread-related code that causes Oblivion under Wine to crash for every version since. The lesson here is that the newest version of Wine is not necessarily the best one to use for any given application.
stevedcc wrote:
> University networks are not like work networks. You can't enforce
> a standard set of tools and be sure that no one needs to run
> anything else
If by ``work networks'' you mean industrial software development
environments -- well, you also can't enforce a standard set of tools.
Let me put it this way: I really hope management over at my
*competitors* lock down their engineering team's tool set, since
that would give my group, which has no such artificial restrictions
on software tools we can use (so long as everythings's okay with the
license), a significant competitive advantage.
I play Oblivion using Wine on Gentoo. With a some .ini file tweakage (all spelled out at the uesp.net wiki), I actually get a better gaming experience under Linux than Windows. Surprisingly, this is mainly due to the fact that the Linux device drivers perform better than the Windows device drivers for my hardware.
.ini file, but you have to go through the trouble of setting all that up, and you have to be willing to live without a few graphics effects.
Under Windows, the audio drivers for my built-in audio chipset (ICH8) on an Intel DG965 mainboard have trouble mixing multiple channels; the audio stutters when casting spells, for instance. Also, the gameplay is smoother under Linux than it is under Windows; I suspect this may be due to the IDE block device drivers for the DG965 board's controller, since the stuttering seems to coincide with disk access (DMA problems?). None of these hardware-related issues show up under Linux; all the audio plays without stuttering, and the gameplay is much smoother. This is all using the device drivers that ship in the mainline Linux kernel; no mucking with any drivers is necessary.
Of course, there are problems with Wine. Any version past 0.9.38 either does not work at all or crashes when you're running around in an outdoor part of the game. Trees sometimes render strangely; it seems that one of the vertices of some of the leaf objects is at the bottom-left corner of the screen, so sometimes streaks of tree leaves go across the screen. Water cannot render at more than a few frames a second, and refraction effects can make everything turn puke yellow/green. Most of these issues can be worked around by disabling the effects in the
Overall, there are problems with running Oblivion under Windows and under Linux+Wine, but I would rather live with the problems I am having under Linux rather than the problems I was having under Windows. Frankly, I am amazed that the Wine folks have managed to get something like oblivion running as well as it does.