A hardware virtual machine? You mean like...two PC's?
Some insights about the article
on
Crypto Snake Oil
·
· Score: 4, Interesting
It's pretty well known that there are many snake oil products that deploy cryptography. Bruce Sneier frequently displays snake-oil cryptography products in his newsletter, for instance. And these are just the really obvious ones.
Some time ago, I tried to evaluate if a Enterprise Service Bus (intercomponent communication) was fit enough to be put into a production environment. It said that it had AES encryption build in. When I looked at the manual, it displayed a pop up window where you could choose the key-size. It listed exactly all key sizes that were *not* possible for AES. This was a very short evaluation, I can tell you. This also shows a very important thing about cryptography: the algorithms used say very little about the security of an application.
Generally, the manual for cryptographic services is easy to find. This is simply because cryptography is added at the end of the development lifecycle. This is logical because cryptography is not part of the main functionality of most applications (e.g. mime encryption in email products). It's something that was added after the products main functionality was finished. So just look at the last paragraph, or Appendix Z and you are looking at it.
Sometimes it is easy to see why so many products contain bad cryptography. Take XML signatures for instance. XML signatures themselves contain *references* to the data that is signed and the cryptographic techniques used. If you are to verify an XML digital signature, you *must* check if these are not altered. Furthermore, you must keep the XML schema-definitions on your own disk, and not retrieve them from the internet. Nevertheless, I've not seen any API-documentation even mentioning this rather obvious cryptographic insight. You can rest assured that there will be many implementations that will get this wrong.
Cryptography is hard.
The real insight of this story is the listing of the products into "credence goods". If you can call this new insight. Otherwise, it's just stating the well known/obvious.
True enough. But there is very little reason to full-format it anyway. Same for hard drives really, with the internal error handling and such. For older windows versions I always partition and format in advance using Knoppix or something similar.
Not needed. You make sure that patriotism is the greatest good. Then you say you are in a war - preferably one that you can never win. Anything the media then says is unpatriotic because it is hurting the war. Fortunately, something like that would never happen is a country such as the good old USA, where freedom of speech is the greatest good.
Pitbulls are banned in the Netherlands as well. After many injuries and the fact that these dogs can hardly be trained, some people really thought that enough was enough and banned the race altogether. The reason being that even if they are nice 99% of the time, the other 1% they spend biting little kids to death. For some reason, this did not fare well with politicians, or the public at large. This is one kind of animal that I won't miss. That and the fact that you must be pretty brain-damaged to keep a fighting dog in the neighbourhood anyway.
Not that it got that much to do with this discussion. Society creates it's own rules. We will have to look at them individually to see if they are really needed. I agree with you that this is not always done in the most prudent way. But sometimes it's just a matter of opinion, like with the dogs.
*Both* of the pages need that "garbage" at the end to make this work, just like the MD5 attack. In that sense, you can still trust MD5 certificates. They have already created different X509 certificates using the MD5 attack that both verify, and have different keys. But these certificates need to be generated by the same person creating the attack. It is still impossible to have a random message, create a MD5 or SHA1 hash and then create a collission.
Ehm, this text was written for the predating 2^63 way of finding collissions and should be considered rather out of date, even though the current attack is only for 64 rounds of SHA-1. Oh, and supplying the reference would also be a good idea. Kudo's for reading the document and following the link though.
1 GB memory stick does about 20 dollars/euro's at the moment. Try finding a 40 GB drive for that kind of money. A portable 2.5" still costs 80-100 euro for the cheaper ones. That's times 4 or 5!
I've got the same thing, but I wrapped it up in a laptop instead of a drive enclosure. Unfortunately there this thing called money that you need when you buy an ultra-portable. The 3.8 KB beast I got from work severely does not fit in my pocket (it's fit for home -> car -> office -> car -> relative though).
I do think that many older people lack sufficient internet skills though. There is a lot of good information on the internet, especially about IT. Many books are available online from many brilliant authors. Electronic form also has a lot of advantages, such as easy searching and copying of code. Within the company I am known for finding almost any information needed on the internet. My reading speed and handling of google as well as knowing where to search (standard bodies etc) makes sure that most of the time I find the info I am looking for.
I do agree that there is still a lot to be desired about screens though. If I would be able to buy 2 relatively cheap, high res e-Readers using eInk technology (with a touch-screen for adding remarks), this problem would be solved. For reading quality, books still easily outperform screens, especially if you also use the screen for coding. Also, although much information is readily found on the internet, it doesn't always get as much attention (from other authors and/or editors) as a good book. That said, if you lack book-searching skills, you are as likely to find an outdated book that is simply wrong as finding a misleading internet page.
Once I got a computer science course that required us to buy a book. The teacher admitted that he read the book in about 3 hours during the summer vacation (thus after requiring us to buy the book), and said he did not think much of it. At least you have read the books that you require your students to read. But if you require them to buy three books while only regularly using one, you might have some angry students as well.
I was going to type a reply to scorn you, but this time I was able to kickstart my brain. Ugh, close call. Now I can sit back and wait for the next gullible person to type the reply and sit back and laugh at him. Thank you for that.
And it's late as well. I don't believe so much in virtualization on this level to create security. I mean, how are the components going to communicate? Sockets? Sockets are their own security problem. Microsoft clearly thinks in the same direction. What we need is a more fine-grained security model, in which applications only get the resources they need. Applications themselves also must be able apply the same security directives to their internal components. Just assigning a user per application won't work either, I mean, I would like to continue to work with my text editor as myself.
Currently, applications can install themselves anywhere they want. They can destroy everything I own, including most things in the registry. They can take every bit of CPU power they like. Any amount of memory. Any amount of threads. Any amount of desktop space (including the whole lot through DirectX). They can even take away my keyboard. I don't think you can solve this by just giving every application it's own CPU and operating system. You can do this by restricting access, and by letting the OS take care of the installation and access conditions (maybe not configuration).
The way to do this is to create dependencies with modules, and create security managers to handle access. This is e.g. part of the Java security model, which is sadly hardly ever used. Microsoft has it's own copy of that of course. It's in.net and works with assemblies. Where Microsoft has an advantage is that it owns the Windows operating system, and can therefore easily use a centralized Virtual Machine (as in MSIL virtual machine), installation procedures etc.
I've little doubt that this is the direction Microsoft is thinking for the long run. Unfortunately they don't seem to grasp it on the same abstraction level that Sun can, so it will probably take time. No doubt it will take double that time for Gartner to understand it. Just running every app in its own OS is much easier to grasp, especially when it is already there.
Mod parent up - if I do, I loose my own addition to the discussion. Most block ciphers are quite immune to known plain text attacks. This is at least true for DES and AES. And well implemented stream ciphers are as well (I specifically say "well implemented" because of the the flawed WEP implementation for WiFi).
I'm not so sure I agree with this. First of all, software encryption/decryption is prone to side channel attacks that are hard to defy ("listening" to the CPU to retrieve an RSA key). Hardware may be able to avert such attacks. A hardware random generator is also very nice to have, since it provides a high entropy source which is not dependent on other factors (making it less difficult to change hardware, funny enough).
Speed is also still an issue. I would like to see Tom's test repeated with a VIA C3 as well (I've a 1.2 fanless C3 laying right in front of me, so maybe I'll try when I get the memory for it next monday). If it uses AES, I really expect quite a speedup. CPU's are fast, but IO has quite risen to the challenge. I would really like to see CPU tests next to Tom's tests to see how much impact encryption/decryption has on system performance. Saying that hardware crypto is not needed is a bit like saying SSE3 is not needed IMHO.
CPU's are the best place for cryptographic accelerators. They already run on high speeds, communicate quickly with main memory. If the x86 manufacturers would agree on a specific instruction set (e.g. that one used by VIA) it would be great. As for compatability, just implement AES (128, 192 and 256 bits) for symetric encryption, SHA1, SHA-2 (256, 384 and 512 bits) for secure digests. Add a random number generator as well. RSA and EC (Eliptic Curves) is a bit optional, since they are hardly used for bulk operations on the desktop anyway. For application servers that depend on SSL, an RSA hardware accellerator (montgomery multiplyer) may still be a good idea though.
In the netherlands, you can get 22 Mb/s from certain cable internet providers (e.g. multikabel). That's a solid throughput of 2/3 MB/s. And even then you presume that WiFi can only be used for internet. Note that 11n is meant for home/office use. Maybe you could broaden your views a bit?
On the other hand, I do think that C# is growing *way* to fast. There does not seem to be any constraint. This will not be good for the language. It will be very difficult to create good tools, and understanding the language will get more and more difficult. This will make it much harder to create systems that are managable in the long run. The big Java expansion has been in the API, not in the language. The core API now offers mindboggling amount of - rather well documented and readable - functionality.
By the way, Java is also quite big on Smart Cards and mobile phones. It's starting to get bigger and bigger on embedded and entertainment systems, and realtime Java is picking up speed as well. Hopefully, with the Eclipse environment, we will also see more desktop applications appear. I am certainly working on one...
Java has a pretty well defined, small and functional syntax. This makes it very easy to create good tools for it. The number of (good) IDE's and language tools is simply staggering. This is certainly not the case for python the last time I looked. C# obviously does have a nice IDE available for it. IMHO, it does not compare well to Eclipse, but that's just my opinion.
C# is a very nice language, but it does not seem that Microsoft is showing any constraint in adding features, almost making it some kind of "D" language (look it up). There are many, many more side effects in C# that you need to consider when reading someones code. It also does not really try to be really object oriented or to force people to code correctly (virtual keyword, delegates, etc). For enterprise apps, this *should* kill most support for it, although PHB's may decide otherwise.
"Exactly. Free Software has plenty of JVMs and compilers. Heck, the Free Software world has too many JVMs and compilers. What's needed are Java compatible class libraries under a license that is both amenable to proprietary and Free Software developers."
Try the 1.6 release with the new verifier and better register usage, and I think you will agree that, although there are many VM implementations, there are very few that will outperform this specific version. I do agree that the libraries are the main thing to free though. As long as Sun and the JCP are still the ones making the official version. I would also like more components to use factories and factory methods, so that people can easily drop in their implementations.
Ever heard of splitting things up in modules? The JDK is pretty large as well, but it's not a problem at all to link it to your project. Syntax highlighting is pretty much local to Java files. I've downloaded and compiled the entire Eclipse project on my 1 GB machine without too many problems as well. That should be quite a number of lines.
Something is terribly wrong there. Reminds me about someone complaining that you needed to put classes in folders that reflect the classes package declarations. Yeah, well, duh! How would you use automatic code generation and refactoring without all that?
The only problem I've seen is that large projects tend to take some time to rebuild when settings are changed. Splitting the projects up into seperate projects does the trick in this case. If you cannot, your design is probably pretty broken, at least you could split most packages into projects.
"We don't know which license we're going to use yet. We do know that it will be an OSI-approved license. We also know that any particular license choice is going to disappoint some people, but we don't see any way around that."
That's true, only the thread was started by saying that "compilers and languages to catch up with the concurrency challenges". The article that this post referred to even mentioned Java as a solution on the bottom. Of course, you need to understand multithreading. But in Java, the support is there.
Java is not a silver bullet but it certainly is a viable choice for supporting parallelism. Something that the article and the grandparent seem to be supporting. There is no doubt that there are many other choices as well.
Or you could use 5 1U's for with 8 cores or 32 threads each. Then you would run a cool 160 threads in total. For SSL, it will also use an cryptographic co-processor (RSA only, unfortunately).
Slashdot Mirror
A hardware virtual machine? You mean like...two PC's?
It's pretty well known that there are many snake oil products that deploy cryptography. Bruce Sneier frequently displays snake-oil cryptography products in his newsletter, for instance. And these are just the really obvious ones.
Some time ago, I tried to evaluate if a Enterprise Service Bus (intercomponent communication) was fit enough to be put into a production environment. It said that it had AES encryption build in. When I looked at the manual, it displayed a pop up window where you could choose the key-size. It listed exactly all key sizes that were *not* possible for AES. This was a very short evaluation, I can tell you. This also shows a very important thing about cryptography: the algorithms used say very little about the security of an application.
Generally, the manual for cryptographic services is easy to find. This is simply because cryptography is added at the end of the development lifecycle. This is logical because cryptography is not part of the main functionality of most applications (e.g. mime encryption in email products). It's something that was added after the products main functionality was finished. So just look at the last paragraph, or Appendix Z and you are looking at it.
Sometimes it is easy to see why so many products contain bad cryptography. Take XML signatures for instance. XML signatures themselves contain *references* to the data that is signed and the cryptographic techniques used. If you are to verify an XML digital signature, you *must* check if these are not altered. Furthermore, you must keep the XML schema-definitions on your own disk, and not retrieve them from the internet. Nevertheless, I've not seen any API-documentation even mentioning this rather obvious cryptographic insight. You can rest assured that there will be many implementations that will get this wrong.
Cryptography is hard.
The real insight of this story is the listing of the products into "credence goods". If you can call this new insight. Otherwise, it's just stating the well known/obvious.
True enough. But there is very little reason to full-format it anyway. Same for hard drives really, with the internal error handling and such. For older windows versions I always partition and format in advance using Knoppix or something similar.
Oh, I've heard of it...
Not needed. You make sure that patriotism is the greatest good. Then you say you are in a war - preferably one that you can never win. Anything the media then says is unpatriotic because it is hurting the war. Fortunately, something like that would never happen is a country such as the good old USA, where freedom of speech is the greatest good.
Pitbulls are banned in the Netherlands as well. After many injuries and the fact that these dogs can hardly be trained, some people really thought that enough was enough and banned the race altogether. The reason being that even if they are nice 99% of the time, the other 1% they spend biting little kids to death. For some reason, this did not fare well with politicians, or the public at large. This is one kind of animal that I won't miss. That and the fact that you must be pretty brain-damaged to keep a fighting dog in the neighbourhood anyway.
Not that it got that much to do with this discussion. Society creates it's own rules. We will have to look at them individually to see if they are really needed. I agree with you that this is not always done in the most prudent way. But sometimes it's just a matter of opinion, like with the dogs.
*Both* of the pages need that "garbage" at the end to make this work, just like the MD5 attack. In that sense, you can still trust MD5 certificates. They have already created different X509 certificates using the MD5 attack that both verify, and have different keys. But these certificates need to be generated by the same person creating the attack. It is still impossible to have a random message, create a MD5 or SHA1 hash and then create a collission.
Ehm, this text was written for the predating 2^63 way of finding collissions and should be considered rather out of date, even though the current attack is only for 64 rounds of SHA-1. Oh, and supplying the reference would also be a good idea. Kudo's for reading the document and following the link though.
http://www.heise-security.co.uk/articles/75686
1 GB memory stick does about 20 dollars/euro's at the moment. Try finding a 40 GB drive for that kind of money. A portable 2.5" still costs 80-100 euro for the cheaper ones. That's times 4 or 5!
I've got the same thing, but I wrapped it up in a laptop instead of a drive enclosure. Unfortunately there this thing called money that you need when you buy an ultra-portable. The 3.8 KB beast I got from work severely does not fit in my pocket (it's fit for home -> car -> office -> car -> relative though).
I do think that many older people lack sufficient internet skills though. There is a lot of good information on the internet, especially about IT. Many books are available online from many brilliant authors. Electronic form also has a lot of advantages, such as easy searching and copying of code. Within the company I am known for finding almost any information needed on the internet. My reading speed and handling of google as well as knowing where to search (standard bodies etc) makes sure that most of the time I find the info I am looking for.
I do agree that there is still a lot to be desired about screens though. If I would be able to buy 2 relatively cheap, high res e-Readers using eInk technology (with a touch-screen for adding remarks), this problem would be solved. For reading quality, books still easily outperform screens, especially if you also use the screen for coding. Also, although much information is readily found on the internet, it doesn't always get as much attention (from other authors and/or editors) as a good book. That said, if you lack book-searching skills, you are as likely to find an outdated book that is simply wrong as finding a misleading internet page.
Once I got a computer science course that required us to buy a book. The teacher admitted that he read the book in about 3 hours during the summer vacation (thus after requiring us to buy the book), and said he did not think much of it. At least you have read the books that you require your students to read. But if you require them to buy three books while only regularly using one, you might have some angry students as well.
I was going to type a reply to scorn you, but this time I was able to kickstart my brain. Ugh, close call. Now I can sit back and wait for the next gullible person to type the reply and sit back and laugh at him. Thank you for that.
And it's late as well. I don't believe so much in virtualization on this level to create security. I mean, how are the components going to communicate? Sockets? Sockets are their own security problem. Microsoft clearly thinks in the same direction. What we need is a more fine-grained security model, in which applications only get the resources they need. Applications themselves also must be able apply the same security directives to their internal components. Just assigning a user per application won't work either, I mean, I would like to continue to work with my text editor as myself.
.net and works with assemblies. Where Microsoft has an advantage is that it owns the Windows operating system, and can therefore easily use a centralized Virtual Machine (as in MSIL virtual machine), installation procedures etc.
Currently, applications can install themselves anywhere they want. They can destroy everything I own, including most things in the registry. They can take every bit of CPU power they like. Any amount of memory. Any amount of threads. Any amount of desktop space (including the whole lot through DirectX). They can even take away my keyboard. I don't think you can solve this by just giving every application it's own CPU and operating system. You can do this by restricting access, and by letting the OS take care of the installation and access conditions (maybe not configuration).
The way to do this is to create dependencies with modules, and create security managers to handle access. This is e.g. part of the Java security model, which is sadly hardly ever used. Microsoft has it's own copy of that of course. It's in
I've little doubt that this is the direction Microsoft is thinking for the long run. Unfortunately they don't seem to grasp it on the same abstraction level that Sun can, so it will probably take time. No doubt it will take double that time for Gartner to understand it. Just running every app in its own OS is much easier to grasp, especially when it is already there.
Mod parent up - if I do, I loose my own addition to the discussion. Most block ciphers are quite immune to known plain text attacks. This is at least true for DES and AES. And well implemented stream ciphers are as well (I specifically say "well implemented" because of the the flawed WEP implementation for WiFi).
I'm not so sure I agree with this. First of all, software encryption/decryption is prone to side channel attacks that are hard to defy ("listening" to the CPU to retrieve an RSA key). Hardware may be able to avert such attacks. A hardware random generator is also very nice to have, since it provides a high entropy source which is not dependent on other factors (making it less difficult to change hardware, funny enough).
Speed is also still an issue. I would like to see Tom's test repeated with a VIA C3 as well (I've a 1.2 fanless C3 laying right in front of me, so maybe I'll try when I get the memory for it next monday). If it uses AES, I really expect quite a speedup. CPU's are fast, but IO has quite risen to the challenge. I would really like to see CPU tests next to Tom's tests to see how much impact encryption/decryption has on system performance. Saying that hardware crypto is not needed is a bit like saying SSE3 is not needed IMHO.
CPU's are the best place for cryptographic accelerators. They already run on high speeds, communicate quickly with main memory. If the x86 manufacturers would agree on a specific instruction set (e.g. that one used by VIA) it would be great. As for compatability, just implement AES (128, 192 and 256 bits) for symetric encryption, SHA1, SHA-2 (256, 384 and 512 bits) for secure digests. Add a random number generator as well. RSA and EC (Eliptic Curves) is a bit optional, since they are hardly used for bulk operations on the desktop anyway. For application servers that depend on SSL, an RSA hardware accellerator (montgomery multiplyer) may still be a good idea though.
In the netherlands, you can get 22 Mb/s from certain cable internet providers (e.g. multikabel). That's a solid throughput of 2/3 MB/s. And even then you presume that WiFi can only be used for internet. Note that 11n is meant for home/office use. Maybe you could broaden your views a bit?
Supernovae are *storing* energy? Wow, let's see if I can get my head around that...
On the other hand, I do think that C# is growing *way* to fast. There does not seem to be any constraint. This will not be good for the language. It will be very difficult to create good tools, and understanding the language will get more and more difficult. This will make it much harder to create systems that are managable in the long run. The big Java expansion has been in the API, not in the language. The core API now offers mindboggling amount of - rather well documented and readable - functionality.
By the way, Java is also quite big on Smart Cards and mobile phones. It's starting to get bigger and bigger on embedded and entertainment systems, and realtime Java is picking up speed as well. Hopefully, with the Eclipse environment, we will also see more desktop applications appear. I am certainly working on one...
Java has a pretty well defined, small and functional syntax. This makes it very easy to create good tools for it. The number of (good) IDE's and language tools is simply staggering. This is certainly not the case for python the last time I looked. C# obviously does have a nice IDE available for it. IMHO, it does not compare well to Eclipse, but that's just my opinion.
C# is a very nice language, but it does not seem that Microsoft is showing any constraint in adding features, almost making it some kind of "D" language (look it up). There are many, many more side effects in C# that you need to consider when reading someones code. It also does not really try to be really object oriented or to force people to code correctly (virtual keyword, delegates, etc). For enterprise apps, this *should* kill most support for it, although PHB's may decide otherwise.
"Exactly. Free Software has plenty of JVMs and compilers. Heck, the Free Software world has too many JVMs and compilers. What's needed are Java compatible class libraries under a license that is both amenable to proprietary and Free Software developers."
Try the 1.6 release with the new verifier and better register usage, and I think you will agree that, although there are many VM implementations, there are very few that will outperform this specific version. I do agree that the libraries are the main thing to free though. As long as Sun and the JCP are still the ones making the official version. I would also like more components to use factories and factory methods, so that people can easily drop in their implementations.
JHC!
Ever heard of splitting things up in modules? The JDK is pretty large as well, but it's not a problem at all to link it to your project. Syntax highlighting is pretty much local to Java files. I've downloaded and compiled the entire Eclipse project on my 1 GB machine without too many problems as well. That should be quite a number of lines.
Something is terribly wrong there. Reminds me about someone complaining that you needed to put classes in folders that reflect the classes package declarations. Yeah, well, duh! How would you use automatic code generation and refactoring without all that?
The only problem I've seen is that large projects tend to take some time to rebuild when settings are changed. Splitting the projects up into seperate projects does the trick in this case. If you cannot, your design is probably pretty broken, at least you could split most packages into projects.
"We don't know which license we're going to use yet. We do know that it will be an OSI-approved license. We also know that any particular license choice is going to disappoint some people, but we don't see any way around that."
That's true, only the thread was started by saying that "compilers and languages to catch up with the concurrency challenges". The article that this post referred to even mentioned Java as a solution on the bottom. Of course, you need to understand multithreading. But in Java, the support is there.
Java is not a silver bullet but it certainly is a viable choice for supporting parallelism. Something that the article and the grandparent seem to be supporting. There is no doubt that there are many other choices as well.
Or you could use 5 1U's for with 8 cores or 32 threads each. Then you would run a cool 160 threads in total. For SSL, it will also use an cryptographic co-processor (RSA only, unfortunately).
s .xml
http://www.sun.com/servers/coolthreads/t1000/spec
Of course, it will only run at a measly 1.2 GHz per core, but still.
Would not want to literally tape out one of these beasts :)