You can arbitrarily approximate bits of RBAC using ACLs and groups, to different degrees in different systems. I'm not expert enough with using sudo to comment on your proposal, but as far as I'm aware, no ACL based system allows the user to pick which groups will be active during their session, nor does it allow the selection of groups to be controlled (e.g. if you pick group A, you can't have group B at the same time).
The definitions used by the article for discretionary, mandatory and role-based access control are a bit confused. They mix up the type of control with mechanisms commonly used to implement them. To be fair, there are no standard definitions of them - or at least, there's more than one "standard" definition. However, having just completed a dissertation in which I attempted to define those things, allow me to offer them here.
Discretionary - a user has discretion to decide who has access to what. A common form of discretionary control is access control lists (ACLs), but capabilities are also discretionary. A big problem with discretionary control is the amount of work the user has to do to grant and revoke permissions to everything. This often leads to systems configured with too much permission - the opposite of principle of least privilege.
Mandatory - the system mandates who has access to what by enforcing a policy (a user may set the policy, but can't grant access outside of that policy). Mandatory systems can require less work to administer day-to-day, as authorisation has been automated. But its often a lot of work to set good policies and are obviously less capable of dealing with things that fall outside of normal working practices. Common forms of mandatory control include label based systems like Bell-LaPadula or Biba (e.g. Top Secret: nuclear;projectX) and protection rings in CPUs.
Role-based (RBAC)- the permissions of a user are taken from their role or roles. Lots of people ask why this isn't the same as using groups and access control lists. You can implement bits of RBAC using groups and ACLs, but full RBAC is more abstract than this, and explicitly allows for greater control - like separation of duties. The current "standard" is the NIST RBAC definition http://csrc.nist.gov/groups/SNS/rbac/)
Note that RBAC can be mandatory or discretionary - it doesn't say how the permissions are allocated to the roles, just how the user gets those permissions through the roles.
Public key crypto solves the main key distribution problem of symmetric crypto. One time pads have the worst key distribution issues of all crypto! So, no, one time pads won't be making any kind of come back due to this.
Well, yes, I suppose you could, although that doesn't really satisfy the normal definition of symmetric ciphers, in which the encryption/decryption keys are either identical, or trivially related. But in principle, I guess you could use a public key cipher like this.
Then I would have to make the distinction clear, and talk about ciphers that can be securely used asymmetrically versus ones that can't. There would no point in doing this whatsoever as far as I can see, but nicely observed!
I'm not talking about how secure or insecure the algorithms really are, and I certainly never said either was totally secure or insecure. It's quite possible that in reality, a given symmetric algorithm is much tougher than a public key one. Someone might figure out how to factor large primes tomorrow (quantum computers can actually do this, if they can be scaled up), and then RSA is toast, while 3DES might still be really hard.
I'm talking about how easy it is to *define* what their apparent security is based on. For public key algorithms, it's easy - it's the same difficulty as the well-defined maths problem they are based on. Most symmetric algorithms aren't based on a single well defined maths problem - they rely on introducing confusion and diffusion in various complex and iterative ways, so it's just not as clear how difficult it may be to break them. If they are resistant to the various attacks that people have figured out so far and seem to statistically diffuse and confuse the plaintext well, then that's as good as we can do.
You are completely correct it is far more likely that the implementation will be broken than the underlying algorithm
For example, there have been some interesting side-channel attacks on public key crypto algorithms, by exploiting timing differences resulting from common implementations of certain maths functions. These can be used to reveal the key using enough attempts.
However, this doesn't invalidate my ability to invent the algorithm in the first place!
Hmmm... I would still say that public key crypto isn't that hard to implement. It's not the complexity of doing the maths - it's finding the solution that's hard. For example, there aren't really any good shortcuts to factoring a large number. Very, very simple maths - just very difficult to find the answer short of trying all the possible solutions.
For me anyway, it's way easier than calculating symmetric encryption (with the honorable exception of the OTP!). I can easily implement public key algorithms with just a pen and paper - I've calculated RSA and El Gamal myself. Contrast this with the internal complexities of s-boxes and the feistel cipher... I would struggle to implement DES accurately on paper, or even to write the software to do it, without making some awful mistake. Of course, your mileage may vary.
I do agree that security generally implies a much wider set of services than just confidentiality. One of my favorite (simple) examples of this is a student hacking in to his school system to change his grades. The grades are encrypted, which the staff thought made the database invulnerable. The student hacks in, and just copies the encrypted grades from a student he knows generally does well, to his own record. He could never read them, but he didn't have to!
I'm intrigued that you say there are ways of finding partial solutions to public key encryption - can you give me any links to some results in this area?
The barman is verifying your identity, by comparing your face with a photo on the card. If it matches, he believes that you have the claimed identity on the card, with the age given. The biometric is being used to *verify* that you possess the claimed identity.
If he took a picture of you, without you saying who you were, ran it past a database of photos of everyone, and the system popped up with "This is probably QuantumG", that would be *identifying you* from a set of possible people using a biometric.
Well, the algorithm you link to is a primality test - useful for generating large primes to encrypt with, not for factoring composite numbers into their prime components. And it's a theoretical advance, as even the inventor admits existing primality tests are faster for practical purposes today. So it would make generating very large keys (larger than we use today) easier, but does not help to crack them.
You are right that the key length of DES was a bit too short, although, the NSA put in some changes that were only understood to increase resistance to differential cryptanalysis later. I think computational power had as much to do with it as any conspiracy.
You are right that we attack symmetric ciphers by developing new cryptanalytic techniques, and public key ciphers by attacking the maths. However, to date, no-one has made any mathematical advance that would help to practically crack any public key cipher, whereas some practical cryptanalytic attacks on symmetric ciphers have been developed.
I guess this shouldn't surprise us; public key ciphers are based on maths problems that have defeated everyone for decades, centuries, or even millenia. Symmetric ciphers just don't have an easily defined, underlying problem you can tie the security to, they are based on intuition and knowledge of attacks found so far, as much as anything else.
Yes, and in fact, the OTP is the only provable, completely secure crypto in existence! Completely uncrackable - as long as the pad is really random and you don't re-use it.
It's not quite the same as other symmetric crypto though. You can't re-use the key (the pad) without completely compromising it, but you can with other crypto algorithms, and you need a pad as long as all the messages you ever want to send. So distribution of a useful OTP is much harder.
I apologise if I seemed arrogant; I wasn't claiming any great intelligence for myself. I maintain that pretty much *anyone*, with a reasonable understanding of maths and the principles of public key ciphers, would find it possible to design a workable (not necessarily efficient or pragmatic) public key cipher, but most people wouldn't even know where to start with symmetric cipher.
The reason there aren't more public key ciphers is not because of a shortage of hard maths problems to pick from, but that the ciphers we have are sufficient, well studied and understood, and security people are quite conservative. In fact, much of the differentiator in them is down to pragmatic reasons, like computational power required to implement them, or that they are standardised and already in widespread use.
Symmetric crypto, on the other hand, is not based on a simple mathematical problem you can find in a textbook. It is based on "scrambling things up" - a vague concept - in a way that you hope is hard to unscramble, and which is highly dependent on the key. But this isn't based on any single underlying mathematical problem or theory. You can't state that the security of your scrambling is the same as the difficulty of doing x. It takes a lot more understanding and skill to design a symmetric cipher that people can even begin to have any faith in, regardless of how pragmatic it may be to implement.
Completely wrong, sorry. Biometrics are usually good for verification (authentication), not identification. Verification means checking that your biometric ("password") matches the one linked to your claimed identity ("username"), and is a one-to-one match that can be performed swiftly, with few false positives or false negatives.
Identification means trawling the database of all known biometrics to find ones that might match - a one-to-many match, that is generally quite slow and will generate a number of false positives in any large set of people.
Symmetric crypto easier than public key? Are you kidding? Public key is based on simple one-way math functions. It's easy to prove it's secure (with certain assumptions about not being able to solve hard problems, like discreet logs or factoring large numbers). If the maths is solid, you've got a good encryption algorithm. If the single hard maths problem isn't cracked, you're safe. Job done.
I could probably invent a reasonable public key algorithm with a maths textbook to hand - but no way could I invent a good symmetric crypto algorithm. Symmetric crypto relies on scrambling things up in a way it can't be unscrambled easily. You have to know a *lot* about cryptanalysis to even begin designing one, and you can still become vulnerable to a surprise attack. There is no general way of mathematically proving that how you are doing the scrambling is secure in any way - only that it is resistant to all the known attacks so far.
Well, I know what you mean about that. I've got Knuth on my bookshelf, and I can honestly say I don't look at it very often! Pure pose value for me;) I assume you're talking about "Applied Cryptograhpy" - but I do read Schneier's books - I've got most of them, and I like 'em. What other security people would you recommend?
I would say quite the opposite. I think it's well documented that Mr Schneier used to think that cryptography would solve all our security woes, and then he realised this was only a small part of the picture. You may have preferred him when he was all gung-ho on the deeply technical and fascinating aspects of crypto - I love that stuff too - but you are not his audience anymore.
Things that you may think are obvious are just not to most people. He's trying to reach normal people, business leaders, politicians - people who don't get it, or still think security is just boring techy stuff that doesn't work very well. He's trying to show it's also a mindset, a way of seeing the world, that anyone can understand. I think he's doing pretty good, but again, we are not his primary audience.
Nice straw man. Of course, if a password was simply "obscured" in a "well known and trivially reversible way", then yes, gosh, that wouldn't provide any protection at all.
But Rob Weir didn't make that claim. He just pointed out that plain text passwords were being stored in the document format, and that this is a security risk - which it is. It may be fine in some circumstances - but in all the other ones, where it isn't fine, there is no other mechanism provided by the standard.
Now, if a password were to be encrypted *properly*, then it wouldn't be trivially reversible, without knowing the secret key. Of course, now you have to deal with how to get the secret key - but again, there is no mechanism defined in the standard to do such thing or to allow such a method to be defined. So you are left with plain text passwords, or nothing.
Oh, finally, security people don't think that an encryption algorithm being "well known" is any kind of weakness. This is known as the Dolev-Yao threat model, where all security depends on the secrecy of the key, and nothing else.
OK, I take your point about losing control, but I still somewhat disagree with your conclusions. The Dolev-Yao threat model, used by all serious cryptographers, assumes that the attacker has all information at their disposal - your encrypted message, the algorithm used to encrypt, even potentially information about the content of the message (but not the exact message itself). Modern cryptography is designed on the assumption that the *only* thing protecting your data is the secrecy of the key itself.
You are really talking about risk management of information. It's not quite information at rest (e.g. on a physically secured server), and neither is it information in transit (e.g. sent over an secured or encrypted link, that is only interceptable at the moment of transmission). What we have here is information that must be portable (hence why it's on the USB stick), but still requires protection, both now and, crucially, into the future in the case of loss. So the encryption is insurance against the loss of that stick.
As you rightfully say, it doesn't necessarily protect you for all time against all attackers, but it can reduce your risk to an extremely low level. You must consider the cover time (the time for which the information must remain secret) when picking your key size, etc. For example, the DES encryption has never been cracked (in the sense of a practical mathematical break), but it is now crackable because its key length is only around 64 bits. When DES was first designed, they predicted the cover time it would give (following Moore's law), fairly accurately. Picking a key length that gives you sufficient insurance into the future must be a part of your selection process - especially for data encrypted on portable devices.
Of course it is always possible that a surprise mathematical attack could render your encryption useless, or a stunning technological advance might make brute force attacks feasible. These are not very likely, but are possible. But the art of using encryption like this is to mitigate the risk of moving the sensitive information, which presumably must be moved. Without encryption, you couldn't move that sensitive information - or at least, not without a lot of additional and possibly prohibitive expense (armed guards, secure physical delivery services).
Finally, while I agree that the loss of encrypted sensitive information is a risk, and must be acknowledged as such, it is not the *same* risk as actual compromise of the information itself. If you treat it this way, you cannot make realistic plans for each eventuality - you will either over-react in one circumstance, or under-react in another. If the information is *so* important that losing the encrypted data must be treated in the same way as losing the information itself, then you shouldn't be moving it around like that in the first place!
No, sorry, that's just wrong. If the data is properly encrypted with a decent cipher using a key with sufficient entropy, you should assume it has not been compromised.
If the encryption you are using is so poor that the loss of your USB stick means you consider the data to be compromised, why bother encrypting at all?!!!
Copyright has nothing to do with "ideas". It is the protection of a specific work or expression. Anything I create, my specific expression of something, is my copyright, even if the ideas in it are old and well known. It does not have to contain originality, only to be an original expression. Like this post (c) 2008 mattpalmer1086.
The technology looks very cool, but Microsoft just can't resist spinning even where there doesn't seem to be any need at all. Check out the FAQ at worldwidetelescope: http://worldwidetelescope.org/buzz/FAQ.aspx
Q. When did Microsoft first starting looking at the sky? A. For 16 years, Microsoft has invested, and will continue to invest, in long-term, broad-based research through Microsoft Research. WorldWide Telescope is built on work that started with Jim Gray's SkyServer and his contributions to Sloan Digital Sky Survey. Sky Server (a portal to the Sloan Digital Sky Survey) was first released in 2001. Aside from the poor grammar in the question, reading that answer just made my skin crawl...
No kidding! I work at a reasonably well known, public-facing organization with a publicized relationship with Microsoft. We had a few support calls with Microsoft in the last year. All of their staff were polite and professional - but they just didn't seem to understand their own products (or even our problem, for quite some time).
Trying to resolve a bug in Active Directory proved to be impossible - their network guys kept asking us to do the same-old, and their.NET guys kept asking different same-old, but they didn't seem to talk to each other Going. Round. In. Circles. In the end, none of the problems were resolved, despite us figuring out where the problem lay and telling them on several occasions. So we coded around their bug (now resurfacing in another third-party product!) but hey, we had support! Tick!
Checking the results of crypto software isn't generally useful, except in this particularly pathological case where they didn't even implement the algorithm they claimed!
The reason being, security weaknesses in crypto software aren't generally of the nature that they encrypt/decrypt wrongly (rendering your data entirely useless). They're more like keys get reused improperly, or privileges can be abused, or keys are written to disk, or exposed via a side-channel attack, like the timing of encryption, etc. It's not that they don't encrypt or decrypt properly, it's that their mode of operation leaves them open to attack.
I hear these predictions that we will achieve "human level" intelligence due to exponential growth in hardware capability and simulation of neural structures. I don't have a fundamental problem with that. My only observation is that it takes humans at least a decade or two to get up to a reasonable level of useful intelligence, through interacting with the world and studying.
There seems to be an assumption that just having the equivalent processing power automatically creates a useful intelligence, with no time given over for learning and developing. So, are we talking about the raw capability to emulate a human level intelligence, or to produce a fully functioning intelligence you can interact with?
Otherwise, we're going to have a very expensive baby, that may or may not, turn out to develop into an interesting intelligence...
Slashdot Mirror
You can arbitrarily approximate bits of RBAC using ACLs and groups, to different degrees in different systems. I'm not expert enough with using sudo to comment on your proposal, but as far as I'm aware, no ACL based system allows the user to pick which groups will be active during their session, nor does it allow the selection of groups to be controlled (e.g. if you pick group A, you can't have group B at the same time).
The definitions used by the article for discretionary, mandatory and role-based access control are a bit confused. They mix up the type of control with mechanisms commonly used to implement them. To be fair, there are no standard definitions of them - or at least, there's more than one "standard" definition. However, having just completed a dissertation in which I attempted to define those things, allow me to offer them here.
Discretionary - a user has discretion to decide who has access to what. A common form of discretionary control is access control lists (ACLs), but capabilities are also discretionary. A big problem with discretionary control is the amount of work the user has to do to grant and revoke permissions to everything. This often leads to systems configured with too much permission - the opposite of principle of least privilege.
Mandatory - the system mandates who has access to what by enforcing a policy (a user may set the policy, but can't grant access outside of that policy). Mandatory systems can require less work to administer day-to-day, as authorisation has been automated. But its often a lot of work to set good policies and are obviously less capable of dealing with things that fall outside of normal working practices. Common forms of mandatory control include label based systems like Bell-LaPadula or Biba (e.g. Top Secret: nuclear;projectX) and protection rings in CPUs.
Role-based (RBAC)- the permissions of a user are taken from their role or roles. Lots of people ask why this isn't the same as using groups and access control lists. You can implement bits of RBAC using groups and ACLs, but full RBAC is more abstract than this, and explicitly allows for greater control - like separation of duties. The current "standard" is the NIST RBAC definition http://csrc.nist.gov/groups/SNS/rbac/)
Note that RBAC can be mandatory or discretionary - it doesn't say how the permissions are allocated to the roles, just how the user gets those permissions through the roles.
Public key crypto solves the main key distribution problem of symmetric crypto. One time pads have the worst key distribution issues of all crypto! So, no, one time pads won't be making any kind of come back due to this.
Well, yes, I suppose you could, although that doesn't really satisfy the normal definition of symmetric ciphers, in which the encryption/decryption keys are either identical, or trivially related. But in principle, I guess you could use a public key cipher like this.
Then I would have to make the distinction clear, and talk about ciphers that can be securely used asymmetrically versus ones that can't. There would no point in doing this whatsoever as far as I can see, but nicely observed!
I'm not talking about how secure or insecure the algorithms really are, and I certainly never said either was totally secure or insecure. It's quite possible that in reality, a given symmetric algorithm is much tougher than a public key one. Someone might figure out how to factor large primes tomorrow (quantum computers can actually do this, if they can be scaled up), and then RSA is toast, while 3DES might still be really hard.
I'm talking about how easy it is to *define* what their apparent security is based on. For public key algorithms, it's easy - it's the same difficulty as the well-defined maths problem they are based on. Most symmetric algorithms aren't based on a single well defined maths problem - they rely on introducing confusion and diffusion in various complex and iterative ways, so it's just not as clear how difficult it may be to break them. If they are resistant to the various attacks that people have figured out so far and seem to statistically diffuse and confuse the plaintext well, then that's as good as we can do.
You are completely correct it is far more likely that the implementation will be broken than the underlying algorithm
For example, there have been some interesting side-channel attacks on public key crypto algorithms, by exploiting timing differences resulting from common implementations of certain maths functions. These can be used to reveal the key using enough attempts.
However, this doesn't invalidate my ability to invent the algorithm in the first place!
Hmmm... I would still say that public key crypto isn't that hard to implement. It's not the complexity of doing the maths - it's finding the solution that's hard. For example, there aren't really any good shortcuts to factoring a large number. Very, very simple maths - just very difficult to find the answer short of trying all the possible solutions.
For me anyway, it's way easier than calculating symmetric encryption (with the honorable exception of the OTP!). I can easily implement public key algorithms with just a pen and paper - I've calculated RSA and El Gamal myself. Contrast this with the internal complexities of s-boxes and the feistel cipher... I would struggle to implement DES accurately on paper, or even to write the software to do it, without making some awful mistake. Of course, your mileage may vary.
I do agree that security generally implies a much wider set of services than just confidentiality. One of my favorite (simple) examples of this is a student hacking in to his school system to change his grades. The grades are encrypted, which the staff thought made the database invulnerable. The student hacks in, and just copies the encrypted grades from a student he knows generally does well, to his own record. He could never read them, but he didn't have to!
I'm intrigued that you say there are ways of finding partial solutions to public key encryption - can you give me any links to some results in this area?
The barman is verifying your identity, by comparing your face with a photo on the card. If it matches, he believes that you have the claimed identity on the card, with the age given. The biometric is being used to *verify* that you possess the claimed identity.
If he took a picture of you, without you saying who you were, ran it past a database of photos of everyone, and the system popped up with "This is probably QuantumG", that would be *identifying you* from a set of possible people using a biometric.
Well, the algorithm you link to is a primality test - useful for generating large primes to encrypt with, not for factoring composite numbers into their prime components. And it's a theoretical advance, as even the inventor admits existing primality tests are faster for practical purposes today. So it would make generating very large keys (larger than we use today) easier, but does not help to crack them.
You are right that the key length of DES was a bit too short, although, the NSA put in some changes that were only understood to increase resistance to differential cryptanalysis later. I think computational power had as much to do with it as any conspiracy.
You are right that we attack symmetric ciphers by developing new cryptanalytic techniques, and public key ciphers by attacking the maths. However, to date, no-one has made any mathematical advance that would help to practically crack any public key cipher, whereas some practical cryptanalytic attacks on symmetric ciphers have been developed.
I guess this shouldn't surprise us; public key ciphers are based on maths problems that have defeated everyone for decades, centuries, or even millenia. Symmetric ciphers just don't have an easily defined, underlying problem you can tie the security to, they are based on intuition and knowledge of attacks found so far, as much as anything else.
Yes, and in fact, the OTP is the only provable, completely secure crypto in existence! Completely uncrackable - as long as the pad is really random and you don't re-use it.
It's not quite the same as other symmetric crypto though. You can't re-use the key (the pad) without completely compromising it, but you can with other crypto algorithms, and you need a pad as long as all the messages you ever want to send. So distribution of a useful OTP is much harder.
I apologise if I seemed arrogant; I wasn't claiming any great intelligence for myself. I maintain that pretty much *anyone*, with a reasonable understanding of maths and the principles of public key ciphers, would find it possible to design a workable (not necessarily efficient or pragmatic) public key cipher, but most people wouldn't even know where to start with symmetric cipher.
The reason there aren't more public key ciphers is not because of a shortage of hard maths problems to pick from, but that the ciphers we have are sufficient, well studied and understood, and security people are quite conservative. In fact, much of the differentiator in them is down to pragmatic reasons, like computational power required to implement them, or that they are standardised and already in widespread use.
Symmetric crypto, on the other hand, is not based on a simple mathematical problem you can find in a textbook. It is based on "scrambling things up" - a vague concept - in a way that you hope is hard to unscramble, and which is highly dependent on the key. But this isn't based on any single underlying mathematical problem or theory. You can't state that the security of your scrambling is the same as the difficulty of doing x. It takes a lot more understanding and skill to design a symmetric cipher that people can even begin to have any faith in, regardless of how pragmatic it may be to implement.
authentication: the process of *proving* (to some level of assurance) that an individual is who they say they are.
Completely wrong, sorry. Biometrics are usually good for verification (authentication), not identification. Verification means checking that your biometric ("password") matches the one linked to your claimed identity ("username"), and is a one-to-one match that can be performed swiftly, with few false positives or false negatives.
Identification means trawling the database of all known biometrics to find ones that might match - a one-to-many match, that is generally quite slow and will generate a number of false positives in any large set of people.
Symmetric crypto easier than public key? Are you kidding? Public key is based on simple one-way math functions. It's easy to prove it's secure (with certain assumptions about not being able to solve hard problems, like discreet logs or factoring large numbers). If the maths is solid, you've got a good encryption algorithm. If the single hard maths problem isn't cracked, you're safe. Job done.
I could probably invent a reasonable public key algorithm with a maths textbook to hand - but no way could I invent a good symmetric crypto algorithm. Symmetric crypto relies on scrambling things up in a way it can't be unscrambled easily. You have to know a *lot* about cryptanalysis to even begin designing one, and you can still become vulnerable to a surprise attack. There is no general way of mathematically proving that how you are doing the scrambling is secure in any way - only that it is resistant to all the known attacks so far.
Well, I know what you mean about that. I've got Knuth on my bookshelf, and I can honestly say I don't look at it very often! Pure pose value for me ;) I assume you're talking about "Applied Cryptograhpy" - but I do read Schneier's books - I've got most of them, and I like 'em. What other security people would you recommend?
I would say quite the opposite. I think it's well documented that Mr Schneier used to think that cryptography would solve all our security woes, and then he realised this was only a small part of the picture. You may have preferred him when he was all gung-ho on the deeply technical and fascinating aspects of crypto - I love that stuff too - but you are not his audience anymore.
Things that you may think are obvious are just not to most people. He's trying to reach normal people, business leaders, politicians - people who don't get it, or still think security is just boring techy stuff that doesn't work very well. He's trying to show it's also a mindset, a way of seeing the world, that anyone can understand. I think he's doing pretty good, but again, we are not his primary audience.
Nice straw man. Of course, if a password was simply "obscured" in a "well known and trivially reversible way", then yes, gosh, that wouldn't provide any protection at all.
But Rob Weir didn't make that claim. He just pointed out that plain text passwords were being stored in the document format, and that this is a security risk - which it is. It may be fine in some circumstances - but in all the other ones, where it isn't fine, there is no other mechanism provided by the standard.
Now, if a password were to be encrypted *properly*, then it wouldn't be trivially reversible, without knowing the secret key. Of course, now you have to deal with how to get the secret key - but again, there is no mechanism defined in the standard to do such thing or to allow such a method to be defined. So you are left with plain text passwords, or nothing.
Oh, finally, security people don't think that an encryption algorithm being "well known" is any kind of weakness. This is known as the Dolev-Yao threat model, where all security depends on the secrecy of the key, and nothing else.
OK, I take your point about losing control, but I still somewhat disagree with your conclusions. The Dolev-Yao threat model, used by all serious cryptographers, assumes that the attacker has all information at their disposal - your encrypted message, the algorithm used to encrypt, even potentially information about the content of the message (but not the exact message itself). Modern cryptography is designed on the assumption that the *only* thing protecting your data is the secrecy of the key itself.
You are really talking about risk management of information. It's not quite information at rest (e.g. on a physically secured server), and neither is it information in transit (e.g. sent over an secured or encrypted link, that is only interceptable at the moment of transmission). What we have here is information that must be portable (hence why it's on the USB stick), but still requires protection, both now and, crucially, into the future in the case of loss. So the encryption is insurance against the loss of that stick.
As you rightfully say, it doesn't necessarily protect you for all time against all attackers, but it can reduce your risk to an extremely low level. You must consider the cover time (the time for which the information must remain secret) when picking your key size, etc. For example, the DES encryption has never been cracked (in the sense of a practical mathematical break), but it is now crackable because its key length is only around 64 bits. When DES was first designed, they predicted the cover time it would give (following Moore's law), fairly accurately. Picking a key length that gives you sufficient insurance into the future must be a part of your selection process - especially for data encrypted on portable devices.
Of course it is always possible that a surprise mathematical attack could render your encryption useless, or a stunning technological advance might make brute force attacks feasible. These are not very likely, but are possible. But the art of using encryption like this is to mitigate the risk of moving the sensitive information, which presumably must be moved. Without encryption, you couldn't move that sensitive information - or at least, not without a lot of additional and possibly prohibitive expense (armed guards, secure physical delivery services).
Finally, while I agree that the loss of encrypted sensitive information is a risk, and must be acknowledged as such, it is not the *same* risk as actual compromise of the information itself. If you treat it this way, you cannot make realistic plans for each eventuality - you will either over-react in one circumstance, or under-react in another. If the information is *so* important that losing the encrypted data must be treated in the same way as losing the information itself, then you shouldn't be moving it around like that in the first place!
No, sorry, that's just wrong. If the data is properly encrypted with a decent cipher using a key with sufficient entropy, you should assume it has not been compromised.
If the encryption you are using is so poor that the loss of your USB stick means you consider the data to be compromised, why bother encrypting at all?!!!
Copyright has nothing to do with "ideas". It is the protection of a specific work or expression. Anything I create, my specific expression of something, is my copyright, even if the ideas in it are old and well known. It does not have to contain originality, only to be an original expression. Like this post (c) 2008 mattpalmer1086.
A. For 16 years, Microsoft has invested, and will continue to invest, in long-term, broad-based research through Microsoft Research. WorldWide Telescope is built on work that started with Jim Gray's SkyServer and his contributions to Sloan Digital Sky Survey. Sky Server (a portal to the Sloan Digital Sky Survey) was first released in 2001. Aside from the poor grammar in the question, reading that answer just made my skin crawl...
No kidding! I work at a reasonably well known, public-facing organization with a publicized relationship with Microsoft. We had a few support calls with Microsoft in the last year. All of their staff were polite and professional - but they just didn't seem to understand their own products (or even our problem, for quite some time).
.NET guys kept asking different same-old, but they didn't seem to talk to each other Going. Round. In. Circles. In the end, none of the problems were resolved, despite us figuring out where the problem lay and telling them on several occasions. So we coded around their bug (now resurfacing in another third-party product!) but hey, we had support! Tick!
Trying to resolve a bug in Active Directory proved to be impossible - their network guys kept asking us to do the same-old, and their
Checking the results of crypto software isn't generally useful, except in this particularly pathological case where they didn't even implement the algorithm they claimed!
The reason being, security weaknesses in crypto software aren't generally of the nature that they encrypt/decrypt wrongly (rendering your data entirely useless). They're more like keys get reused improperly, or privileges can be abused, or keys are written to disk, or exposed via a side-channel attack, like the timing of encryption, etc. It's not that they don't encrypt or decrypt properly, it's that their mode of operation leaves them open to attack.
Not really. Open source software isn't cost free - the costs are just in different places.
I hear these predictions that we will achieve "human level" intelligence due to exponential growth in hardware capability and simulation of neural structures. I don't have a fundamental problem with that. My only observation is that it takes humans at least a decade or two to get up to a reasonable level of useful intelligence, through interacting with the world and studying.
There seems to be an assumption that just having the equivalent processing power automatically creates a useful intelligence, with no time given over for learning and developing. So, are we talking about the raw capability to emulate a human level intelligence, or to produce a fully functioning intelligence you can interact with?
Otherwise, we're going to have a very expensive baby, that may or may not, turn out to develop into an interesting intelligence...