I'm no economic expert, but hyper-inflation seems like it would be good (comparatively) for the middle class. My mother-in-law always tells the story of her living in Croatia during the war. She would charge whatever she wanted on her American Express card and by the time the bill was due her government salary had automatically adjusted to the extreme inflation and what she had payed a lot for now comparatively cost pennies. As long as salaries adjust (which they would have to for people not to starve) then you could pay off your mortgage in a month with your newly hyper-increased wage. Historically, this is like the period in US history when people were fighting over silver-backed currency, which would have devalued the dollar and let poor people pay off their debts quickly.
I said it is for local authentication, IPs have nothing to do with it. Every company has an AD policy to lock your account after a few failed logins, this is no different. It is not a matter of choosing the correct 1 out of 3, four times in a row. It is choosing the correct four out of 12 sequences, which is indeed 1/495. Think of it like taking the original scheme, with three different sequences, and breaking each of those sequences into four smaller subsquences. Now, you shuffle those subsequences and present them to the user. Since I have trained on my password, I will also perform better on any subsequence from my password sequence (if we are talking guitar hero, if I know the song I will also know any smaller riff from the song). However, since there are more possible permutations now that I have broken the sequences into smaller pieces, it is much less likely that an attacker can guess the correct one. The article makes no guesses on how many times you can break up your password while still maintaining soundness (i.e. will be able to perform better on the right sequences). I imagine it can't go too short, but the point is you can increase your password length linearly while exponentially increasing the number of possible permutations which is good.
Yes, we should stick with the model we have now which is certainly working fine. No problems here. Why should we every try anything new when it is so hard and we are likely to get it wrong according to some geeks on slashdot? Better to just keep making new hash functions and yelling at people for reusing passwords...
It should say no repeating bigrams. Specifically, they make a complete graph consisting of those letters and randomly sample from the set of all Euler walks on that graph.
If you read the paper you will see that your credentials consist of a "password" sequence and two other static random ones. You are presented with these three sequences, in a shuffled order, each time so they will all repeat. I know we don't have a habit of reading the articles around here, but how could you think an article in a top-tier security conference would be that trivially broken? Additionally, they start with 3 challenge sequences but say that it could be expanded to 4 shorter password sequences and 8 random ones giving you 12 choose 4 = 495 possible passwords. It is also worth noting that this clearly has local authentication in mind where you would not allow more than 3 or 4 failed login attempts. As far as the hashed or unhashed goes, we can't be turning down good research because it is not completely perfect, lest we never accomplish anything.
You can't deny that it makes it easier to remember the keywords if you speak the language. We are also not talking just about the small set of reserved words, but stuff like standard APIs and libraries. How much of a pain in the ass would it be if instead of strcpy() it was jrblik()? Don't answer, it would suck.
Except not really? You just have a preprocessor step where you specify which language you coded it in and everything is translated to some canonical form. You could even do this in everyone's precious favorite language C using macros.
I was just saying it is disingenuous for the summary to imply that it doesn't support IMAP. That is factually wrong. If you want to complain about it not supporting custom servers then that is fine, but it was obviously a calculated decision made by Microsoft and not, as the summary would like you to believe, the result of lazy or incompetent developers.
It only lets you set up accounts for Exchange, Hotmail and Gmail right now, but it definitely does support IMAP. If you add a Gmail account to it and then disable POP retrieval it still works. Disable IMAP and it suddenly doesn't. I imagine they will add the option for arbitrary servers before it gets released, but even if they don't it will satisfy 98% of the people that use it (those without Outlook and who don't know what Thunderbird is).
Considering the largest RSA modulus ever factored is something like 750 bits, and until recently they were offering large amounts of prize money, I think 1024 is probably secure enough for your email that nobody really cares about, and 2048 will be secure for many years to come.
Nobody said fully homomorphic. You can do a lot with just multiplication or just addition. There was a paper by Microsoft Research about a year ago with a list of real world applications for partially homomorphic encryption. One of the big ones is statistical analysis (sum, mean, regression all require only additions). There are also almost-fully homomorphic ciphers that can do an unbounded number of additions and a small number of multiplications efficiently.
There are plenty of things you can do to take advantage of computational resources in the cloud while remaining secure i.e. private information retrieval, secure multiparty computation, homomorphic encryption, etc.
Makes it easy to coerce people with this though. Just have them show you their ID and you can verify that they voted the way you wanted them to vote. One of the good things about the system we have now is, if it works, only you know how exactly you voted. In addition to the obvious organized bullying situation, I would bet there are a lot of cases where a particularly domineering husband/father would demand to see their family's IDs so they could make sure they voted the "right" way.
Agreed. While I think this issue certainly warrants discussion, the whole article comes off as childish with quips like this:
"we view Windows itself as malware and want to keep it away from our machines."
They seem like they are making a big deal out of this thing just to sound holier than thou. Their ideal situation, where users can install their own certificates or choose to disable secure boot, is exactly what is mandated by Microsoft (for x86 at least). They even mention this in the article. The only problem they seem to have is with some nebulous "barrier to installation" caused by having to manually do one of those two things before you can install another operating system. It is 100% completely impossible to have secure boot without SOME additional effort on the users part when installing another bootloader or OS because that is entirely the point (to prevent malware silently subverting the boot process). The article is chocked full of complaints with no tangible solutions.
Gotcha, that makes sense. But why then would you buy Windows 7 assuming 8 is going to be the same price when it comes out? I would agree that it might not be a big enough improvement to justify paying a significant amount of money, but its at least better than nothing.
I really don't get what everyone hates about it. I installed it recently and sure the metro interface is kinda weird, but you can pretty much ignore it and stay in the desktop mode and everything is exactly like Windows 7 but with a bunch of tiny improvements like being able to natively mount ISO files.
If there is no verification going along with the signing, then what is even the point of having Canonical sign custom boot loaders in the first place? You should just self sign it and then load your public key in UEFI. I agree with everything you are saying, I just don't see the point of Canonical signing anything but their own code.
Yes, that would be wonderful if that was how secure boot worked in right now but it does not. Hence, we have to rely on the fact that the keys are very tightly controlled. The second part would also be great except any "upstream" process is at the mercy of the boot loader. Imagine the boot loader is a hypervisor that fakes any requests from the kernel for the boot sector so that it looks like everything is valid and signed. The only way to get this to work right now is to have complete controlled trusted boot chain.
That seems like a horrible solution. As soon as Canonical starts signing things for people, they take on a tremendous amount of responsibility. All it takes is them signing ONE potentially malicious boot loader (doesn't even have to be that malicious, just something that silently boots unsigned kernels) and the whole secure boot thing is ruined for everyone everywhere. It is crazy how narrow a precipice this all rests on. As much as I hate to say it, I don't see an easy way out of this situation besides Microsoft highly restricting signing (like they are doing) and letting people install their own root certificates (which would be a headache, even for moderately technical people).
Either you would have to have your own custom grub that runs on top of a standard, signed grub or you are completely circumventing secure boot which would ruin the whole thing for everybody.
Slashdot Mirror
Whats your proposed solution that is better?
I'm no economic expert, but hyper-inflation seems like it would be good (comparatively) for the middle class. My mother-in-law always tells the story of her living in Croatia during the war. She would charge whatever she wanted on her American Express card and by the time the bill was due her government salary had automatically adjusted to the extreme inflation and what she had payed a lot for now comparatively cost pennies. As long as salaries adjust (which they would have to for people not to starve) then you could pay off your mortgage in a month with your newly hyper-increased wage. Historically, this is like the period in US history when people were fighting over silver-backed currency, which would have devalued the dollar and let poor people pay off their debts quickly.
I said it is for local authentication, IPs have nothing to do with it. Every company has an AD policy to lock your account after a few failed logins, this is no different. It is not a matter of choosing the correct 1 out of 3, four times in a row. It is choosing the correct four out of 12 sequences, which is indeed 1/495. Think of it like taking the original scheme, with three different sequences, and breaking each of those sequences into four smaller subsquences. Now, you shuffle those subsequences and present them to the user. Since I have trained on my password, I will also perform better on any subsequence from my password sequence (if we are talking guitar hero, if I know the song I will also know any smaller riff from the song). However, since there are more possible permutations now that I have broken the sequences into smaller pieces, it is much less likely that an attacker can guess the correct one. The article makes no guesses on how many times you can break up your password while still maintaining soundness (i.e. will be able to perform better on the right sequences). I imagine it can't go too short, but the point is you can increase your password length linearly while exponentially increasing the number of possible permutations which is good.
Yes, we should stick with the model we have now which is certainly working fine. No problems here. Why should we every try anything new when it is so hard and we are likely to get it wrong according to some geeks on slashdot? Better to just keep making new hash functions and yelling at people for reusing passwords...
It should say no repeating bigrams. Specifically, they make a complete graph consisting of those letters and randomly sample from the set of all Euler walks on that graph.
If you read the paper you will see that your credentials consist of a "password" sequence and two other static random ones. You are presented with these three sequences, in a shuffled order, each time so they will all repeat. I know we don't have a habit of reading the articles around here, but how could you think an article in a top-tier security conference would be that trivially broken? Additionally, they start with 3 challenge sequences but say that it could be expanded to 4 shorter password sequences and 8 random ones giving you 12 choose 4 = 495 possible passwords. It is also worth noting that this clearly has local authentication in mind where you would not allow more than 3 or 4 failed login attempts. As far as the hashed or unhashed goes, we can't be turning down good research because it is not completely perfect, lest we never accomplish anything.
You can't deny that it makes it easier to remember the keywords if you speak the language. We are also not talking just about the small set of reserved words, but stuff like standard APIs and libraries. How much of a pain in the ass would it be if instead of strcpy() it was jrblik()? Don't answer, it would suck.
Except not really? You just have a preprocessor step where you specify which language you coded it in and everything is translated to some canonical form. You could even do this in everyone's precious favorite language C using macros.
Incorrect, you can read the specifications here. http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256 Why would you say something with such conviction without even googling it first?
I was just saying it is disingenuous for the summary to imply that it doesn't support IMAP. That is factually wrong. If you want to complain about it not supporting custom servers then that is fine, but it was obviously a calculated decision made by Microsoft and not, as the summary would like you to believe, the result of lazy or incompetent developers.
It only lets you set up accounts for Exchange, Hotmail and Gmail right now, but it definitely does support IMAP. If you add a Gmail account to it and then disable POP retrieval it still works. Disable IMAP and it suddenly doesn't. I imagine they will add the option for arbitrary servers before it gets released, but even if they don't it will satisfy 98% of the people that use it (those without Outlook and who don't know what Thunderbird is).
Probably because then somebody could scoop you on the analysis paper that you are in the process of writing.
You seem to be awfully picky for somebody who is too lazy (attention seeking?) to google it for themselves.
Considering the largest RSA modulus ever factored is something like 750 bits, and until recently they were offering large amounts of prize money, I think 1024 is probably secure enough for your email that nobody really cares about, and 2048 will be secure for many years to come.
Nobody said fully homomorphic. You can do a lot with just multiplication or just addition. There was a paper by Microsoft Research about a year ago with a list of real world applications for partially homomorphic encryption. One of the big ones is statistical analysis (sum, mean, regression all require only additions). There are also almost-fully homomorphic ciphers that can do an unbounded number of additions and a small number of multiplications efficiently.
Thats the whole point of this, they replaced old certificates with new ones that don't use MD5.
There are plenty of things you can do to take advantage of computational resources in the cloud while remaining secure i.e. private information retrieval, secure multiparty computation, homomorphic encryption, etc.
Makes it easy to coerce people with this though. Just have them show you their ID and you can verify that they voted the way you wanted them to vote. One of the good things about the system we have now is, if it works, only you know how exactly you voted. In addition to the obvious organized bullying situation, I would bet there are a lot of cases where a particularly domineering husband/father would demand to see their family's IDs so they could make sure they voted the "right" way.
Agreed. While I think this issue certainly warrants discussion, the whole article comes off as childish with quips like this: "we view Windows itself as malware and want to keep it away from our machines." They seem like they are making a big deal out of this thing just to sound holier than thou. Their ideal situation, where users can install their own certificates or choose to disable secure boot, is exactly what is mandated by Microsoft (for x86 at least). They even mention this in the article. The only problem they seem to have is with some nebulous "barrier to installation" caused by having to manually do one of those two things before you can install another operating system. It is 100% completely impossible to have secure boot without SOME additional effort on the users part when installing another bootloader or OS because that is entirely the point (to prevent malware silently subverting the boot process). The article is chocked full of complaints with no tangible solutions.
Gotcha, that makes sense. But why then would you buy Windows 7 assuming 8 is going to be the same price when it comes out? I would agree that it might not be a big enough improvement to justify paying a significant amount of money, but its at least better than nothing.
I really don't get what everyone hates about it. I installed it recently and sure the metro interface is kinda weird, but you can pretty much ignore it and stay in the desktop mode and everything is exactly like Windows 7 but with a bunch of tiny improvements like being able to natively mount ISO files.
If there is no verification going along with the signing, then what is even the point of having Canonical sign custom boot loaders in the first place? You should just self sign it and then load your public key in UEFI. I agree with everything you are saying, I just don't see the point of Canonical signing anything but their own code.
Yes, that would be wonderful if that was how secure boot worked in right now but it does not. Hence, we have to rely on the fact that the keys are very tightly controlled. The second part would also be great except any "upstream" process is at the mercy of the boot loader. Imagine the boot loader is a hypervisor that fakes any requests from the kernel for the boot sector so that it looks like everything is valid and signed. The only way to get this to work right now is to have complete controlled trusted boot chain.
That seems like a horrible solution. As soon as Canonical starts signing things for people, they take on a tremendous amount of responsibility. All it takes is them signing ONE potentially malicious boot loader (doesn't even have to be that malicious, just something that silently boots unsigned kernels) and the whole secure boot thing is ruined for everyone everywhere. It is crazy how narrow a precipice this all rests on. As much as I hate to say it, I don't see an easy way out of this situation besides Microsoft highly restricting signing (like they are doing) and letting people install their own root certificates (which would be a headache, even for moderately technical people).
Either you would have to have your own custom grub that runs on top of a standard, signed grub or you are completely circumventing secure boot which would ruin the whole thing for everybody.