Unless you can prove that your usage of raw RSA is secure, you should use the recommended standard of padding. I suggest you look at PKCS #1 v2.1. http://www.rsasecurity.com/rsalabs/pkcs/index.html
It is your choice to fix weaknesses and possible weaknesses. Do you want to be reasonable secure or not?
As for the RSA argument: assuming you're referring to the problem of page 236 of Practical Cryptography by Ferguson and Schneier: tinc uses the 0xFFFF value for the rsa e value...
Did you miss "This very same structure invites many types of attacks. The simple ones we've mentioned in the previous paragraph. There are far more advanced attacks,..."?
We won't, because it is not a problem. Many parts of the packets that are sent are predictable, because there is a lot of redundancy in them (think MAC, IP and TCP headers and trailers). That doesn't matter for the rest of the packet, or symmetric ciphers in general would be pretty worthless. You send many predictable things via SSL as well (think HTTP requests).
You want to screw with the basic CBC mode of operation by feeding it a poor IV, a predictable IV, because you are being lazy? SSL and predictable HTTP requests are a red herring.
We don't encrypt messages shorter that the key with RSA.
The 128-bit blowfish is shorter than the 2048-bit RSA public key.
Well check again, that is exactly why the attack you describe won't work.
Mallory encrypts S1 with Bob's public key E_b(S1) and sends that (METAKEY E_b(S1)) to Bob. Bob sends S2 encrypted with Alice's public key, METAKEY E_a(S2) to Mallory.
Mallory creates a new connection (as Mallory) to Alice and sends METAKEY E_a(S2) to Alice, as his challenge to Alice. Alice replies with METAKEY E_m(S3) to Mallory.
Mallory encrypts S3 with Bob's public key E_b(S3) and sends that (METAKEY E_b(S3)) to Bob, as if it came from Mallory. Bob sends S4 encrypted with Mallory's public key, METAKEY E_m(S4) to Mallory.
Mallory send CHALLENGE H1 to Bob, encrypted with S1 (that Mallory knows). Bob replies with CHALLENGE H2, encrypted with S2, to Mallory. Mallory sends CHALLENGE H2 encrypted with S2 to Alice. Alice replies to Mallory with CHALLENGE H3 encrypted with S3.
Mallory sends CHAL_REPLY SHA1(H2) encrypted with S1 to Bob, Bob responds with CHAL_REPLY SHA1(H1) encrypted with S2 to Mallory. Mallory sends CHAL_REPLY SHA1(H1) encrypted with S2 to Alice. Alice responds with CHAL_REPLY SHA1(H2) encrypted with S3 to Mallory.
The challenge is encrypted with one key and the challenge reply is encrypted using the other key. If Mallory switched out a key then either the challenge or the challenge reply is going to be encrypted with a key that the first side didn't expect and the challenge will fail (after decryption, only garbage remains).
So is the documentation is wrong or not? If 6.3.1 Authentication protocol is correct, then the attack I described works.
I did miss that there is two symmetric keys, S1 and S2, but I don't think that doesn't matter in this case.
Mallory only created the key that is used to encrypt traffic TO Bob. He can't use it to decrypt the challenge he gets FROM Bob. The key Bob uses to send messages to Mallory is sent to Mallory encrypted with Alices public key.
So the protocol docs is wrong when it says:
From now on:
- the client will symmetrically encrypt outgoing traffic using S1
- the server will symmetrically encrypt outgoing traffic using S2
Mallory could forward the challenge from Bob to Alice, and she would send a correct reply back to Mallory, but Mallory cannot decrypt that one either (because the key used to encrypt the challenge is sent encrypted with Bob's public RSA key), so he cannot forward it to Bob.
Mallory simply forwards the reply (CHAL_REPLY 816a86) from Alice to Bob, no need to decrypt.
But Bob also sends an encrytped challenge string to Mallory, which he has to decrypt, hash, and send it back to Bob. He can't do that because he doesn't know the right key.
Mallory created the session key, so of course he can decrypt using it, hash the challenge and send the hashed challenge back to Bob.
He can't forward it to Alice and forward Alice's reply back to Bob, because he can't decrypt and reencrypt it.
Mallory does have to splice together two channels together to make the attack work, but I do not see why this would not work.
There are some points where tinc could certainly be improved (some of it already planned for 2.0), but we don't believe the "real problem" he mentions actually exists.
So which flaws do you plan on fixing?
the 32 bit predictable IV
This is simple to fix, just fix it. Don't waste your time on whether or not it may or may not be a problem in the "real world", computer security is like programming Satan's Computer, always expect the unexpected and preempt any possible attack.
The messages encrypted with RSA are indeed not padded, but padding is, AFAIK, only necessary when the message is shorter than the RSA key. In our case, the message is exactly as long as the RSA key.
Sigh. Why do you think that? RSA should not be used "raw" -- that is without padding for either encryption or signing.
Sure. Each side sends the key used for encryption of the TCP connection to the other side, encrypted using the public RSA key (which is known beforehand) of the other side. Noone except the owners of the private part of the RSA keys can decrypt this. So there is no way to determine the keys used to encrypt the rest of the TCP connection for a man in the middle.
So, Alice wishes to establish a connection with Bob, and Mallory is the active attacker who can insert, delete, and modify packets on the network.
Alice encrypts the session key with Bob's public key, and sends it across the network. Mallory takes the packets and deletes it. Mallory encrypts his own session key with Bob's public key, and sends it to Bob. Mallory then creates a second (possibly different) session key and encrypts it with Alice's public key and sends it to Alice. Mallory sends Bob a encrypted challenge string, and Bob replies with hashed results. Mallory repeats this with Alice.
Mallory can now carry out his man in the middle attack with these new connection. He cannot read what Alice is sending Bob, since he cannot decrypt the session key encrypted with Bob's RSA public key, but he can pretend to be Alice when communicating to Bob, and Mallory can pretend to be Bob when communicating with Alice.
So, I'm not allowed to take a defensive stance if I believe he claims it's worse than it is? I should readily accept everything someone with has been working longer with encryption than I did?
Well, frankly I rank his opinion above yours when it comes to cryptography.
If you have any facts to back up your assertions that his claims are flaws, please feel free to share them with us. Show me the protocol design, and how is resists the attacks Peter mentions.
It just seems to me you are overreacting if you dismiss our work outright when we merily take some of his remarks in question. We don't dismiss Peter's analysis, we just want to make sure what is right and what is wrong.
Then make some effort to clarify away any confusion. Why can the chess grandmaster attack not succeed with tinc? How does tinc resist all the attacks mention in his letter/essay/comments? Protocol and related attacks against used on SSH (v1 and v2, implmentations from SSH Inc. and OpenSSH), SSL (all versions), PGP (incld. OpenPGP and GPG)?
To make it clear: Security software is assumed insecure by default. Through careful design, implementation, and auditing security / crypto software gains a reputation for being secure. No one is trying to personally attack you or your work, I think more than 99% of all software is insecure.
When I start selling you my project as shinola, you can tell me that it's a shitty product. Until then, you're welcome to contribute. If you just want to criticise, then I'll thank for your input, but advise you to calm down and take a chill pill.
Well, Peter Gutmann did provide useful insight for the programmers involved in these open source projects. What frustrated him was some of them ignored him, or simply did not know enough about security to understand his comments. That is the kiss of death for these projects IMHO.
He contribued far more insight to these projects than dozens of inexperienced programmers did previously.
Anybody using my project is liable to be doing so because they enjoy playing with it as much as me, not because they're relying on it for a critical application.
Sorry, I don't just use open source software for fun and enjoyable, I use it to get things to done in the real world. You are basically taking a cop-out, either your project (at the current time) is secure or it is not. If it is not secure, don't pretend that it is.
How easy would it be to replace CRC-32 with something else in CIPE?
It is not just changing a few hundred lines of code. The network protocol was insecure by design not just in its implementation. To make off the cuff attempts to fix it are worthless, a good security protocol needs to be designed. Designed to resist known attacks, and in a manner to try to minimise damage from unknown attacks.
It takes alot of work and very hard to get a security protocol right, Security Engineering by Prof. Ross Anderson describes how a published 3 line protocol (written in BAN logic, a very high level pseudo code) had a flaw for over 10 years.
There are some points where tinc could certainly be improved (some of it already planned for 2.0), but we don't believe the "real problem" he mentions actually exists. We have told him our objections to his writeup, and asked if he could prove or make it more plausible that an attack on the authentication protocol is possible.
Beautiful. Bloody beautiful.
You, with no real security experience, seem to think you know more than Peter Gutmann, who has been working on cryptography and computer security since the mid-1990s. That's rich.
He still hasn't convinced us.
Newsflash: That's not how security works. He has no obligation to convince people who are ignorant of security that there software is flawed. Security needs to demostrate why it is provable and verifiably secure.
Peter Gutmann believes there is a possible MITM attack ("Chess grandmaster attack"), but hasn't shown us how, just that he believes it's there.
I doubt Peter was imagining things. If you cannot follow his comments, I am seriously concerned about how prepared you are to write any security software. I found his writing quite clear, though perhaps you do not understand it is not a flaw in a number of lines of code, but a flaw in the entire protocol being used, a protocol you (your group) created.
We're still in discussion, and if we believe there is really a problem we will fix it.
Wow, I'm now inspired to never to use your software.
First, the CRC32 problems only put it on par with ssh 1. Which is still in use by many people I suspect. ok it should have been fixed.
Whether someone else is naked on the Internet does not matter. Insecure software should not be used when better, secure, solutions exist, including free software solutions, e.g. OpenSSH.
CIPE was poorly designed, the author(s) ignored known failures in similar protocols (e.g. ssh v1, ssl v1), I don't see why anyone should try to defend these problems. Fix them, or if you are a user - ask that they are fixed. Actual security should be a priority in any "security" software.
The security and cryptography field just highlights the problem because there are so many opportunities to do something particularly stupid in those fields. Anyone can write a cryptosystem that they can't break themselves. Unfortunately a lot of people figure if they can't break it, then neither can anyone else...
And if it does fail, it may not be obvious. The failure controlled by an attacker is not random, and may never be seen by the user.
You notice when your server crashes, you notice then the power goes out, but do you notice when the attack uses the "grandmaster chess attack" against an insecure VPN solution? In most cases not until after money is missing from the user's bank account (or whatever the VPN was protecting).
Now, having said that, I use VTUN and haven't had any problems. But then again, I also have the boxen firewalled to hell and back, no services allowed but SSH from a few known hosts, no root SSH, etc. So even if you do crack my key, you're not getting much that will get you anywhere.
Security failures are typically not obvious. They are not like a normal (accidental) failure which tends be random and uncontrolled so it is apparent to the user. An attacker that does not what her attack known, you likely won't know if they gain unauthorized access to your VPN or internal network.
Note that the attacker does not need your VPN keys, they simply bypasses the VTUN attempt at security, and can possibly gain direct access into your VPN or internal network.
While I don't consider it the most secure tool, it does the trick well enough for now.
How can be certain that an attacker is not breaking into your network?
His advice is "Stop trying to reinvent the wheel and use the stuff that we already know works, like SSL and IPsec."
The problem is that there are too many people out there who think that these standards are too complex and so they go and try to make something simpler. But it's the complexity that makes them secure. It's like deciding that 3DES is too complex, so you'll just go use ROT-13 since you can wrap your head around it.
Good insight. SSL in commonly useage is version 3 (1995) the first version (1994) being seriously broken, and version 2 (also 1994) had serious flaws, and there is TLS (RFC 2246) 1.0 is a standard and recommended extensions are available. It has taken a lot of experts a long time to get it right, and it needs minor maintance from time to time.
Now, what WOULD be useful is for someone to refactor OpenSSL into a library that people could actually use. If they could just change a couple function calls, edit their makefile, and it would magically work, we'd see a lot more people using really secure protocols.
The reason OpenSSL is so complex is that it tries very hard to be the highest performance (read: platform and processor specific assembly) on a wide variety of processors and OSes, attempts to implement things correctly and includes tests to verify the library.
OpenSSL is not that hard for the application developer to actually use, but I am afraid that cryptography (and computer security in general) demands that the implmenter has a bit of a clue, and cannot simply #include and have it magically secure everything.
My mom loves the STCB series, and that's the audience No Starch is going for with this book - those that don't really know much about the internet or computer security. It's a good read with interesting anecdotes.
These books are written by computer security professionals who may their living both doing computer security and teaching computer security (SANS and Foundstone).
Steal This Computer Book seems to be aimed at too young to know they are getting ripped off kids and computer novices. So don't buy this book if you are over 10.
Re:Articles like this don't make me want to use C/
on
Secure Programming
·
· Score: 2, Insightful
Seriously, let's say I write an application to manage a little local computer store, why should I use C and potentially ship a lot of memory-related bugs with my app when I can use something like Lisp or Python or O'Caml which all are stable, complete and powerful languages in which that task would be easy and would result in a better application?
So you don't want to have memory allocation and pointer issues. Fine. That does not make your programs secure which is the end goal of secure programming in ____.
You still have issues of data/input validation, principle of least priviledges, secure (confidential and/or authenticated and robust) communications, sanitizing the enviornment, dropping unnecessary priviledges (and designing the program so it can drop priviledges early on before user/network client interaction), race conditions, error handling, and many many other tedious yet important issues.
Mrs. Torres, your daughter was doing something illegal.
Actually, until the 1990s her daughter was not doing anything criminal. Thus until recently she was not doing anything illegal.
Until the mid 1990s, copyright infringement was not a criminal activity, and the copyright owner (which not necessarily the creator / preformer) had to take the infringer to civil court and sue to for damages.
Think of this: some copying of music is legal, for example you can make a time-shifting recording from an off-the-air radio broadcast to your audio cassette deck, and then listen to your favorite song again later. You can freely copy music that is in the public domain (assuming the performance and source recording is also freely redistributable). So a person does not commit an illegal activity simply by copying a music recording. In the case where the person does not have the copyright holder's permission, and it does not fall within the fair use (or fair dealings in some countries) exceptions it may be civil or (now) criminal copyright infringement.
Slashdot Mirror
Unless you can prove that your usage of raw RSA is secure, you should use the recommended standard of padding. I suggest you look at PKCS #1 v2.1. http://www.rsasecurity.com/rsalabs/pkcs/index.html
It is your choice to fix weaknesses and possible weaknesses. Do you want to be reasonable secure or not?
As for the RSA argument: assuming you're referring to the problem of page 236 of Practical Cryptography by Ferguson and Schneier: tinc uses the 0xFFFF value for the rsa e value ...
..."?
Did you miss "This very same structure invites many types of attacks. The simple ones we've mentioned in the previous paragraph. There are far more advanced attacks,
We won't, because it is not a problem. Many parts of the packets that are sent are predictable, because there is a lot of redundancy in them (think MAC, IP and TCP headers and trailers). That doesn't matter for the rest of the packet, or symmetric ciphers in general would be pretty worthless. You send many predictable things via SSL as well (think HTTP requests).
You want to screw with the basic CBC mode of operation by feeding it a poor IV, a predictable IV, because you are being lazy? SSL and predictable HTTP requests are a red herring.
We don't encrypt messages shorter that the key with RSA.
The 128-bit blowfish is shorter than the 2048-bit RSA public key.
Well check again, that is exactly why the attack you describe won't work.
Mallory encrypts S1 with Bob's public key E_b(S1) and sends that (METAKEY E_b(S1)) to Bob. Bob sends S2 encrypted with Alice's public key, METAKEY E_a(S2) to Mallory.
Mallory creates a new connection (as Mallory) to Alice and sends METAKEY E_a(S2) to Alice, as his challenge to Alice. Alice replies with METAKEY E_m(S3) to Mallory.
Mallory encrypts S3 with Bob's public key E_b(S3) and sends that (METAKEY E_b(S3)) to Bob, as if it came from Mallory. Bob sends S4 encrypted with Mallory's public key, METAKEY E_m(S4) to Mallory.
Mallory send CHALLENGE H1 to Bob, encrypted with S1 (that Mallory knows). Bob replies with CHALLENGE H2, encrypted with S2, to Mallory. Mallory sends CHALLENGE H2 encrypted with S2 to Alice. Alice replies to Mallory with CHALLENGE H3 encrypted with S3.
Mallory sends CHAL_REPLY SHA1(H2) encrypted with S1 to Bob, Bob responds with CHAL_REPLY SHA1(H1) encrypted with S2 to Mallory. Mallory sends CHAL_REPLY SHA1(H1) encrypted with S2 to Alice. Alice responds with CHAL_REPLY SHA1(H2) encrypted with S3 to Mallory.
The challenge is encrypted with one key and the challenge reply is encrypted using the other key. If Mallory switched out a key then either the challenge or the challenge reply is going to be encrypted with a key that the first side didn't expect and the challenge will fail (after decryption, only garbage remains).
So is the documentation is wrong or not? If 6.3.1 Authentication protocol is correct, then the attack I described works.
I did miss that there is two symmetric keys, S1 and S2, but I don't think that doesn't matter in this case.
Mallory only created the key that is used to encrypt traffic TO Bob. He can't use it to decrypt the challenge he gets FROM Bob. The key Bob uses to send messages to Mallory is sent to Mallory encrypted with Alices public key.
So the protocol docs is wrong when it says:
From now on:
- the client will symmetrically encrypt outgoing traffic using S1
- the server will symmetrically encrypt outgoing traffic using S2
Mallory could forward the challenge from Bob to Alice, and she would send a correct reply back to Mallory, but Mallory cannot decrypt that one either (because the key used to encrypt the challenge is sent encrypted with Bob's public RSA key), so he cannot forward it to Bob.
Mallory simply forwards the reply (CHAL_REPLY 816a86) from Alice to Bob, no need to decrypt.
But Bob also sends an encrytped challenge string to Mallory, which he has to decrypt, hash, and send it back to Bob. He can't do that because he doesn't know the right key.
Mallory created the session key, so of course he can decrypt using it, hash the challenge and send the hashed challenge back to Bob.
He can't forward it to Alice and forward Alice's reply back to Bob, because he can't decrypt and reencrypt it.
Mallory does have to splice together two channels together to make the attack work, but I do not see why this would not work.
There are some points where tinc could certainly be improved (some of it already planned for 2.0), but we don't believe the "real problem" he mentions actually exists.
So which flaws do you plan on fixing?
the 32 bit predictable IV
This is simple to fix, just fix it. Don't waste your time on whether or not it may or may not be a problem in the "real world", computer security is like programming Satan's Computer, always expect the unexpected and preempt any possible attack.
The messages encrypted with RSA are indeed not padded, but padding is, AFAIK, only necessary when the message is shorter than the RSA key. In our case, the message is exactly as long as the RSA key.
Sigh. Why do you think that? RSA should not be used "raw" -- that is without padding for either encryption or signing.
Sure. Each side sends the key used for encryption of the TCP connection to the other side, encrypted using the public RSA key (which is known beforehand) of the other side. Noone except the owners of the private part of the RSA keys can decrypt this. So there is no way to determine the keys used to encrypt the rest of the TCP connection for a man in the middle.
So, Alice wishes to establish a connection with Bob, and Mallory is the active attacker who can insert, delete, and modify packets on the network.
Alice encrypts the session key with Bob's public key, and sends it across the network. Mallory takes the packets and deletes it. Mallory encrypts his own session key with Bob's public key, and sends it to Bob. Mallory then creates a second (possibly different) session key and encrypts it with Alice's public key and sends it to Alice. Mallory sends Bob a encrypted challenge string, and Bob replies with hashed results. Mallory repeats this with Alice.
Mallory can now carry out his man in the middle attack with these new connection. He cannot read what Alice is sending Bob, since he cannot decrypt the session key encrypted with Bob's RSA public key, but he can pretend to be Alice when communicating to Bob, and Mallory can pretend to be Bob when communicating with Alice.
So, I'm not allowed to take a defensive stance if I believe he claims it's worse than it is? I should readily accept everything someone with has been working longer with encryption than I did?
Well, frankly I rank his opinion above yours when it comes to cryptography.
If you have any facts to back up your assertions that his claims are flaws, please feel free to share them with us. Show me the protocol design, and how is resists the attacks Peter mentions.
It just seems to me you are overreacting if you dismiss our work outright when we merily take some of his remarks in question. We don't dismiss Peter's analysis, we just want to make sure what is right and what is wrong.
Then make some effort to clarify away any confusion. Why can the chess grandmaster attack not succeed with tinc? How does tinc resist all the attacks mention in his letter/essay/comments? Protocol and related attacks against used on SSH (v1 and v2, implmentations from SSH Inc. and OpenSSH), SSL (all versions), PGP (incld. OpenPGP and GPG)?
To make it clear: Security software is assumed insecure by default. Through careful design, implementation, and auditing security / crypto software gains a reputation for being secure. No one is trying to personally attack you or your work, I think more than 99% of all software is insecure.
When I start selling you my project as shinola, you can tell me that it's a shitty product. Until then, you're welcome to contribute. If you just want to criticise, then I'll thank for your input, but advise you to calm down and take a chill pill.
Well, Peter Gutmann did provide useful insight for the programmers involved in these open source projects. What frustrated him was some of them ignored him, or simply did not know enough about security to understand his comments. That is the kiss of death for these projects IMHO.
He contribued far more insight to these projects than dozens of inexperienced programmers did previously.
Anybody using my project is liable to be doing so because they enjoy playing with it as much as me, not because they're relying on it for a critical application.
Sorry, I don't just use open source software for fun and enjoyable, I use it to get things to done in the real world. You are basically taking a cop-out, either your project (at the current time) is secure or it is not. If it is not secure, don't pretend that it is.
How easy would it be to replace CRC-32 with
something else in CIPE?
It is not just changing a few hundred lines of code. The network protocol was insecure by design not just in its implementation. To make off the cuff attempts to fix it are worthless, a good security protocol needs to be designed. Designed to resist known attacks, and in a manner to try to minimise damage from unknown attacks.
It takes alot of work and very hard to get a security protocol right, Security Engineering by Prof. Ross Anderson describes how a published 3 line protocol (written in BAN logic, a very high level pseudo code) had a flaw for over 10 years.
There are some points where tinc could certainly be improved (some of it already planned for 2.0), but we don't believe the "real problem" he mentions actually exists. We have told him our objections to his writeup, and asked if he could prove or make it more plausible that an attack on the authentication protocol is possible.
Beautiful. Bloody beautiful.
You, with no real security experience, seem to think you know more than Peter Gutmann, who has been working on cryptography and computer security since the mid-1990s. That's rich.
He still hasn't convinced us.
Newsflash: That's not how security works. He has no obligation to convince people who are ignorant of security that there software is flawed. Security needs to demostrate why it is provable and verifiably secure.
Peter Gutmann believes there is a possible MITM attack ("Chess grandmaster attack"), but hasn't shown us how, just that he believes it's there.
I doubt Peter was imagining things. If you cannot follow his comments, I am seriously concerned about how prepared you are to write any security software. I found his writing quite clear, though perhaps you do not understand it is not a flaw in a number of lines of code, but a flaw in the entire protocol being used, a protocol you (your group) created.
We're still in discussion, and if we believe there is really a problem we will fix it.
Wow, I'm now inspired to never to use your software.
First, the CRC32 problems only put it on par with ssh 1. Which is still in use by many people I suspect. ok it should have been fixed.
Whether someone else is naked on the Internet does not matter. Insecure software should not be used when better, secure, solutions exist, including free software solutions, e.g. OpenSSH.
CIPE was poorly designed, the author(s) ignored known failures in similar protocols (e.g. ssh v1, ssl v1), I don't see why anyone should try to defend these problems. Fix them, or if you are a user - ask that they are fixed. Actual security should be a priority in any "security" software.
The security and cryptography field just highlights the problem because there are so many opportunities to do something particularly stupid in those fields. Anyone can write a cryptosystem that they can't break themselves. Unfortunately a lot of people figure if they can't break it, then neither can anyone else...
And if it does fail, it may not be obvious. The failure controlled by an attacker is not random, and may never be seen by the user.
You notice when your server crashes, you notice then the power goes out, but do you notice when the attack uses the "grandmaster chess attack" against an insecure VPN solution? In most cases not until after money is missing from the user's bank account (or whatever the VPN was protecting).
Now, having said that, I use VTUN and haven't had any problems. But then again, I also have the boxen firewalled to hell and back, no services allowed but SSH from a few known hosts, no root SSH, etc. So even if you do crack my key, you're not getting much that will get you anywhere.
Security failures are typically not obvious. They are not like a normal (accidental) failure which tends be random and uncontrolled so it is apparent to the user. An attacker that does not what her attack known, you likely won't know if they gain unauthorized access to your VPN or internal network.
Note that the attacker does not need your VPN keys, they simply bypasses the VTUN attempt at security, and can possibly gain direct access into your VPN or internal network.
While I don't consider it the most secure tool, it does the trick well enough for now.
How can be certain that an attacker is not breaking into your network?
If you are looking for a good vpn package for linux,
So how do we know it's secure?
It doesn't look like snake oil, but how do we attempt to verfiy its security claims?
I don't see any documents descripting its protocols and security model in detail.
His advice is "Stop trying to reinvent the wheel and use the stuff that we already know works, like SSL and IPsec."
The problem is that there are too many people out there who think that these standards are too complex and so they go and try to make something simpler. But it's the complexity that makes them secure. It's like deciding that 3DES is too complex, so you'll just go use ROT-13 since you can wrap your head around it.
Good insight. SSL in commonly useage is version 3 (1995) the first version (1994) being seriously broken, and version 2 (also 1994) had serious flaws, and there is TLS (RFC 2246) 1.0 is a standard and recommended extensions are available. It has taken a lot of experts a long time to get it right, and it needs minor maintance from time to time.
Now, what WOULD be useful is for someone to refactor OpenSSL into a library that people could actually use. If they could just change a couple function calls, edit their makefile, and it would magically work, we'd see a lot more people using really secure protocols.
The reason OpenSSL is so complex is that it tries very hard to be the highest performance (read: platform and processor specific assembly) on a wide variety of processors and OSes, attempts to implement things correctly and includes tests to verify the library.
OpenSSL is not that hard for the application developer to actually use, but I am afraid that cryptography (and computer security in general) demands that the implmenter has a bit of a clue, and cannot simply #include and have it magically secure everything.
There is no silver bullet, even in cryptography.
My mom loves the STCB series, and that's the audience No Starch is going for with this book - those that don't really know much about the internet or computer security. It's a good read with interesting anecdotes.
She might also enjoy the earlier writings of Robert Glass, I think Universal Elixir and Other Computing Projects Which Failed and Computing Catastrophes are classic general audience books that anyone could enjoy.
If this is at all like the previous editions of the same title, then I recommend you Skip this Computer Book.
Get a decent book about computer abuse/misuse:
Hacking Exposed, 4th edition
Hackers Beware, by Eric Cole
Counterhack, by Ed Skoudis
These books are written by computer security professionals who may their living both doing computer security and teaching computer security (SANS and Foundstone).
Steal This Computer Book seems to be aimed at too young to know they are getting ripped off kids and computer novices. So don't buy this book if you are over 10.
Seriously, let's say I write an application to manage a little local computer store, why should I use C and potentially ship a lot of memory-related bugs with my app when I can use something like Lisp or Python or O'Caml which all are stable, complete and powerful languages in which that task would be easy and would result in a better application?
So you don't want to have memory allocation and pointer issues. Fine. That does not make your programs secure which is the end goal of secure programming in ____.
You still have issues of data/input validation, principle of least priviledges, secure (confidential and/or authenticated and robust) communications, sanitizing the enviornment, dropping unnecessary priviledges (and designing the program so it can drop priviledges early on before user/network client interaction), race conditions, error handling, and many many other tedious yet important issues.
Mrs. Torres, your daughter was doing something illegal.
Actually, until the 1990s her daughter was not doing anything criminal. Thus until recently she was not doing anything illegal.
Until the mid 1990s, copyright infringement was not a criminal activity, and the copyright owner (which not necessarily the creator / preformer) had to take the infringer to civil court and sue to for damages.
Think of this: some copying of music is legal, for example you can make a time-shifting recording from an off-the-air radio broadcast to your audio cassette deck, and then listen to your favorite song again later. You can freely copy music that is in the public domain (assuming the performance and source recording is also freely redistributable). So a person does not commit an illegal activity simply by copying a music recording. In the case where the person does not have the copyright holder's permission, and it does not fall within the fair use (or fair dealings in some countries) exceptions it may be civil or (now) criminal copyright infringement.
This is a terrible slashdot article, no hype, no good in-jokes, no mindless "____ is the next big thing".
Next you'll expect slashdot readers to actually learn something about the history of computing, and the basics of computer science, and information technology.
did a statistically significant portion of the workforce on vacation this week?
In areas affected by the power outage, yes. My colleagues in Ottawa are not allowed to go to work until Monday, in order to converse power.
Generally 'taught' Masters are shorter than the 'research' Masters,
taught or one-year Masters are also known as "terminal" Masters, meaning you cannot use them towards getting a Ph.D.