Actually, I don't intend to put much work into persuading you of this. I know enough about the subject to know that you need padding. If you think you don't need padding, it is because you don't know enough. Go and learn. Read the paper presenting OAEP, or PSS, or similar, and understand how one builds a security reduction between a hard problem and a cryptographic primitive.
Or just take our word for it.
Or ignore the advice of experts and go and do your own half-baked thing. It's really up to you.
I think you must be misunderstanding what was written. Directly applying the RSA transform to application data for either signing or encryption is entirely insecure whatever the message size and has been known so for some time, so it seems implausble that PKCS would give its blessing to it.
Please quote chapter and verse. Not because it would make you right - if PKCS says that, it's wrong - but because it would be interesting to know if PKCS really does bless such insecure constructions.
I'm, how can I put this, less than convinced by a security analysis from people who think that that's what RSA padding is for. Please go and read some of the papers about padding for encryption and signing.
If you could use SSL, you certainly should. This is only one example of a million possible mistakes, but many many experts have examined SSL very closely and checked for such mistakes.
GPG has been adequately defended here. What's wrong with the loopback approach? It has several security benefits - see the first paragraph of my paper proposing a (broken) cipher for this purpose:
http://www.ciphergoth.org/crypto/mercy/html/intr od uction.html
I can't make any sense of your assertion that we don't have working stateless cryptosystems. There is no problem with encrypting many packets independently; that's what modern modes of operation are designed to do.
Gutmann knows what he is talking about, and is right on every point.
The three PK systems you identify include trust management but don't say anything about trust metrics as Levien defines them, or as the poster needs them. Keynote et al give precise trust information. In this context, trust metrics are meant to give you a way to get indirect, heuristic trust information in the absence of precise trust information.
Incidentally, one of the things you could use such a metric for is to avoid the need for a global namespace - if you just met someone at a club called Snorky, you can use a trust metric to find who people you trust call by that name.
1) A global system of trust metrication, rather than one per website - so I can certify you as a non-troll once and for all, rather than once on each website.
2) A system which is not in the total command of a single website - in other words, one in which different websites can have a different "root of trust".
I'm assuming you want:
3) attack resistance as Raph Levien defines it
since the experience of sites like Kuro5hin especially demonstrate that non-attack-resistant trust metrics are pretty much a waste of time, and I can only assume that those who advocate collateral-damage string-and-sealing-wax methods like blocking IP address blocks don't realise that attack resistance in the trust metric is possible.
My TrustFlow trust metric was designed exactly to fulfill these criteria, and I believe it is the only one that does so at this time. It's pretty simple to understand, and a fast Perl/C implementation is available under the GPL (ask me if you need it relicensed).
As an experiment, I wrote a program that applied TrustFlow to the LiveJournal friends graph. Nearly 70,000 people have now tried it and users mostly report that it does a pretty good job of reflecting who is close to them in the graph.
In theory, you could set a trust root key and a trust threshold, and users could provide PK-signed documents proving that they are trusted to a particular extent by that root key by showing a subset of the trust graph. If you want to do this, though, ask for my help, there are some subtleties.
OK, this made me laugh very hard for a long time...
(would have emailed, but no email in your profile)
What is "secure" depends on where you stand.
on
Open Source DRM
·
· Score: 1
Security is all about proper operation in the face of an adversary. As a result, one person's security is another's insecurity.
If I break into your colo server and use it for bad purposes, I may take steps to stop you getting in in order to kick me out. From your point of view, the box is still the victim of a security vulnerability, while from mine it is now secure.
I want hardware I've paid for be secure in my favour; I don't want it to be secure against me.
You've missed the point of using a public-key signature checking algorithm. The Xbox doesn't have any secrets you can "tease out" by this or any other means - AIUI the key the Xbox uses to check signatures is already well known. You might as well do the signature checking on your own PC and do the timing analysis on that for all the good it'll do you.
I do most of the system administration on Charlie's web server (which also serves my website). I wish he'd warn me when we were in danger of being slashdotted...
Watching the logs it looks like we're OK at the moment, but we don't have all the bandwidth in the world.
Oh and he just signed my emergency passport application, so I'm not going to say anything else rude about him:-)
The mysterious tweak was not restricting a portion of the keyspace; it was the choice of "S-boxes". In DES, the S-boxes are a set of 8 functions that take 6-bit inputs and return 4-bit outputs. They're not specified algorithmically; the standard just says "S-box 1: 0 -> 14, 1 -> 4..." and so on: eight tables, each of which contains 64 4-bit numbers. The S-boxes are central to DES's security; the only other operations in the cipher are bit shuffles and XOR.
When DES was launched, people noticed pretty quickly that these tables had not been filled randomly; they did not pass randomness tests. But IBM (who designed DES) and the NSA (who approved it) were tight-lipped; not only about their design, but about the whole design of DES. Naturally, people suspected a back door.
When differential cryptanalysis was discovered, it was shown that the S-boxes had been specifically hardened against it, and that this was the souce of the pattern seen. Don Coppersmith of IBM had independently discovered DC, calling it the T-attack (T for "tickle"), and had worked out how to defend DES against it.
However, when Mitsuru Matsui discovered linear cryptanalysis, it was found that DES was not specifically hardened against it, and indeed the best academic attack against DES is a linear attack. Since the NSA approved DES, perhaps they did not know about linear cryptanalysis either.
Of course the real NSA back door was always the 56-bit key, and the best practical attack is still brute-force key search.
As a professional cryptographer, I hear this expression of awed belief in the miraculous abilities of the NSA often, but it's generally borne of a lack of understanding of the subject. It's a shame that the extraordinary work of the open cryptographic community over the last quarter century is so little understood.
Maybe I'm being slow, but how does that show otherwise? If I and my five mates had decided to try this, we could also claim to have a bomb. Actually that was one of the first options to spring to mind.
Donning my "crypto expert" hat for Slashdot once again...
I find it very hard to believe that anyone implementing a new system would build something that it was so practical to break. In general, it's not much harder to build a cryptosystem requiring all of the world's computing resources for millenia. Either they had some *very* funny tradeoffs to make, or they've seriously screwed up, and employed people with no clue about modern crypto engineering, or that quote came from someone who did not appreciate the real strength of the cryptographic components used. --
I know quite a lot of math, both number theory and complexity and computability theory, and I read Gödel, Escher, Bach when it came out. To me, this sounds like a fair summary of the problem with this approach. There's no need to be so rude when you're wrong.
With hardware, you can imagine a scenario where you ask it to do exactly the same thing a million times (say, eject a disk); it can do it right 999,999 times and fail on the millionth occasion. But because of the problem the original poster outlined, in order to measure the time between failures of software you have to assess the frequency of the events which tickle the bugs; in the case of the behaviour of script-kiddies, this means that what's supposed to be a very simple statistical measure of reliability incorporates a complex and controversial social model of the behaviour of an unpredictable group of people. --
The software may be open source, but what's the license on the content of the database? I don't want to put huge amounts of work into creating what will become someone else's proprietary content, a la CDDB... --
It's interesting to compare your scorecard with that for Robert A Heinlein's predictions of 1950 for the year 2000 (http://www.xibalba.demon.co.uk/jbr/heinlein.html) . Heinlein scores far worse - 3.6 out of 18, or 20%. --
I believe you on every count, in fact I admire him greatly and consider him to be an extraordinarily clear thinker and a strikingly sober and careful participant in intellectual debate. I was trying to contrast his actual actions with the stereotype many here have of him. --
There's no mention of this on the official cDc website, so we're still short of technical information. How does this compare to alternatives like Freenet and Mojo Nation, which are designed to avoid the mistakes of Gnutella and Napster? And how much closer does it bring us to the first P2P service proposed, Ross Anderson's Eternity Service, which basically describes all the ideal qualities a P2P could have? I'm looking forward to reading what the CDC themselves have to say about it - it's a shame we hear it from the BBC before we hear it from them... --
Slashdot Mirror
Actually, I don't intend to put much work into persuading you of this. I know enough about the subject to know that you need padding. If you think you don't need padding, it is because you don't know enough. Go and learn. Read the paper presenting OAEP, or PSS, or similar, and understand how one builds a security reduction between a hard problem and a cryptographic primitive.
Or just take our word for it.
Or ignore the advice of experts and go and do your own half-baked thing. It's really up to you.
I think you must be misunderstanding what was written. Directly applying the RSA transform to application data for either signing or encryption is entirely insecure whatever the message size and has been known so for some time, so it seems implausble that PKCS would give its blessing to it.
Please quote chapter and verse. Not because it would make you right - if PKCS says that, it's wrong - but because it would be interesting to know if PKCS really does bless such insecure constructions.
I'm, how can I put this, less than convinced by a security analysis from people who think that that's what RSA padding is for. Please go and read some of the papers about padding for encryption and signing.
If you could use SSL, you certainly should. This is only one example of a million possible mistakes, but many many experts have examined SSL very closely and checked for such mistakes.
GPG has been adequately defended here. What's wrong with the loopback approach? It has several security benefits - see the first paragraph of my paper proposing a (broken) cipher for this purpose:
r od uction.html
http://www.ciphergoth.org/crypto/mercy/html/int
I can't make any sense of your assertion that we don't have working stateless cryptosystems. There is no problem with encrypting many packets independently; that's what modern modes of operation are designed to do.
Gutmann knows what he is talking about, and is right on every point.
The three PK systems you identify include trust management but don't say anything about trust metrics as Levien defines them, or as the poster needs them. Keynote et al give precise trust information. In this context, trust metrics are meant to give you a way to get indirect, heuristic trust information in the absence of precise trust information.
Incidentally, one of the things you could use such a metric for is to avoid the need for a global namespace - if you just met someone at a club called Snorky, you can use a trust metric to find who people you trust call by that name.
If I'm interpreting you correctly, you want:
1) A global system of trust metrication, rather than one per website - so I can certify you as a non-troll once and for all, rather than once on each website.
2) A system which is not in the total command of a single website - in other words, one in which different websites can have a different "root of trust".
I'm assuming you want:
3) attack resistance as Raph Levien defines it
since the experience of sites like Kuro5hin especially demonstrate that non-attack-resistant trust metrics are pretty much a waste of time, and I can only assume that those who advocate collateral-damage string-and-sealing-wax methods like blocking IP address blocks don't realise that attack resistance in the trust metric is possible.
My TrustFlow trust metric was designed exactly to fulfill these criteria, and I believe it is the only one that does so at this time. It's pretty simple to understand, and a fast Perl/C implementation is available under the GPL (ask me if you need it relicensed).
As an experiment, I wrote a program that applied TrustFlow to the LiveJournal friends graph. Nearly 70,000 people have now tried it and users mostly report that it does a pretty good job of reflecting who is close to them in the graph.
In theory, you could set a trust root key and a trust threshold, and users could provide PK-signed documents proving that they are trusted to a particular extent by that root key by showing a subset of the trust graph. If you want to do this, though, ask for my help, there are some subtleties.
The metric, and the implementation, are discussed in the Trust Metrics LiveJournal community. I draw your particular attention to the entry describing the metric and the TrustFlow for LiveJournal FAQ.
OK, this made me laugh very hard for a long time...
(would have emailed, but no email in your profile)
Security is all about proper operation in the face of an adversary. As a result, one person's security is another's insecurity.
If I break into your colo server and use it for bad purposes, I may take steps to stop you getting in in order to kick me out. From your point of view, the box is still the victim of a security vulnerability, while from mine it is now secure.
I want hardware I've paid for be secure in my favour; I don't want it to be secure against me.
You've missed the point of using a public-key signature checking algorithm. The Xbox doesn't have any secrets you can "tease out" by this or any other means - AIUI the key the Xbox uses to check signatures is already well known. You might as well do the signature checking on your own PC and do the timing analysis on that for all the good it'll do you.
No, he's saying it's like Godwin's Law - the call to change distro is inevitable in the same way that the mention of Hitler is.
i n' s-Law.html
http://www.catb.org/~esr/jargon/html/entry/Godw
I do most of the system administration on Charlie's web server (which also serves my website). I wish he'd warn me when we were in danger of being slashdotted...
:-)
Watching the logs it looks like we're OK at the moment, but we don't have all the bandwidth in the world.
Oh and he just signed my emergency passport application, so I'm not going to say anything else rude about him
That's not quite right.
The mysterious tweak was not restricting a portion of the keyspace; it was the choice of "S-boxes". In DES, the S-boxes are a set of 8 functions that take 6-bit inputs and return 4-bit outputs. They're not specified algorithmically; the standard just says "S-box 1: 0 -> 14, 1 -> 4..." and so on: eight tables, each of which contains 64 4-bit numbers. The S-boxes are central to DES's security; the only other operations in the cipher are bit shuffles and XOR.
When DES was launched, people noticed pretty quickly that these tables had not been filled randomly; they did not pass randomness tests. But IBM (who designed DES) and the NSA (who approved it) were tight-lipped; not only about their design, but about the whole design of DES. Naturally, people suspected a back door.
When differential cryptanalysis was discovered, it was shown that the S-boxes had been specifically hardened against it, and that this was the souce of the pattern seen. Don Coppersmith of IBM had independently discovered DC, calling it the T-attack (T for "tickle"), and had worked out how to defend DES against it.
However, when Mitsuru Matsui discovered linear cryptanalysis, it was found that DES was not specifically hardened against it, and indeed the best academic attack against DES is a linear attack. Since the NSA approved DES, perhaps they did not know about linear cryptanalysis either.
Of course the real NSA back door was always the 56-bit key, and the best practical attack is still brute-force key search.
As a professional cryptographer, I hear this expression of awed belief in the miraculous abilities of the NSA often, but it's generally borne of a lack of understanding of the subject. It's a shame that the extraordinary work of the open cryptographic community over the last quarter century is so little understood.
Maybe I'm being slow, but how does that show otherwise? If I and my five mates had decided to try this, we could also claim to have a bomb. Actually that was one of the first options to spring to mind.
A deterministically generated pad is not a one-time pad.
About 3,000 have been killed since the sixties in Northern Ireland related violence. I suspect that today's deaths dwarf that figure.
When replying, bear in mind that all articles posted by this userID are trolls.
At the rate I'm losing karma with all this trollbusting, I'll hit the karma cap sometime in 2004.
--
Donning my "crypto expert" hat for Slashdot once again...
I find it very hard to believe that anyone implementing a new system would build something that it was so practical to break. In general, it's not much harder to build a cryptosystem requiring all of the world's computing resources for millenia. Either they had some *very* funny tradeoffs to make, or they've seriously screwed up, and employed people with no clue about modern crypto engineering, or that quote came from someone who did not appreciate the real strength of the cryptographic components used.
--
I know quite a lot of math, both number theory and complexity and computability theory, and I read Gödel, Escher, Bach when it came out. To me, this sounds like a fair summary of the problem with this approach. There's no need to be so rude when you're wrong.
With hardware, you can imagine a scenario where you ask it to do exactly the same thing a million times (say, eject a disk); it can do it right 999,999 times and fail on the millionth occasion. But because of the problem the original poster outlined, in order to measure the time between failures of software you have to assess the frequency of the events which tickle the bugs; in the case of the behaviour of script-kiddies, this means that what's supposed to be a very simple statistical measure of reliability incorporates a complex and controversial social model of the behaviour of an unpredictable group of people.
--
The software may be open source, but what's the license on the content of the database? I don't want to put huge amounts of work into creating what will become someone else's proprietary content, a la CDDB...
--
It's interesting to compare your scorecard with that for Robert A Heinlein's predictions of 1950 for the year 2000 (http://www.xibalba.demon.co.uk/jbr/heinlein.html) . Heinlein scores far worse - 3.6 out of 18, or 20%.
--
I believe you on every count, in fact I admire him greatly and consider him to be an extraordinarily clear thinker and a strikingly sober and careful participant in intellectual debate. I was trying to contrast his actual actions with the stereotype many here have of him.
--
There's no mention of this on the official cDc website, so we're still short of technical information. How does this compare to alternatives like Freenet and Mojo Nation, which are designed to avoid the mistakes of Gnutella and Napster? And how much closer does it bring us to the first P2P service proposed, Ross Anderson's Eternity Service, which basically describes all the ideal qualities a P2P could have? I'm looking forward to reading what the CDC themselves have to say about it - it's a shame we hear it from the BBC before we hear it from them...
--
Furthermore, the person that Newton was speaking to at the time was unusually short.
--