On my android phone I get the same, but with multi-tasking. There are applications running in the background all the time. They are updating Google maps (with GPS tracking) while I am browsing. They are getting my eMail. They are receiving my television guide. They are updating the weather, playing music etc. etc.. You've got a few services that close unused applications if you don't use them for a while, and state is normally kept (keeping state IS something you have to program). There is a default DB for applications to save state in.
And of course I do have a screen that support multiple "widgets" that get updated regularly, although I suspect that iPhone widgets just get called once in a while if the desktop is available.
With DES CBC encryption you only have to know what is in any of the encoded blocks. If they use a standard padding mechanism you can use the first to last block as IV, the key is brute force and the last block has to end with XX XX 80 00 00 00 00 00 after decryption or something similar.
Encryption algorithms are supposed to protect against known plain text attacks and for good reason. It's not a "crypto breakthrough" because it is just a more effective way to brute force DES. Of course this *is* useful for knowing the current state of DES attacks and for certain persons interested in breaking that old DES encrypted file.
So it is interesting news, but not a breakthrough.
Many encryption schemes (for secure messaging, say SSL) include a MAC or HMAC (secure checksum) with a *different* session key. So finding the MAC key is not always the same as finding the encryption key.
You know the password is correct by generating a key from a password (say, using PKCS#5 password based encryption key generation scheme), and sending back an encrypted challenge. Using DES for this scheme is a terrible idea (known plaintext - all the encrypted "characters" are known).
Anyway, most encrypted data (not passwords, they are normally not encrypted) is data wrapped in either ASN.1 DER encoded structures (CMS or PKCS#7) or (e.g.) XML encoded structures. Then there is the padding of the last block which is also generally known. Knowing the (partial) plain text of some of the encrypted blocks is simply not an issue.
Yes, you can encrypt twice, if needed with two different algorithms. Yes, this would mean that plain text is hard to detect. If you use the same key and the same algorithm, double encryption is probably cryptographically slightly worse compared to simply increasing the number of rounds of the algorithm. There is simply no good substitute for Increasing the key length and using a good cryptographic algorithm like AES (for any key size).
It allows multiple clients to have their own IP addresses. Which means that you don't have any limitations you have with IPv4 while hosting stuff (bittorrent, games). If your router supports IPv6 of course, but I don't think that network appliances are the problem. Things like mobile devices (for which IPv6 would be great) are more likely to suffer because of lacking IPv6 support.
From a competition point of view those applications also compete with JBoss and Eclipse / IntelliJ IDEA. I certainly hope that they are preserved. But moving them into Oracle will certainly not limit choice between providers. I presume Oracle will keep at least one application server / EE environment and IDE alive.
Well, congratulations for getting a well working configuration. But don't assume your easy configuration is the norm. Things are getting better, but we're not there yet.
Are you that guy from the Debian mailing list? You sound like him - unjustly bashing ATI/AMD, misrepresenting their statements, and exaggerating the problems ATI on Linux has.
No, for a normal user they are unusable. Any less advanced person would not have spend those kind of hours on configuring a graphics card.
They fact is that even the binary drivers (yuck) are much better than thy used to be, and the Free drivers are moving along by leaps and bounds. AMD has done very well with their promise to deliver documentation, and the Xorg guys are improving drivers as fast as they can, given limited manpower, and a rather large amount of (needed) churn in Xorg (DRI2, KMS, TTM/GEM, Gallium3D) that they need to keep up with.
Oh, I'm not bashing anyone, trust me on this.
I'm just this guy waiting on some kind of normal display/sound drivers on my Linux computers. Currently doing anything slightly over running vesa or nvidia for graphics and very basic sound stuff sucks on Linux (or at least the last 4 Ubuntu versions I tried. Don't mistake this comment for "Linux sucks". I love the way many things like package mgmt and source control work in Linux. But also don't forget that good touchpad, display and sound card support are paramount for any real "Linux on the desktop". After so much time, any promises of better support would get anyone down.
I currently have Intel, but in 2007/2008 I had an r300, and it worked very well (free drivers). I have a lot of confidence in the Radeon driver, and sometime soonish I will probably get an r700 or r800.
Well, I'm looking at a screen driven by my laptop with Intel graphics now (karmic koala), and if Windows would give me kind of shit like this I would SERIOUSLY complain to Microsoft. It's that compiling the OpenJDK works so much better under Linux because seriously, the amount of time that it takes to get things slightly right is bugging the hell out of me.
It's amazing how far Linux has come, and it is at least as amazing how far it still needs to go.
Everyone likes to show off how stupid they are, I guess. You don't measure public key keyspace like that. Not all possible bit patterns are valid keys. In fact, VERY FEW bit patterns are valid keys.
Um, no that's just for RSA and DSA. You can more or less measure ECC key spaces like this. AFAIK it is not a fundamental part of asymmetric cryptographic techniques. Since this IS about RSA, the GP is certainly incorrect though. So you make a very valid point but your explanation is slightly off.
I think the patent encumbrances of ECC are the reason it's mysteriously absent from a lot of commercial software that deals with security and even a lot of Linux distros and software. I'd have to double-check, but for example, I don't think Windows Certificate Services supports ECC.
How many years was it again that they promised to produce open source graphic drivers for Linux? I've lost count and have ordered a new motherboard with a silent Nvidia based graphics card because I just *HAD* it with ATI on Linux. My AMD chipset motherboard also had a lot of SATA instability under Linux and I had all kinds of problems letting the system know how to read any of the CPU's censors (X2 Phenom based CPU). So I have just ordered an Intel based CPU/chipset as well.
I've no doubt that AMD is slowly working with the community to get better support, but their current binary offering sucks balls, there is no other way to describe it. Having a discrete graphics chip with video decoding capabilities should not mean you can use either one, but not both at the same time. Turning my monitor 90 degrees? Forget it, greyed out. And that's just the start of things.
And don't tell me how to do things, I've been running Linux since my first slackware CD's and even now I have not a single good idea on how to fix these issues, even after googling for hours on end. If I can't get this right, then only very hard core Linux programmers can.
Essentially, that opens another huge security gap (which might have been there for a long time but went unnoticed so far).
It does not necessarily open up a "huge security gap", that's sensationalism. It does add significant "surface" to attack.
GlobalPlatform cards (used by Visa/Mastercard) have always contained methods to update the Java Card (or other OS) applications on the card. Of course, this requires either signed code or a master key set. One expects this interface to be well tested and certified - and normally they are.
Normally bank cards (and ID cards/passports) don't get updated in the field. I would not be surprised when upgrading the cards would meet serious problems.
Since the last 4 or 5 book reviews he puts up on Amazon (including this one) get 5/5 stars (and only one out of many scores only two stars). I'm not saying that that is wrong or anything, but it does make me just slightly wary. If anyone else has another opinion please post it because this review alone won't let me buy the book.
Exactly. They are trying to host forms on an application most people just use to view formatted pages of text. Fine by me, just call it.fpdf, create a new MIME extension and be done with it. It could still be nicely compatible with Acrobat Reader, and you could disable JS for normal.pdf files.
Currently I am just using another viewer without any JS and 10 pages of settings just to be able to view.pdfs without getting a headache. They are trying to accomplish multiple things on a popular platform and are falling in their own trap.
Yes, just don't buy a secure flash product that does not specify exactly what is done in hardware and using which protocol. You are much better off using open source software encryption if you don't know how the hardware protection is done.
As for peer review: you can do with a nice white paper explaining the crypto and asking specific questions to the vendor if you don't get anything. As for peer review; yes, if you are a large company you should ask a crypto/side channel specialist for help. A certification (FIPS or using the international common criteria specs) really does help. But you have to make really sure what is tested. There are many secure devices on this world that are only partly certified. Just buying a "certified device" means absolutely nothing. Most of the time you can get a brief description of the tested components at the certification body.
As for flag ship products: these are basically flash storage vendors trying to make something on the side. Their flagship product is that large memory/low footprint/fast (in that order) product they are selling. They won't be hit too hard when something like this happens. Buy from a security vendor that has something to loose instead; they are bust if their stuff is broken like these dumb-drives clearly are.
Nah, the ironkey is made from aluminium not from wood (tree products, could not pass the pun). Having looked at the ironkey protocols they seem quite sturdy. Actually it is the only USB-key device I would buy for myself for secure storage - even though even those drives have key distro problems (how do you trust the ironkey that is in your mail, for instance).
I do believe he was commenting on other peoples comments not his own.
(In other words, just like this is a comment on your comment and not on my own comment and your comment was a comment on the author who made a comment on other peoples comments. Since this comment was on the comment about your comments all this should probably be considered reflective meta comments and non-reflective meta-meta comments.)
In Java CheckStyle I've disallowed any statements that have been placed behind the code instead of on the line right in front of it. There are a few reasons for doing so: 1) they can be easily overlooked 2) they tend to explain the how instead of the why (which is a mistake most of the time) 3) people tend to use spaces to format them and 4) they tend to go over the 120 column mark we've set during refactoring.
So none of the lines except maybe the line containing just else would have been marked with a warning:) (yes, I know, I am responding to a jest).
"(As an aside why is it in Uni that recursive code is held in such high regard as being elegant whereas in day to day like its almost always a bad idea. I made that mistake a few times early on in my professional life)."
Oh, that one is easy. Recursive code is a nice mathematical concept, used a lot in functional programming. As computer science more or less evolved from mathematics (and maybe physics) there is a lot of influence from those fields. You'll probably see it a lot less in studies for applied software engineering.
Yes, and it's something you *should* certainly avoid, even when the platform does not suffer easily from stack overflows. I normally try and replace it with a state machine (I think, nowadays recursive methods have somehow disappeared from all of my designs).
In Eclipse (an IDE, mostly used for Java) you can create comments that automatically generate "Tasks". These tasks are then displayed in the "Task View", for instance when a comment contains TODO: or DEBUG: or NOTE: or WARNING: which are the tasks that I have defined. In release code, there should be no TODO: or DEBUG: comments left of course. You can also easily look those up in a normal text editor.
So before releasing it is very easy to take a quick look at the task view to see if you've got any loose ends. The hacks are of course tagged with a "WARNING: ugly code, should use an unmodifiable HashMap instead of two arrays" or something similar.
"Because the algorithm is almost never the weakness in any security system? "
Come again? MD5, MiFare, single DES, WEP, GSM - just a bunch of algorithms and systems that are broken because of the algorithm.
"This was snake oil, sold as "provably perfect encryption" which is a total load of rubbish."
No, provably perfect encryption does exist (one time pads for instance). You are probably trying to say that "provably perfect security systems" are a load of rubbish. Many algorithms are provably secure, but they rely on a certain view of the world which is unobtainable.
"Anyhow, quantum crypto wasn't about a algorithm, but about a silly claim that one can use technology to make communication intercepts "provably impossibly".
Well, I don't think the idea behind quantum crypto has been invalidated, just this implementation.
"Bullshit - making one link of a chain really really strong doesn't make the chain meaningfully stronger."
As long as they can make it impossible to hack anything between the end points - in such a way that the end points are a useful distance apart they have met their goal. It seems though they did not accomplish this.
If quantum cryptography of this kind makes any sense practically or commercially is another matter. Personally I would rather invest in other parts of a real world security system for sure. Just replace the ends with AES 256 master keys and create short lived session keys using any authenticated key agreement protocol.
From an academic point of view it is interesting though.
Slashdot Mirror
Another flashy headline. Who the fuck do they think they are, the sun?
On my android phone I get the same, but with multi-tasking. There are applications running in the background all the time. They are updating Google maps (with GPS tracking) while I am browsing. They are getting my eMail. They are receiving my television guide. They are updating the weather, playing music etc. etc.. You've got a few services that close unused applications if you don't use them for a while, and state is normally kept (keeping state IS something you have to program). There is a default DB for applications to save state in.
And of course I do have a screen that support multiple "widgets" that get updated regularly, although I suspect that iPhone widgets just get called once in a while if the desktop is available.
With DES CBC encryption you only have to know what is in any of the encoded blocks. If they use a standard padding mechanism you can use the first to last block as IV, the key is brute force and the last block has to end with XX XX 80 00 00 00 00 00 after decryption or something similar.
Encryption algorithms are supposed to protect against known plain text attacks and for good reason. It's not a "crypto breakthrough" because it is just a more effective way to brute force DES. Of course this *is* useful for knowing the current state of DES attacks and for certain persons interested in breaking that old DES encrypted file.
So it is interesting news, but not a breakthrough.
Many encryption schemes (for secure messaging, say SSL) include a MAC or HMAC (secure checksum) with a *different* session key. So finding the MAC key is not always the same as finding the encryption key.
You know the password is correct by generating a key from a password (say, using PKCS#5 password based encryption key generation scheme), and sending back an encrypted challenge. Using DES for this scheme is a terrible idea (known plaintext - all the encrypted "characters" are known).
Anyway, most encrypted data (not passwords, they are normally not encrypted) is data wrapped in either ASN.1 DER encoded structures (CMS or PKCS#7) or (e.g.) XML encoded structures. Then there is the padding of the last block which is also generally known. Knowing the (partial) plain text of some of the encrypted blocks is simply not an issue.
Yes, you can encrypt twice, if needed with two different algorithms. Yes, this would mean that plain text is hard to detect. If you use the same key and the same algorithm, double encryption is probably cryptographically slightly worse compared to simply increasing the number of rounds of the algorithm. There is simply no good substitute for Increasing the key length and using a good cryptographic algorithm like AES (for any key size).
It allows multiple clients to have their own IP addresses. Which means that you don't have any limitations you have with IPv4 while hosting stuff (bittorrent, games). If your router supports IPv6 of course, but I don't think that network appliances are the problem. Things like mobile devices (for which IPv6 would be great) are more likely to suffer because of lacking IPv6 support.
You get that from fucking the article? Curious.
From a competition point of view those applications also compete with JBoss and Eclipse / IntelliJ IDEA. I certainly hope that they are preserved. But moving them into Oracle will certainly not limit choice between providers. I presume Oracle will keep at least one application server / EE environment and IDE alive.
I can't see an ice cream stand in the middle of the ocean.
Well, congratulations for getting a well working configuration. But don't assume your easy configuration is the norm. Things are getting better, but we're not there yet.
Are you that guy from the Debian mailing list? You sound like him - unjustly bashing ATI/AMD, misrepresenting their statements, and exaggerating the problems ATI on Linux has.
No, for a normal user they are unusable. Any less advanced person would not have spend those kind of hours on configuring a graphics card.
They fact is that even the binary drivers (yuck) are much better than thy used to be, and the Free drivers are moving along by leaps and bounds. AMD has done very well with their promise to deliver documentation, and the Xorg guys are improving drivers as fast as they can, given limited manpower, and a rather large amount of (needed) churn in Xorg (DRI2, KMS, TTM/GEM, Gallium3D) that they need to keep up with.
Oh, I'm not bashing anyone, trust me on this.
I'm just this guy waiting on some kind of normal display/sound drivers on my Linux computers. Currently doing anything slightly over running vesa or nvidia for graphics and very basic sound stuff sucks on Linux (or at least the last 4 Ubuntu versions I tried. Don't mistake this comment for "Linux sucks". I love the way many things like package mgmt and source control work in Linux. But also don't forget that good touchpad, display and sound card support are paramount for any real "Linux on the desktop". After so much time, any promises of better support would get anyone down.
I currently have Intel, but in 2007/2008 I had an r300, and it worked very well (free drivers). I have a lot of confidence in the Radeon driver, and sometime soonish I will probably get an r700 or r800.
Well, I'm looking at a screen driven by my laptop with Intel graphics now (karmic koala), and if Windows would give me kind of shit like this I would SERIOUSLY complain to Microsoft. It's that compiling the OpenJDK works so much better under Linux because seriously, the amount of time that it takes to get things slightly right is bugging the hell out of me.
It's amazing how far Linux has come, and it is at least as amazing how far it still needs to go.
Everyone likes to show off how stupid they are, I guess. You don't measure public key keyspace like that. Not all possible bit patterns are valid keys. In fact, VERY FEW bit patterns are valid keys.
Um, no that's just for RSA and DSA. You can more or less measure ECC key spaces like this. AFAIK it is not a fundamental part of asymmetric cryptographic techniques. Since this IS about RSA, the GP is certainly incorrect though. So you make a very valid point but your explanation is slightly off.
There is a related-key weakness in AES-256 and AES-192, bringing their effective strength down to 2^119 and 2^176 respectively.
Only for related key attacks. Never ever leave out the context when talking about broken cryptographic algorithms.
Check it out, if you just generate a random key for each file you encrypt, then no such attack can take place.
AES-128 is certainly strong enough for the first couple of years anyway.
I think the patent encumbrances of ECC are the reason it's mysteriously absent from a lot of commercial software that deals with security and even a lot of Linux distros and software. I'd have to double-check, but for example, I don't think Windows Certificate Services supports ECC.
http://blogs.technet.com/pki/archive/2008/01/23/how-to-set-up-a-ca-with-a-cng-ecc-certificate.aspx
Since Vista and Windows 2008 it does, but through CNG not through the more familiar CryptoAPI / CSP.
Even then it is limited to certain NIST curves - forget about doing any enhanced EC cryptography through that API.
How many years was it again that they promised to produce open source graphic drivers for Linux? I've lost count and have ordered a new motherboard with a silent Nvidia based graphics card because I just *HAD* it with ATI on Linux. My AMD chipset motherboard also had a lot of SATA instability under Linux and I had all kinds of problems letting the system know how to read any of the CPU's censors (X2 Phenom based CPU). So I have just ordered an Intel based CPU/chipset as well.
I've no doubt that AMD is slowly working with the community to get better support, but their current binary offering sucks balls, there is no other way to describe it. Having a discrete graphics chip with video decoding capabilities should not mean you can use either one, but not both at the same time. Turning my monitor 90 degrees? Forget it, greyed out. And that's just the start of things.
And don't tell me how to do things, I've been running Linux since my first slackware CD's and even now I have not a single good idea on how to fix these issues, even after googling for hours on end. If I can't get this right, then only very hard core Linux programmers can.
Essentially, that opens another huge security gap (which might have been there for a long time but went unnoticed so far).
It does not necessarily open up a "huge security gap", that's sensationalism. It does add significant "surface" to attack.
GlobalPlatform cards (used by Visa/Mastercard) have always contained methods to update the Java Card (or other OS) applications on the card. Of course, this requires either signed code or a master key set. One expects this interface to be well tested and certified - and normally they are.
Normally bank cards (and ID cards/passports) don't get updated in the field. I would not be surprised when upgrading the cards would meet serious problems.
Since the last 4 or 5 book reviews he puts up on Amazon (including this one) get 5/5 stars (and only one out of many scores only two stars). I'm not saying that that is wrong or anything, but it does make me just slightly wary. If anyone else has another opinion please post it because this review alone won't let me buy the book.
Exactly. They are trying to host forms on an application most people just use to view formatted pages of text. Fine by me, just call it .fpdf, create a new MIME extension and be done with it. It could still be nicely compatible with Acrobat Reader, and you could disable JS for normal .pdf files.
Currently I am just using another viewer without any JS and 10 pages of settings just to be able to view .pdfs without getting a headache. They are trying to accomplish multiple things on a popular platform and are falling in their own trap.
Yes, just don't buy a secure flash product that does not specify exactly what is done in hardware and using which protocol. You are much better off using open source software encryption if you don't know how the hardware protection is done.
As for peer review: you can do with a nice white paper explaining the crypto and asking specific questions to the vendor if you don't get anything. As for peer review; yes, if you are a large company you should ask a crypto/side channel specialist for help. A certification (FIPS or using the international common criteria specs) really does help. But you have to make really sure what is tested. There are many secure devices on this world that are only partly certified. Just buying a "certified device" means absolutely nothing. Most of the time you can get a brief description of the tested components at the certification body.
As for flag ship products: these are basically flash storage vendors trying to make something on the side. Their flagship product is that large memory/low footprint/fast (in that order) product they are selling. They won't be hit too hard when something like this happens. Buy from a security vendor that has something to loose instead; they are bust if their stuff is broken like these dumb-drives clearly are.
Nah, the ironkey is made from aluminium not from wood (tree products, could not pass the pun). Having looked at the ironkey protocols they seem quite sturdy. Actually it is the only USB-key device I would buy for myself for secure storage - even though even those drives have key distro problems (how do you trust the ironkey that is in your mail, for instance).
I do believe he was commenting on other peoples comments not his own.
(In other words, just like this is a comment on your comment and not on my own comment and your comment was a comment on the author who made a comment on other peoples comments. Since this comment was on the comment about your comments all this should probably be considered reflective meta comments and non-reflective meta-meta comments.)
In Java CheckStyle I've disallowed any statements that have been placed behind the code instead of on the line right in front of it. There are a few reasons for doing so: 1) they can be easily overlooked 2) they tend to explain the how instead of the why (which is a mistake most of the time) 3) people tend to use spaces to format them and 4) they tend to go over the 120 column mark we've set during refactoring.
So none of the lines except maybe the line containing just else would have been marked with a warning :) (yes, I know, I am responding to a jest).
"(As an aside why is it in Uni that recursive code is held in such high regard as being elegant whereas in day to day like its almost always a bad idea. I made that mistake a few times early on in my professional life)."
Oh, that one is easy. Recursive code is a nice mathematical concept, used a lot in functional programming. As computer science more or less evolved from mathematics (and maybe physics) there is a lot of influence from those fields. You'll probably see it a lot less in studies for applied software engineering.
Yes, and it's something you *should* certainly avoid, even when the platform does not suffer easily from stack overflows. I normally try and replace it with a state machine (I think, nowadays recursive methods have somehow disappeared from all of my designs).
In Eclipse (an IDE, mostly used for Java) you can create comments that automatically generate "Tasks". These tasks are then displayed in the "Task View", for instance when a comment contains TODO: or DEBUG: or NOTE: or WARNING: which are the tasks that I have defined. In release code, there should be no TODO: or DEBUG: comments left of course. You can also easily look those up in a normal text editor.
So before releasing it is very easy to take a quick look at the task view to see if you've got any loose ends. The hacks are of course tagged with a "WARNING: ugly code, should use an unmodifiable HashMap instead of two arrays" or something similar.
"Because the algorithm is almost never the weakness in any security system? "
Come again? MD5, MiFare, single DES, WEP, GSM - just a bunch of algorithms and systems that are broken because of the algorithm.
"This was snake oil, sold as "provably perfect encryption" which is a total load of rubbish."
No, provably perfect encryption does exist (one time pads for instance). You are probably trying to say that "provably perfect security systems" are a load of rubbish. Many algorithms are provably secure, but they rely on a certain view of the world which is unobtainable.
"Anyhow, quantum crypto wasn't about a algorithm, but about a silly claim that one can use technology to make communication intercepts "provably impossibly".
Well, I don't think the idea behind quantum crypto has been invalidated, just this implementation.
"Bullshit - making one link of a chain really really strong doesn't make the chain meaningfully stronger."
As long as they can make it impossible to hack anything between the end points - in such a way that the end points are a useful distance apart they have met their goal. It seems though they did not accomplish this.
If quantum cryptography of this kind makes any sense practically or commercially is another matter. Personally I would rather invest in other parts of a real world security system for sure. Just replace the ends with AES 256 master keys and create short lived session keys using any authenticated key agreement protocol.
From an academic point of view it is interesting though.
Wasn't Switzerland using this form of quantum crypto for some election or something?
http://it.slashdot.org/article.pl?sid=07/10/11/2211205