I have actually seen a Petabox, and it's quite impressive. I work at the UK National Archives, and we have an arrangement with the Internet Archive to archive government web sites. They were kind enough to show us around and explain everything.
The point of the Petabox is that a single person should be able to maintain that amount of storage cheaply. The genius of the design is it's simplicity. All units are identically specced. Their IP addresses are sequential and the units are arranged physically to match, making it extremely simple to locate a malfunctioning rack unit. There is no logical volume management at all. Instead, a home web server locates a requested file and redirects the request to the box on which it lives. All technology is open source and open standards.
All the custom units are mirrored, and arranged in a double sided rack mount with a central heat vent. They all do some pretty sophisticated power management to reduce the cooling requirements.
It's not that you can't create a more resilient architecture; you can. But you can't do it as cheaply, or manage it as efficiently and simply as the Petabox.
I wouldn't use it for critical data with absolute availability requirements. I would use it if I needed to store huge amounts of data cheaply and reasonably securely.
I've only touched the surface of what I was shown, and the extreme focus on simplicity is carried through every aspect of the Petabox's design. I was extremely impressed with it, its design superbly fulfills it's requirements.
It's an interesting problem alright. If I have understood you correctly, the goals are to:
1) Register a unique copy of software with the vendor using 2 servers. 2) That the compromise of one of these servers will not compromise the security of the entire system. Security in this context presumably meaning that the attacker cannot use the compromise to validate arbitrary client machines of his choosing. 3) Provide an online validation method for clients to authenticate their copy and allow it to run each time it is (Logged in? Turned on?)
In practice, most validation schemes attempt to operate off-line for the most part. They may attempt to cryptographically bind a licence key to the machine using some kind of hardware audit when initially registering, avoiding the need for constant online re-validation. Anyway, we'll set aside the obvious scalability problems of forcing online validation globally for all systems, as that is part of your stated goal.
We should also state the assumption that, while the client may be untrusted in the sense that it may attempt to abuse licence keys, we have to trust that the client operating system itself is functioning correctly. If we accept the possibility that the client operating system has been modified, the servers become irrelevant, as the validation checks could simply be bypassed in the first place. There are, of course, ways of making this quite difficult, although, as ever, if you put heavy security in one place, you are inviting attack in another.
With this in mind, the problem then becomes how does a trusted client operating system obtain validation to operate using a valid licence key from a vendor using 2 untrusted servers, over an untrusted network, in such a way that:
(1) if only one of the servers is compromised, the attacker does not gain enough to validate arbitrary clients, and (2) only one copy of an unmodified client operating system with a particular id can operate simultaneously.
You are absolutely right about that. I did a back of the envelope calculation without checking how it really worked at all;) Now there's a security lesson for me.
Still, the basic point holds - you don't want your users typing in a key that long. Most will not get it right, even on the third attempt. I get 20 character licence keys wrong pretty often on the first attempt.
Wow - you put some effort into that. However, the explanation isn't really complete - you aren't using your own terminology consistently, and I still believe your approach suffers from several important and fatal weaknesses. Let's try to tighten up the definitions a little:
So we have the User U, a key exchange X, and an registration server R.
U has a copyid and a private key u_priv.
X has the user's public key u_pub
R has it's own public key r_pub and generates a random string rand.
That's my reading of what you wrote; I may have some details wrong, but it's not possible to say from your description. Anyway, taking that protocol as given, let's see where it needs some work.
Assumptions: 1. Is the copyid unique? I'm assuming it is.
Questions: 1. How does the user get their private key? 2. How does the key exchange get the user's public key? 3. (ii) Rather than using a round of communication to get R's public key to the user, why not just give the user the registration server's public key in a certificate? Will it be changing frequently? 4. (iii) Never give out a private key in a communication protocol. There are other ways of authenticating that don't create this weakness. 5. (iv) How is the copyid associated with the user's public key? Step (i) only sends a copyid - but no way of binding the two together. 6. Why are you bothering to protect the user's public key by encrypting it with itself? Public keys are supposed to be public. If it's to allow the use of the private key (which now has to be transmitted) to produce the public key I see what you're trying to do - it provides origin authentication of the user, but it's a really, really nasty way of doing it, and pretty much completely backwards from how public and private keys are supposed to be used and managed. 7) The random string is the shared secret between the user and microsoft. How is this communication protected? As it stands in your description, the string is sent back unencrypted.
Problems:
The security problem is to ensure that the copy of windows is legitimate and is only running on one PC.
1. Most of your protocol seems to be concerned with protecting the confidentiality of the messages exchanged between client and server. There are plenty of good ways of doing this already which are far more secure. SSL/TLS, for example. Don't roll your own security - you will not get it right most times. 2. The result of the protocol is to bind a copyid to a public user key and a random password. What prevents me from using this on many machines? 3. It doesn't solve the problem of preventing piracy. It's simply a rather convoluted key exchange mechanism, of which there are many far simpler, more efficient, and provably more secure methods available.
Forgive me if I sound a little harsh, but you sound like someone who knows a reasonable amount about how public/private key encryption works, but hasn't studied security much.
Hmmmm... I have to take issue with your description of how easy it would be for MS to have really secure key validation.
>print a 1024-bit "public key" on the packet, which matches a private key on the validating server.
OK. That's almost sensible. Except that 1024 bits are 128 ASCII chars. Some of them are unprintable, so using some form of encoding like base 64 would give you 512 characters. That's quite a lot to type for a user to type in, and how do you know you have a legitimate copy of windows and not a Mafia-Hacked (tm) version. Why not use one of those digitally signed "certificate" things people tend to like for public key validation. Anyway, we'll assume that all users have the same Microsoft public key.
> Use the key to generate a unique ID
Here is where it starts getting a bit vague. Generate a unique ID from the same number that all the users have how exactly? Or do you mean that a number is *somehow* generated and then encrypted using the public key?
> which is copied onto the computer.
OK. So now I can copy that number off the computer and onto another one. What prevents me from doing this? How is the number tied to the machine?
> Any subsequent communication...
What communication? You haven't mentioned any so far. I'll assume that somehow in an earlier stage, you sent the number you generated to microsoft. Possibly encrypted by the public key.
> has to match the unique ID and the public key.
What do you mean, *match*? Do you mean that the conversation is encrypted using these numbers? So how do Microsoft know that I'm not simply replaying a communication I intercepted from another machine? How do Microsoft know that the number I generated is a *valid* number? Anyone can make up a number, encrypt it with the publicly avaiable public key, and send it to Microsoft.
I guess you knew what you meant when you wrote the post, but just throwing around the magic words "public key" doesnt' solve the actual security problem, which is to know that the copy of windows running was purchased legitimately.
(BTW: most security people define Availability as a key concept (CIA: Confidentiality, Integrity, Availability). So unfortunately turning the PC off doesn't make it secure. Well - it may make the PC hardware secure from remote attack, but not the information it's being used to manage, nor the physical machine itself.
That's an interesting perspective. I can see that for individual businesses, this may be a harder problem.
From my perspective (I work at the UK National Archives), migrating and maintaining documents, web sites, spreadsheets, presentations, images, audio, video, virtual reality from public enquiries, databases... etc. etc. with the intention that people will be able to read them 1000 years later is our hard problem.
But we don't have to convince our users to upgrade to the tools that the content creator used - we upgrade the content to be in a format they can use without any worries - normally by sticking to open standards, or in the absence of widely spread open standards, de facto ones (like PDF).
Nope - this is nothing to do with when quantum effects "take over" from gravity. The reverse, in fact - those forces already swamp the measurement of such a tiny force as gravity - they had to find ways to rule them out to reveal the gravitational influence.
The experiment is looking for evidence that gravity does not follow Newton's law at very small scales. This is predicted by some theories (notably string theory). Confirmation that gravity behaves "normally" up to these atomic scales rules out some theories which require larger extra dimensions. As a side benefit, they managed to measure the casimir force really accurately too.
Hmmm... just finished reading an excellent book about cosmology (The Fabric of the Cosmos, by Brian Greene). In it, the author clearly states that all objects are constantly moving at the speed of light through space-time.
If you are stationary in space, then you are "moving" at the speed of light through time. Any motion through space reduces your velocity through time - but it always adds up to the speed of light.
I must admit, that idea made me stop and re-read that section of the book a couple of times, as I'd never heard relativity expressed that way before. I may have not entirely presented his arguments correctly (I am not a physicist), but that was the essence of it.
I was marched by security out of a large IT supplier in the UK when they found out I had found another job with a "competitor". They weren't really a competitor, but my boss was an a-hole.
Then they tried to pay me only for the week I'd done so far that month. 30 days notice works both ways. I contacted their HR department and asked them if this was normal company policy (i.e. illegal).
They paid up, and I got a nice one month break before my next job. It all works out somehow...
So true. My sister, who isn't particulary technical, recently downloaded some obscure music she was after. But it wouldn't play on her Mac, she didn't realise that it would only play on certain licensed devices, couldn't figure out how to transfer it to her stereo or to play it in her car. And she had no faith that, even if she could get it to play on her "licensed device" that it would remain playable in a few years time, as things move on.
I had to tell her "welcome to the wonderful world of DRM." Needless to say, she hasn't bought any more music online since.
Very true - I'm with the UK National Archives Digital Preservation department, and we're taking essentially the same position for long term preservation.
Not only that, we clearly can't mandate that members of the public have an expensive office suite installed in order to read public documentation. We may offer it in that format for convenience (to the many who do have Office), but we can't only offer it that way.
This is actually a very good idea, but very hard to implement with current commercial operating systems without driving the user crazy (log in, log out).
The basic problem is that processes run with the full privilege of the logged in user. This violates the principle of least privilege. Why should your web browser be able to format your hard disk? Overwrite your tax documents? Why should your word processor be able to instantiate a network connection? It's not just access to files, it's access to services. The Java sandbox model goes some way to providing this kind of security.
There is some interesting work on distributed capability systems (based around cryptographically protected access tokens attached to the processes, rather than access control lists on objects with user permissions).
Check out http://www.erights.org/ for some very interesting information on these types of system. It's also the home of the E language - a secure language for building distributed capability based systems.
They have a focus on developers who create software that supports their platforms. Microsoft don't care about web developers per se. Web developers are creating applications that don't rely on Microsoft products. The web developers they like create web applications that use IE specific "features".
If Microsoft supported CSS properly, or submitted their new ideas to the standards bodies, IE wouldn't be required. And following on from that, Windows itself could go. Why do you think IE was made a fundamental part of the OS? Why has it not been ported to other platforms?
Eventually, with a rich enough, standardised feature set, maybe even some office type applications could be delivered via a web interface.
They aren't going to do it unless they control the platform. It will be very interesting to see what Avalon offers in terms of delivering rich client functionality remotely. I assume they see this as a web-killer app, as opposed to a web killer-app.
It's not that they're lazy. Microsoft have done a tremendous job in getting developers to create software for their platforms, creating tools and superb documentation, even before they were the de facto standard that they are today. But only for platforms that they control and which incidentally form a huge part of their cash flow.
The danger to Microsoft is rich client applications which can run on any platform through a standard browser. They are not going to do that if they don't have to in order to stay in the game. That would be like asking Turkeys to vote for Christmas.
Actually, Diffie Hellman is a key exchange protocol, not an authentication protocol. It's also vulnerable to a Man in the Middle attack, since it doesn't perform any authentication at all.
The Station-to-Station protocol was derived later from Diffie Hellman key exchange to add authentication to the key exchange and thus avoid the MITM attack, using digital signatures to authenticate the identities of the parties concerned.
This is exactly what does happen. But there are two reasons why a cryptographic entity may be considered broken.
One is the reason you give, that processing power makes brute force searching practical. For example, the most common encryption algorithm in use today is probably DES. It was designed in the 70s, and was explicitly recommended that it's useful shelf life was only for a couple of decades. They already knew back then that processing power would overtake it's usefulness. As time has gone on, numerous other encryption algorithms have risen, including the new standard AES to take it's place, and have been tested extensively, with sufficient time to have a good sense of whether there are any "obvious" flaws in it.
Which brings us to the second reason why a cryptographic product may cease to be useful - an attack on the fundamental way the algorithm works. For example, if you can find a way of pulling out statistical patterns and using that information in some way, you may be able to get around the already known amount of brute-force processing you would have to do, to considerably shorten the attack - which may suddenly make an attack feasible with *current* amounts of processing power. This is what is happening with SHA-1 right now - although the current attack is still not very feasible for most people, it has moved into the "possible" territory for large organisations. And the likelihood is that once one attack has been found, others will follow. So we're all going to migrate away from MD5 and SHA1 to something else. No need to panic just yet, but we need to pay attention when attacks are found that no-one knew about before.
Since we just don't know how "secure" any of our encryption algorithms really are - a new form of mathematical analysis could be found at any time - people keep attacking them, yes, hoping to find that no attack is possible, or of course hoping that they are the ones who find an attack - it can do the career no end of good. But we all benefit when this is done openly.
The longer a cryptographic entity resists attack by all these frighteningly intelligent people, the more secure we all feel. But a new attack is always just around the corner...:)
My understanding of multi collision attacks is that it is focussed on the sequential applicaiton of a hash function:
e.g.
hash = SHA1( SHA1( message ))
Whereas I think the parent poster is talking about recording two hashes in parallel, using two different algorithms:
hash1 = SHA1( message )
hash2 = MD5( message )
Now the problem is to find a single file message2, with a collision for hash1, and for hash2. This would appear to be considerably harder, even though you can use the collisions from MD5 to feed your SHA1 testing, it is still extremely unlikely that any of them will collide - they're still quite resistant to random collision - nothing has changed there.
Of course, I'm not advocating this as a good practical solution - just pointing out that parallel application of hashes appears to be more secure than using a single one, whereas sequential application has been shown to be vulnerable to multi collision attacks.
Of course, I could be completely wrong about multi collision attacks, and if so, I'd appreciate a better explanation from someone more knowlegeable than I.
The short answer is that if it breaks, it needed fixing anyway. The long answer is that we have no absolute proofs of security, except for impractical things like using one-time-pads.
It is only by resisting cryptanalysis for long periods of time that confidence is built. So given that we have imperfect knowledge, the question becomes: do you want the bad guys (who are looking) to find the vulnerabilities first, if they exist?
I'm not too clear what you mean by "widening the key" - these are hashing algorithms. They don't have keys. Do you mean using an algorithm that produces a longer hash output, or one that operates on more bits simultaneously to produce it's output (potentially giving better mixing, for example)?
You are probably right that sequentially applying one hash algorithm to another may not give increased security - impossible to know really without cryptanalysis, but probably not worth taking the chance.
But I think the parent poster is correct to say that applying both hash algorithms to the original file and recording both hash outputs would give increased security, as it would be much, much harder to find a single alternate file that produced a collision for each algorithm. What's likely to work in producing a collision for one algorithm is not likely to work for the other.
It's not necessarily about swapping out protocols, or replacing HTML, or SQL. Although you are right to realise that it would be easier if they were seperate. Examples of this might be if you want to extend your application to mobile access, or to produce a web services interface for business partners to take advantage of. It's a lot easier if your business logic is not mixed up with specific presentation details.
Let's take a slightly different example. Say you upgrade your application and need to change the underlying database structure to support some new requirements. Your way: go through all the code looking for bits that refer to those tables in the database, and update them all manually. The way preferred by the majority of software professionals: update the database code in one place only.
You make your own decisions, of course, and I'm not saying that your decisions are wrong for the kinds of things you're doing. But I'm assuming that they're quite small scale projects, or that you are not responsible for ongoing maintenance issues.
I think you mean that case-INsensitivity is perfectly fine, you insensitive clod...:)
Reputation carries you a long way
on
Delphi Turns 10
·
· Score: 4, Insightful
Delphi was a great language for building windows applications. It's VCL managed to abstract out most of the windows hideousness, enough so that beginners had to learn *nothing* about all of that to make quite good looking, and well behaved applications. If you became more expert, it didn't get in your way either. I stuck with Borland products for years, from Turbo Pascal onwards. Their early products were fast, well structured, high quality beasts that were leaders in their day. The developer community was fantastic.
But Borland, the company, what can I say. And let's just agree to politely ignore the "Inprise" episode. Over many years I reported several critical bugs in the VCL and IDE using their bug reporting tools, with fixes and workarounds provided, and nothing was done - over several product releases. In my last role, we switched from Delphi to C++ Builder, and that did it for me. Buggy, unstable and zero support, even for critical compiler and linker bugs that prevented us from building our applications for weeks at a time.
I feel like a valued friend developed Alzheimers. I still miss the old Borland...
Slashdot Mirror
I have actually seen a Petabox, and it's quite impressive. I work at the UK National Archives, and we have an arrangement with the Internet Archive to archive government web sites. They were kind enough to show us around and explain everything.
The point of the Petabox is that a single person should be able to maintain that amount of storage cheaply. The genius of the design is it's simplicity. All units are identically specced. Their IP addresses are sequential and the units are arranged physically to match, making it extremely simple to locate a malfunctioning rack unit. There is no logical volume management at all. Instead, a home web server locates a requested file and redirects the request to the box on which it lives. All technology is open source and open standards.
All the custom units are mirrored, and arranged in a double sided rack mount with a central heat vent. They all do some pretty sophisticated power management to reduce the cooling requirements.
It's not that you can't create a more resilient architecture; you can. But you can't do it as cheaply, or manage it as efficiently and simply as the Petabox.
I wouldn't use it for critical data with absolute availability requirements. I would use it if I needed to store huge amounts of data cheaply and reasonably securely.
I've only touched the surface of what I was shown, and the extreme focus on simplicity is carried through every aspect of the Petabox's design. I was extremely impressed with it, its design superbly fulfills it's requirements.
It's an interesting problem alright. If I have understood you correctly, the goals are to:
1) Register a unique copy of software with the vendor using 2 servers.
2) That the compromise of one of these servers will not compromise the security of the entire system. Security in this context presumably meaning that the attacker cannot use the compromise to validate arbitrary client machines of his choosing.
3) Provide an online validation method for clients to authenticate their copy and allow it to run each time it is (Logged in? Turned on?)
In practice, most validation schemes attempt to operate off-line for the most part. They may attempt to cryptographically bind a licence key to the machine using some kind of hardware audit when initially registering, avoiding the need for constant online re-validation. Anyway, we'll set aside the obvious scalability problems of forcing online validation globally for all systems, as that is part of your stated goal.
We should also state the assumption that, while the client may be untrusted in the sense that it may attempt to abuse licence keys, we have to trust that the client operating system itself is functioning correctly. If we accept the possibility that the client operating system has been modified, the servers become irrelevant, as the validation checks could simply be bypassed in the first place. There are, of course, ways of making this quite difficult, although, as ever, if you put heavy security in one place, you are inviting attack in another.
With this in mind, the problem then becomes how does a trusted client operating system obtain validation to operate using a valid licence key from a vendor using 2 untrusted servers, over an untrusted network, in such a way that:
(1) if only one of the servers is compromised, the attacker does not gain enough to validate arbitrary clients, and
(2) only one copy of an unmodified client operating system with a particular id can operate simultaneously.
Have I understood the problem correctly?
You are absolutely right about that. I did a back of the envelope calculation without checking how it really worked at all
Still, the basic point holds - you don't want your users typing in a key that long. Most will not get it right, even on the third attempt. I get 20 character licence keys wrong pretty often on the first attempt.
cheers,
Matt
Wow - you put some effort into that. However, the explanation isn't really complete - you aren't using your own terminology consistently, and I still believe your approach suffers from several important and fatal weaknesses. Let's try to tighten up the definitions a little:
So we have the User U, a key exchange X, and an registration server R.
U has a copyid and a private key u_priv.
X has the user's public key u_pub
R has it's own public key r_pub and generates a random string rand.
E_key{ message } means encrypt message using key.
The protocol then runs:
i) U->X: copyid
ii) X->U: E_u_pub{ r_pub }
iii) U->R: E_r_pub{ copyid | u_priv }
iv) R->X: copyid
v) X->R: E_u_pub{ u_pub }
vi) R->U: rand | unlock_instructions
That's my reading of what you wrote; I may have some details wrong, but it's not possible to say from your description. Anyway, taking that protocol as given, let's see where it needs some work.
Assumptions:
1. Is the copyid unique? I'm assuming it is.
Questions:
1. How does the user get their private key?
2. How does the key exchange get the user's public key?
3. (ii) Rather than using a round of communication to get R's public key to the user, why not just give the user the registration server's public key in a certificate? Will it be changing frequently?
4. (iii) Never give out a private key in a communication protocol. There are other ways of authenticating that don't create this weakness.
5. (iv) How is the copyid associated with the user's public key? Step (i) only sends a copyid - but no way of binding the two together.
6. Why are you bothering to protect the user's public key by encrypting it with itself? Public keys are supposed to be public. If it's to allow the use of the private key (which now has to be transmitted) to produce the public key I see what you're trying to do - it provides origin authentication of the user, but it's a really, really nasty way of doing it, and pretty much completely backwards from how public and private keys are supposed to be used and managed.
7) The random string is the shared secret between the user and microsoft. How is this communication protected? As it stands in your description, the string is sent back unencrypted.
Problems:
The security problem is to ensure that the copy of windows is legitimate and is only running on one PC.
1. Most of your protocol seems to be concerned with protecting the confidentiality of the messages exchanged between client and server. There are plenty of good ways of doing this already which are far more secure. SSL/TLS, for example. Don't roll your own security - you will not get it right most times.
2. The result of the protocol is to bind a copyid to a public user key and a random password. What prevents me from using this on many machines?
3. It doesn't solve the problem of preventing piracy. It's simply a rather convoluted key exchange mechanism, of which there are many far simpler, more efficient, and provably more secure methods available.
Forgive me if I sound a little harsh, but you sound like someone who knows a reasonable amount about how public/private key encryption works, but hasn't studied security much.
Hmmmm... I have to take issue with your description of how easy it would be for MS to have really secure key validation.
>print a 1024-bit "public key" on the packet, which matches a private key on the validating server.
OK. That's almost sensible. Except that 1024 bits are 128 ASCII chars. Some of them are unprintable, so using some form of encoding like base 64 would give you 512 characters. That's quite a lot to type for a user to type in, and how do you know you have a legitimate copy of windows and not a Mafia-Hacked (tm) version. Why not use one of those digitally signed "certificate" things people tend to like for public key validation. Anyway, we'll assume that all users have the same Microsoft public key.
> Use the key to generate a unique ID
Here is where it starts getting a bit vague. Generate a unique ID from the same number that all the users have how exactly? Or do you mean that a number is *somehow* generated and then encrypted using the public key?
> which is copied onto the computer.
OK. So now I can copy that number off the computer and onto another one. What prevents me from doing this? How is the number tied to the machine?
> Any subsequent communication...
What communication? You haven't mentioned any so far. I'll assume that somehow in an earlier stage, you sent the number you generated to microsoft. Possibly encrypted by the public key.
> has to match the unique ID and the public key.
What do you mean, *match*? Do you mean that the conversation is encrypted using these numbers? So how do Microsoft know that I'm not simply replaying a communication I intercepted from another machine? How do Microsoft know that the number I generated is a *valid* number? Anyone can make up a number, encrypt it with the publicly avaiable public key, and send it to Microsoft.
I guess you knew what you meant when you wrote the post, but just throwing around the magic words "public key" doesnt' solve the actual security problem, which is to know that the copy of windows running was purchased legitimately.
(BTW: most security people define Availability as a key concept (CIA: Confidentiality, Integrity, Availability). So unfortunately turning the PC off doesn't make it secure. Well - it may make the PC hardware secure from remote attack, but not the information it's being used to manage, nor the physical machine itself.
That's an interesting perspective. I can see that for individual businesses, this may be a harder problem.
From my perspective (I work at the UK National Archives), migrating and maintaining documents, web sites, spreadsheets, presentations, images, audio, video, virtual reality from public enquiries, databases... etc. etc. with the intention that people will be able to read them 1000 years later is our hard problem.
But we don't have to convince our users to upgrade to the tools that the content creator used - we upgrade the content to be in a format they can use without any worries - normally by sticking to open standards, or in the absence of widely spread open standards, de facto ones (like PDF).
Nope - this is nothing to do with when quantum effects "take over" from gravity. The reverse, in fact - those forces already swamp the measurement of such a tiny force as gravity - they had to find ways to rule them out to reveal the gravitational influence.
The experiment is looking for evidence that gravity does not follow Newton's law at very small scales. This is predicted by some theories (notably string theory). Confirmation that gravity behaves "normally" up to these atomic scales rules out some theories which require larger extra dimensions. As a side benefit, they managed to measure the casimir force really accurately too.
Hmmm... just finished reading an excellent book about cosmology (The Fabric of the Cosmos, by Brian Greene). In it, the author clearly states that all objects are constantly moving at the speed of light through space-time.
If you are stationary in space, then you are "moving" at the speed of light through time. Any motion through space reduces your velocity through time - but it always adds up to the speed of light.
I must admit, that idea made me stop and re-read that section of the book a couple of times, as I'd never heard relativity expressed that way before. I may have not entirely presented his arguments correctly (I am not a physicist), but that was the essence of it.
I was marched by security out of a large IT supplier in the UK when they found out I had found another job with a "competitor". They weren't really a competitor, but my boss was an a-hole.
Then they tried to pay me only for the week I'd done so far that month. 30 days notice works both ways. I contacted their HR department and asked them if this was normal company policy (i.e. illegal).
They paid up, and I got a nice one month break before my next job. It all works out somehow...
Free as in SPEECH, not free as in beer. Sheesh - how many times...
Stallman has never said you can't sell software - just that your right to use it, modify it and build on it is protected.
So true. My sister, who isn't particulary technical, recently downloaded some obscure music she was after. But it wouldn't play on her Mac, she didn't realise that it would only play on certain licensed devices, couldn't figure out how to transfer it to her stereo or to play it in her car. And she had no faith that, even if she could get it to play on her "licensed device" that it would remain playable in a few years time, as things move on.
I had to tell her "welcome to the wonderful world of DRM." Needless to say, she hasn't bought any more music online since.
Genius marketing tactics guys.
Very true - I'm with the UK National Archives Digital Preservation department, and we're taking essentially the same position for long term preservation.
Not only that, we clearly can't mandate that members of the public have an expensive office suite installed in order to read public documentation. We may offer it in that format for convenience (to the many who do have Office), but we can't only offer it that way.
This is actually a very good idea, but very hard to implement with current commercial operating systems without driving the user crazy (log in, log out).
The basic problem is that processes run with the full privilege of the logged in user. This violates the principle of least privilege. Why should your web browser be able to format your hard disk? Overwrite your tax documents? Why should your word processor be able to instantiate a network connection? It's not just access to files, it's access to services. The Java sandbox model goes some way to providing this kind of security.
There is some interesting work on distributed capability systems (based around cryptographically protected access tokens attached to the processes, rather than access control lists on objects with user permissions).
Check out http://www.erights.org/ for some very interesting information on these types of system. It's also the home of the E language - a secure language for building distributed capability based systems.
They have a focus on developers who create software that supports their platforms. Microsoft don't care about web developers per se. Web developers are creating applications that don't rely on Microsoft products. The web developers they like create web applications that use IE specific "features".
If Microsoft supported CSS properly, or submitted their new ideas to the standards bodies, IE wouldn't be required. And following on from that, Windows itself could go. Why do you think IE was made a fundamental part of the OS? Why has it not been ported to other platforms?
Eventually, with a rich enough, standardised feature set, maybe even some office type applications could be delivered via a web interface.
They aren't going to do it unless they control the platform. It will be very interesting to see what Avalon offers in terms of delivering rich client functionality remotely. I assume they see this as a web-killer app, as opposed to a web killer-app.
It's not that they're lazy. Microsoft have done a tremendous job in getting developers to create software for their platforms, creating tools and superb documentation, even before they were the de facto standard that they are today. But only for platforms that they control and which incidentally form a huge part of their cash flow.
The danger to Microsoft is rich client applications which can run on any platform through a standard browser. They are not going to do that if they don't have to in order to stay in the game. That would be like asking Turkeys to vote for Christmas.
Sad, but true.
I don't get it - slashdot keeps taking the final 8 off the URL, whether I format it as HTML or plaintext...
2 24 8
http://www.rsasecurity.com/rsalabs/node.asp?id=
Oh well...
Actually, Diffie Hellman is a key exchange protocol, not an authentication protocol. It's also vulnerable to a Man in the Middle attack, since it doesn't perform any authentication at all.
2 24 8
The Station-to-Station protocol was derived later from Diffie Hellman key exchange to add authentication to the key exchange and thus avoid the MITM attack, using digital signatures to authenticate the identities of the parties concerned.
Here's a link that explains more:
http://www.rsasecurity.com/rsalabs/node.asp?id=
This is exactly what does happen. But there are two reasons why a cryptographic entity may be considered broken.
:)
One is the reason you give, that processing power makes brute force searching practical. For example, the most common encryption algorithm in use today is probably DES. It was designed in the 70s, and was explicitly recommended that it's useful shelf life was only for a couple of decades. They already knew back then that processing power would overtake it's usefulness. As time has gone on, numerous other encryption algorithms have risen, including the new standard AES to take it's place, and have been tested extensively, with sufficient time to have a good sense of whether there are any "obvious" flaws in it.
Which brings us to the second reason why a cryptographic product may cease to be useful - an attack on the fundamental way the algorithm works. For example, if you can find a way of pulling out statistical patterns and using that information in some way, you may be able to get around the already known amount of brute-force processing you would have to do, to considerably shorten the attack - which may suddenly make an attack feasible with *current* amounts of processing power. This is what is happening with SHA-1 right now - although the current attack is still not very feasible for most people, it has moved into the "possible" territory for large organisations. And the likelihood is that once one attack has been found, others will follow. So we're all going to migrate away from MD5 and SHA1 to something else. No need to panic just yet, but we need to pay attention when attacks are found that no-one knew about before.
Since we just don't know how "secure" any of our encryption algorithms really are - a new form of mathematical analysis could be found at any time - people keep attacking them, yes, hoping to find that no attack is possible, or of course hoping that they are the ones who find an attack - it can do the career no end of good. But we all benefit when this is done openly.
The longer a cryptographic entity resists attack by all these frighteningly intelligent people, the more secure we all feel. But a new attack is always just around the corner...
My understanding of multi collision attacks is that it is focussed on the sequential applicaiton of a hash function:
e.g.
hash = SHA1( SHA1( message ))
Whereas I think the parent poster is talking about recording two hashes in parallel, using two different algorithms:
hash1 = SHA1( message )
hash2 = MD5( message )
Now the problem is to find a single file message2, with a collision for hash1, and for hash2. This would appear to be considerably harder, even though you can use the collisions from MD5 to feed your SHA1 testing, it is still extremely unlikely that any of them will collide - they're still quite resistant to random collision - nothing has changed there.
Of course, I'm not advocating this as a good practical solution - just pointing out that parallel application of hashes appears to be more secure than using a single one, whereas sequential application has been shown to be vulnerable to multi collision attacks.
Of course, I could be completely wrong about multi collision attacks, and if so, I'd appreciate a better explanation from someone more knowlegeable than I.
The short answer is that if it breaks, it needed fixing anyway. The long answer is that we have no absolute proofs of security, except for impractical things like using one-time-pads.
It is only by resisting cryptanalysis for long periods of time that confidence is built. So given that we have imperfect knowledge, the question becomes: do you want the bad guys (who are looking) to find the vulnerabilities first, if they exist?
Which is why good guys attack security systems.
There is no key. It's a hash algorithm. Morons indeed.
I'm not too clear what you mean by "widening the key" - these are hashing algorithms. They don't have keys. Do you mean using an algorithm that produces a longer hash output, or one that operates on more bits simultaneously to produce it's output (potentially giving better mixing, for example)?
You are probably right that sequentially applying one hash algorithm to another may not give increased security - impossible to know really without cryptanalysis, but probably not worth taking the chance.
But I think the parent poster is correct to say that applying both hash algorithms to the original file and recording both hash outputs would give increased security, as it would be much, much harder to find a single alternate file that produced a collision for each algorithm. What's likely to work in producing a collision for one algorithm is not likely to work for the other.
It's not necessarily about swapping out protocols, or replacing HTML, or SQL. Although you are right to realise that it would be easier if they were seperate. Examples of this might be if you want to extend your application to mobile access, or to produce a web services interface for business partners to take advantage of. It's a lot easier if your business logic is not mixed up with specific presentation details.
Let's take a slightly different example. Say you upgrade your application and need to change the underlying database structure to support some new requirements. Your way: go through all the code looking for bits that refer to those tables in the database, and update them all manually. The way preferred by the majority of software professionals: update the database code in one place only.
You make your own decisions, of course, and I'm not saying that your decisions are wrong for the kinds of things you're doing. But I'm assuming that they're quite small scale projects, or that you are not responsible for ongoing maintenance issues.
I think you mean that case-INsensitivity is perfectly fine, you insensitive clod... :)
Delphi was a great language for building windows applications. It's VCL managed to abstract out most of the windows hideousness, enough so that beginners had to learn *nothing* about all of that to make quite good looking, and well behaved applications. If you became more expert, it didn't get in your way either. I stuck with Borland products for years, from Turbo Pascal onwards. Their early products were fast, well structured, high quality beasts that were leaders in their day. The developer community was fantastic.
But Borland, the company, what can I say. And let's just agree to politely ignore the "Inprise" episode. Over many years I reported several critical bugs in the VCL and IDE using their bug reporting tools, with fixes and workarounds provided, and nothing was done - over several product releases. In my last role, we switched from Delphi to C++ Builder, and that did it for me. Buggy, unstable and zero support, even for critical compiler and linker bugs that prevented us from building our applications for weeks at a time.
I feel like a valued friend developed Alzheimers. I still miss the old Borland...