I do not use igoogle, either, but when I looked at my page, it looks a lot better and more usable than before. It is also faster, since it doesn't load everything right at the beginning, nor reload everything when you choose a different view. I don't see what is the big deal.
I have a 1.60GHz processor from three years ago, and flash "only" uses about 60% of my CPU time. I couldn't imagine it being capable of running on anything lower end. It's such a fat program...
Honestly, I didn't know Real was still around. I wouldn't let that software near my windows machines, much less the Linux ones.
It's funny, actually, but the Linux version of RealPlayer is not loaded with garbage. It just looks like a vanilla video player. It is not at all like the Windows version.
Also, quantum key exchange doesn't really protect against man-in-the-middle attacks. It promisses to do that, but doesn't deliver.
This is true. I remember reading an article about that a while back which said something to the effect that making an imperfect copy of the message allows a man-in-the-middle attack. I don't remember the details, though.
Unfortunately, that is vulnerable to man-in-the-middle attacks.
A tries to connect to B. C is a router in between. C pretends to be B when talking to A and pretends to be A when talking to B.
The result: A has connected securely to C and C has connected securely to B. A and B, however, think that they are securely connected to each other, while C secretly collects as much information as it wants.
Attempted solutions to this include using signatures, since those cannot (feasibly) be forged. However, if the man-in-the-middle attack is elaborate enough, C can also pretend to be the signature registrar. In this scenario, C simply signs with its own signature, and then when A queries it for the information it needs to check the signature, C gives A its own information, so the signatures match.
There is no way around this without using some alternative and fully trusted method of getting the key from B to A. With man-in-the-middle and public-key cryptography, A receives a public key, but it might not actually be B's public key. The whole idea with WPA and WEP is that you have to physically enter the key at both ends. Since you have physically seen and changed both ends, you know that the communication is actually between these two devices.
Another method of secure key sharing is quantum cryptography, because an eavesdropper has cannot listen without destroying data. Even in that case, both ends have physically been set up to communicate with each other, so there is no doubt as to whether there is a man-in-the-middle. On the web, there most certainly is a man-in-the-middle. In fact, there are many. Every router between A and B is a potential eavesdropper.
In short, the answer to your question is that, no, there is no wisdom in salting SALT with the current timestamp.
I originally thought of doing this as the primary method of salting SECRET, but then I thought that transmitting SALT would be a much better idea.
Here's why: Think about it. Where does the timestamp come from? A time server, most likely. Or, more directly, from the network to which you are connected.
Using the timestamp requires that the clocks of the router and your wireless card be synchronized, thus meaning that you must get the timestamp from the network to which you are connected.
So, why should you let the attacker be able to predict what SALT is going to be (assuming that SALT=timestamp)? In either case, SALT originally comes from the router. It is just a matter of the predictability of the value of SALT.
Also, another argument against the use of timestamps in general for salting passwords: It requires that the times be absolutely synchronized. They cannot even be off slightly, especially if you need to have five nines of uptime when connected to the network. The reason for this is that, even if you only use the hours to salt and the clocks are only off by a second, you lose that second because during that time, the encryption keys are different.
Assuming that the difference is one second per hour, you now only have about four nines of uptime assuming that you never have any other problems (probably an unlikely scenario).
[This is where someone else who knows something about crypto chimes in... I just know this because I'd seen someone else getting called out on this misconception.]
W007! I actually do know something about crypto (as well as number theory, which is useful and fun).
You are right about the fact that, if SALT were transmitted through plaintext every time, it would only be a matter of time before SECRET would be able to be deduced (assuming that the method of breaking the overall WPA encryption allows you to figure out the encryption key being used [I don't know too much about WPA in particular, so I'm not sure if it is public key or not]).
I should have been clearer. Every XX minutes, a different SALT is transmitted via ciphertext.
This increases the complexity of the problem significantly:
You must break the first encryption key and gain the full key. The key looks something like: a8fbcd1db5a6bf013763fd45a32f2b319bfba413
You must break the second encryption key. Again, the key looks something like: 216cd69e6e4112b6adffec1853ae415b0fa45fcf
[Wash, rinse, repeat]
You eventually have enough keys lined up to figure out that they use the sha1sum and all start with "this is insanity ", therefore SECRET="this is insanity ".
The problem is that you have to break the encryption scheme enough times to gain enough keys to establish what SECRET is. Then you have to break the hash. If it is a particularly good hash (i.e. NOT MD5 OR SHA1!) and the key that you are hashing has sufficient entropy (i.e. consists of random data) then you shouldn't be able to break the hash using a rainbow table, and brute force might be necessary.
Now, you can always try to mathematically find a flaw in the hash or encryption scheme, but that is a different problem. Personally, I wouldn't trust an encryption scheme designed by someone else unless I had the mathematical background to prove it, which, in the case of RSA, I do. Therefore, I would use RSA with as large a key and block size as is feasible. I'd probably also write my own implementation.
(I must confess, though, that the implementation I wrote to which I have linked is not by any means secure as it stands. It is also probably buggy, as I spent maybe half an hour on it at most. Someone commented on another recipe that writing RSA should be simple, and so I took the opportunity to write it.)
I think that the way I would do it would be as follows:
Have a secret key SECRET. SECRET is never directly used.
When you first initiate the connection, you ask the wireless network for the current salt, SALT in plaintext.
You then use a very secure hash (I think that the one that I wrote a while ago is probably secure enough, though this is an unwarranted assumption, as I haven't shown it to any security experts) and take the hash of SECRET salted with SALT. You use the hash value as the key.
Every XX minutes, SALT changes. Therefore the key changes. However, someone cannot get the new key even if they have broken the old key because they need the SECRET as well as the current salt.
The way to break this would be to break the hash, but with a sufficiently strong hash, that should be difficult to do in a reasonable amount of time, especially if SECRET and SALT are very long.
Trouble is, the second part is why the won't work, because nobody is going to take a karma hit for moderating.
The specifics of it could always be figured out later. Perhaps not having it affect karma so much as how often the person is able to moderate would be a better system.
That way, no karma hit, and better moderators get to moderate more.
Any idea how we would get this idea to the administrators?
Actually, the only difference between "Ubuntu Server Edition" and the "regular" Desktop version is which packages get installed by default.
This isn't entirely true. The server edition also has an optimized kernal, though you'd have to go to the website to find out the exact specifications that they optimize it to. I think that it is something like better utilizing more memory and multiple cores. I think that virtualization is also improved for the server version.
These are things that you might not necessarily want on a desktop computer.
That said, you can make the server edition act like the desktop edition by installing one of kubuntu-desktop/ubuntu-desktop/xubuntu-desktop (others?) in order to get a desktop environment.
I wouldn't go that far, but I think that it might be a good idea to implement a +1 Agree -1 Disagree options for mods and then not let that moderation affect the overall score of the post. This sort of moderation could be used purely for the internal value of karma (of the moderator, not of the post being moderated).
I hope I am making sense.
I think that this option for moderation would filter out those who moderate for Agree/Disagree by giving them that option and then not counting it. Those who use it should be penalized in their karma score, as the guidelines of moderation clearly state that they should not moderate for Agree/Disagree.
I'm not sure what it would take to get it written into law, but I have some sort of idea how a precedent could be set:
I'm hoping that someone starts a project based on it and releases it under a different license on the basis that the government is not allowed to hold copyright. Hopefully this person will be a good lawyer or at least be able to afford one. Then, if the government sues said person, hopefully said person will win in court.
From the description, it sounds like a fork is getting all the monetary attention - not unheard of.
Mod parent up.
This is, in fact, the whole purpose of open-sourcing something. It makes it so that somebody who has a better idea can implement it. If that idea is incompatible with the original project or not accepted by the project owners, the party with the better idea forks, and a new project is formed. If that project is legitimately better, it will be the one that gets monetary support.
One problem with that, though, is that the game publishers will not tell you that their games are deliberately buggy and defective by design. However, if the game comes with DRM, that is a good sign that the developers of the game distrust you.
I've always found it odd that my school managed to get the computers in the computer lab to log in and be usable instantly (they run Windows XP). However, all the other computers in the school (also running the same OS) take about a minute to be usable, but are still better than any home edition of XP that I have used. Maybe this has something to do with logging into a network session?
Although I doubt that they will, I hope that they close the iTunes store and cause everybody who bought songs on it grief. It is nothing against them, but it would be a rude awakening to those who think nothing of DRM. In the long run, it would (hopefully) lead to its death, eventually.
You do know, of course, that the majority of spamming computers in the US are part of the botnets controlled by the Russian mafia, right [citation needed]?
The scheme is not impossible, just impractical. Most (non-nerd) people cannot be bothered installing software to compute keys. Also, the amount of computing time necessary becomes negligible once you have enormous botnets, like the Russian mafia.
Slashdot Mirror
I do not use igoogle, either, but when I looked at my page, it looks a lot better and more usable than before. It is also faster, since it doesn't load everything right at the beginning, nor reload everything when you choose a different view. I don't see what is the big deal.
I think the full command is /
rm -rf
and that allows you to convert all your *.rm files into a real video format, instead of a RealVideo format.
What are your specs?
I have a 1.60GHz processor from three years ago, and flash "only" uses about 60% of my CPU time. I couldn't imagine it being capable of running on anything lower end. It's such a fat program...
Honestly, I didn't know Real was still around. I wouldn't let that software near my windows machines, much less the Linux ones.
It's funny, actually, but the Linux version of RealPlayer is not loaded with garbage. It just looks like a vanilla video player. It is not at all like the Windows version.
http://savannah.nongnu.org/projects/ampu
:)
Contribute
I wish I had mod points...
No, because BSD is dead.
Also, quantum key exchange doesn't really protect against man-in-the-middle attacks. It promisses to do that, but doesn't deliver.
This is true. I remember reading an article about that a while back which said something to the effect that making an imperfect copy of the message allows a man-in-the-middle attack. I don't remember the details, though.
I stand corrected. Thank you.
Unfortunately, that is vulnerable to man-in-the-middle attacks.
A tries to connect to B.
C is a router in between.
C pretends to be B when talking to A and pretends to be A when talking to B.
The result:
A has connected securely to C and C has connected securely to B. A and B, however, think that they are securely connected to each other, while C secretly collects as much information as it wants.
Attempted solutions to this include using signatures, since those cannot (feasibly) be forged. However, if the man-in-the-middle attack is elaborate enough, C can also pretend to be the signature registrar. In this scenario, C simply signs with its own signature, and then when A queries it for the information it needs to check the signature, C gives A its own information, so the signatures match.
There is no way around this without using some alternative and fully trusted method of getting the key from B to A. With man-in-the-middle and public-key cryptography, A receives a public key, but it might not actually be B's public key. The whole idea with WPA and WEP is that you have to physically enter the key at both ends. Since you have physically seen and changed both ends, you know that the communication is actually between these two devices.
Another method of secure key sharing is quantum cryptography, because an eavesdropper has cannot listen without destroying data. Even in that case, both ends have physically been set up to communicate with each other, so there is no doubt as to whether there is a man-in-the-middle. On the web, there most certainly is a man-in-the-middle. In fact, there are many. Every router between A and B is a potential eavesdropper.
</paranoia>
In short, the answer to your question is that, no, there is no wisdom in salting SALT with the current timestamp.
I originally thought of doing this as the primary method of salting SECRET, but then I thought that transmitting SALT would be a much better idea.
Here's why:
Think about it. Where does the timestamp come from? A time server, most likely. Or, more directly, from the network to which you are connected.
Using the timestamp requires that the clocks of the router and your wireless card be synchronized, thus meaning that you must get the timestamp from the network to which you are connected.
So, why should you let the attacker be able to predict what SALT is going to be (assuming that SALT=timestamp)? In either case, SALT originally comes from the router. It is just a matter of the predictability of the value of SALT.
Also, another argument against the use of timestamps in general for salting passwords:
It requires that the times be absolutely synchronized. They cannot even be off slightly, especially if you need to have five nines of uptime when connected to the network. The reason for this is that, even if you only use the hours to salt and the clocks are only off by a second, you lose that second because during that time, the encryption keys are different.
Assuming that the difference is one second per hour, you now only have about four nines of uptime assuming that you never have any other problems (probably an unlikely scenario).
[This is where someone else who knows something about crypto chimes in... I just know this because I'd seen someone else getting called out on this misconception.]
W007! I actually do know something about crypto (as well as number theory, which is useful and fun).
You are right about the fact that, if SALT were transmitted through plaintext every time, it would only be a matter of time before SECRET would be able to be deduced (assuming that the method of breaking the overall WPA encryption allows you to figure out the encryption key being used [I don't know too much about WPA in particular, so I'm not sure if it is public key or not]).
I should have been clearer. Every XX minutes, a different SALT is transmitted via ciphertext.
This increases the complexity of the problem significantly:
You must break the first encryption key and gain the full key. The key looks something like:
a8fbcd1db5a6bf013763fd45a32f2b319bfba413
You must break the second encryption key. Again, the key looks something like:
216cd69e6e4112b6adffec1853ae415b0fa45fcf
[Wash, rinse, repeat]
You eventually have enough keys lined up to figure out that they use the sha1sum and all start with "this is insanity ", therefore SECRET="this is insanity ".
The problem is that you have to break the encryption scheme enough times to gain enough keys to establish what SECRET is. Then you have to break the hash. If it is a particularly good hash (i.e. NOT MD5 OR SHA1!) and the key that you are hashing has sufficient entropy (i.e. consists of random data) then you shouldn't be able to break the hash using a rainbow table, and brute force might be necessary.
Now, you can always try to mathematically find a flaw in the hash or encryption scheme, but that is a different problem. Personally, I wouldn't trust an encryption scheme designed by someone else unless I had the mathematical background to prove it, which, in the case of RSA, I do. Therefore, I would use RSA with as large a key and block size as is feasible. I'd probably also write my own implementation.
(I must confess, though, that the implementation I wrote to which I have linked is not by any means secure as it stands. It is also probably buggy, as I spent maybe half an hour on it at most. Someone commented on another recipe that writing RSA should be simple, and so I took the opportunity to write it.)
I think that the way I would do it would be as follows:
Have a secret key SECRET. SECRET is never directly used.
When you first initiate the connection, you ask the wireless network for the current salt, SALT in plaintext.
You then use a very secure hash (I think that the one that I wrote a while ago is probably secure enough, though this is an unwarranted assumption, as I haven't shown it to any security experts) and take the hash of SECRET salted with SALT. You use the hash value as the key.
Every XX minutes, SALT changes. Therefore the key changes. However, someone cannot get the new key even if they have broken the old key because they need the SECRET as well as the current salt.
The way to break this would be to break the hash, but with a sufficiently strong hash, that should be difficult to do in a reasonable amount of time, especially if SECRET and SALT are very long.
Trouble is, the second part is why the won't work, because nobody is going to take a karma hit for moderating.
The specifics of it could always be figured out later. Perhaps not having it affect karma so much as how often the person is able to moderate would be a better system.
That way, no karma hit, and better moderators get to moderate more.
Any idea how we would get this idea to the administrators?
Actually, the only difference between "Ubuntu Server Edition" and the "regular" Desktop version is which packages get installed by default.
This isn't entirely true. The server edition also has an optimized kernal, though you'd have to go to the website to find out the exact specifications that they optimize it to. I think that it is something like better utilizing more memory and multiple cores. I think that virtualization is also improved for the server version.
These are things that you might not necessarily want on a desktop computer.
That said, you can make the server edition act like the desktop edition by installing one of kubuntu-desktop/ubuntu-desktop/xubuntu-desktop (others?) in order to get a desktop environment.
I wouldn't go that far, but I think that it might be a good idea to implement a +1 Agree -1 Disagree options for mods and then not let that moderation affect the overall score of the post. This sort of moderation could be used purely for the internal value of karma (of the moderator, not of the post being moderated).
I hope I am making sense.
I think that this option for moderation would filter out those who moderate for Agree/Disagree by giving them that option and then not counting it. Those who use it should be penalized in their karma score, as the guidelines of moderation clearly state that they should not moderate for Agree/Disagree.
Mod parent up.
Not that doing so will actually effect change in the naming scheme...
(Oh, and I'm forgetting that there is no +1 Agree and -1 Disagree. Bummer.)
I'm not sure what it would take to get it written into law, but I have some sort of idea how a precedent could be set:
I'm hoping that someone starts a project based on it and releases it under a different license on the basis that the government is not allowed to hold copyright. Hopefully this person will be a good lawyer or at least be able to afford one. Then, if the government sues said person, hopefully said person will win in court.
My $0.02
From the description, it sounds like a fork is getting all the monetary attention - not unheard of.
Mod parent up.
This is, in fact, the whole purpose of open-sourcing something. It makes it so that somebody who has a better idea can implement it. If that idea is incompatible with the original project or not accepted by the project owners, the party with the better idea forks, and a new project is formed. If that project is legitimately better, it will be the one that gets monetary support.
I see nothing wrong here.
Mod parent up insightful!
One problem with that, though, is that the game publishers will not tell you that their games are deliberately buggy and defective by design. However, if the game comes with DRM, that is a good sign that the developers of the game distrust you.
I've always found it odd that my school managed to get the computers in the computer lab to log in and be usable instantly (they run Windows XP). However, all the other computers in the school (also running the same OS) take about a minute to be usable, but are still better than any home edition of XP that I have used. Maybe this has something to do with logging into a network session?
Either way, anti-DRM wins!
Although I doubt that they will, I hope that they close the iTunes store and cause everybody who bought songs on it grief. It is nothing against them, but it would be a rude awakening to those who think nothing of DRM. In the long run, it would (hopefully) lead to its death, eventually.
Mod parent up funny!
You do know, of course, that the majority of spamming computers in the US are part of the botnets controlled by the Russian mafia, right [citation needed]?
The scheme is not impossible, just impractical. Most (non-nerd) people cannot be bothered installing software to compute keys. Also, the amount of computing time necessary becomes negligible once you have enormous botnets, like the Russian mafia.