>People think that adding encryption to something makes it more secure. No, it does not. Encryption is worthless without > secure key exchange,
This is false; encrypting everything by default significantly increases the barrier to casual eavesdropping. Letters are usually sent in sealed enveloped. Yes, someone could go to the trouble to steam them open, but generally they dont bother. When they must bother, its expensive.
How to establish trust is a completely separate problem. Its even separable: (you could have the authentication and tamper-resistance with no encryption at all.).
If you have been paying attention to recent events, mass-eavesdropping has been a big thing in the news lately.
> Because you can't have it both ways: Either the government regulates money for various reasons >(crime, abuse, economic stability) or it doesn't.
This is a false dichotomy.
There are things than can be regulated (Fraud, crime, abusive behavior)
There are also things that can go unregulated (creation of money, spending and receiving of money) In a crypto currenct, these things are impossible to regulate save by global consensus.
The abuses that occurred during the 2008-9 crisis went largely un-punished even despite a clear cause for fraud. The bail-out amount to a huge inflationary minting of dollars, effectively governmental redistribution of wealth. Both of these things can be complained about and both are bad.
There was a time when >90% of all people had to be in agriculture, just to keep everyone fed. Now fewer than 1% are involved in agriculture, we grow way more food than anyone can eat, and somehow we still have jobs for most people.
Think of it from the POV of a business owner. Even if you can fire 80% of your workforce, you cannot simply rest on your laurels and pocket the savings: other businesses are out there finding new ways to outcompete you or make your industry obsolete, and you end up hiring people that can help you maintain your edge.
It turns out that human time is always valuable, and we find new things for people to do. Its a kind of stasis really: people have to learn new skills and do more creative thinking to remain employable. Brute force and repetitive thinking jobs are always at risk.
Those who are willing to learn and adapt have remained employed.
>then it doesn't really matter how strong your password is
Well, thats not quite true. A password with 128 bits of entropy is still going to be strong even when hashed unsalted.
Leaked hash material is really only helpful for finding poor passwords via one of the brute force methods. Lack of salts, or poor salting, is only helpful for rainbow table or rainbow dictionary type attacks.
Choosing a good password will still help you. The only problem is websites that do one of the various bad behaviors: * forcing an capital or digit reduces entropy * limititng the max length reduces entropy.
I'm also a fan of unicode and i18n, however it doesnt add quite as much to security as it may seem.
the whole unicode codespace is only 22.1 bits, meaning that a unicode character is only adding about ~3 ascii characters worth of entropy to the passphrase. It might be easier to memorize a larger number of bits. But if you know the native language of the person who owns the password, you can eliminate the vast majority of the unicode code space from the search space, most likely resulting in only 1 or 2 bytes of entropy per character. (more for languages with a larger number of characters) However, a dictionary search will bring the entropy back down to the same or less than ascii, unless the user uses random non-dictionary, or complex phrases.
There are additionally difficulties: Some languages are not very easy to input without being able to see what you are typing. A strong security system will prevent shoulder-surfing by showing circles, or even better nothing at all, as you type Trying to HenKan Japanese or Chinese without being able see what is being written can be challenging.
In addition, using a device or computer without a given input method would make it virtually impossible to login. Not every machine is setup with your idealized input method, or trained to your writing style.
In short: the downsides seems to dominate, and there is no significant security advantage. I use unicode passwords myself where they work, just because I like them. (especially for throw-away accounts) I do think that software should accept passphrases in utf-8, just for completeness sake. But I don't really think that they improve anything...
>The Japanese writing system is one of those monolithic, looming monstrosities >of inefficiency and folly that make you question how it could ever have evolved,
You are espousing a very common opinion, typically held by those who dont know how to read chinese or japanese.
>No linguistic theory can explain why they don't use an existing, >nearly perfect syllabary they already have, and everyone already knows
You try reading an all kana document and you'll find out why, once your eyes stop bleeding.
It'll become real obvious to you if you bother to learn the language.
They are paying the "going rate" for "Intellectual property": zero. The concept of "intellectual property" is somewhat self delusional. "Information Services" would be a more accurate description.
We cannot blame China for not paying for work that has already been performed.
In a service model, you should collect money, or at least sign a contract to get paid, before you do the work, not after.
The problem with the "Intellectual Property Industry" is that their business model is the same as those aggressive window washers who try to force people waiting at red lights to pay for their dubious "service". at some point, people get fed up and tell you to buzz off.
>The solution is simple. Binaries are an accidental byproduct of the >current technology so don't build the law around them. Solve the real problem.
Source vs Binary is neither temporary nor accidental: it is increasingly becoming a reality for all forms of copyrightable data. This is hardly limited to software.
Music exits in a polished final form. For proper re-use, the original source midi's, separated, tracks, sheet music, and other creation artifacts are much more valuable that the final.mp3.
For books, the original TeX or Word Processor files are much more valuable that a finalized, obfuscated, and DRM'd PDF file.
For movies, the original takes would allow you to make your own "director's cut".
If copyright law required all forms of copyrightable content to be released in the "preferred form of the work for making modifications to it" in order to gain protection, then society would benefit. Because when things revert to the public domain under the current law, they may still be effectively lost, or of diminished value.
OK, you missed the entire point of the maxim "Security != Obscurity".
It is a truism. The point is this: any secrets will eventually be leaked, whether you know it or not. Things that are easy to change, such as keys and passwords, are relatively low risk. Things that are very difficult to change, such as algorithms, are very high risk.
If you count on the fact that your crypto algorithm or operating system is secure because its obscure, then when its leaked you will be facing a catastrophic disaster. Instead of losing the data on one communication or one server, you face a organization wide vulerability, and compromise of past communications.
The extra security gained from keeping the algorithms secret pales in comparison to the disaster of having them be weak. Getting as many eyes on this type of code as possible is the best way to mitigate risk.
After that, you still keep as much secret as possible.
However, there's not enough of a bootlegging problem to lure young ATF or state revenue agents to spend time learning how to investigate them, Jackson said.
as I just explained: it would not be easier with base32, it would be harder. The length would be almost the same, well beyond whats convenient for people to memorize, and it would be impossible to understand the subnetting boundaries.
The people who designed ipv6 were pretty smart, give them some credit. They knew what they were doing.
But TCP does error checking per packet, not for the whole file at once. (so once per 1460bytes or so)
its unlikely that TCP is the culprit here, but with a file that big, there are many many places where things could go wrong, and a single bit error is all it takes to mess things up in a compressed file.
I would bet on the HTTP client/server software being involved.
a movie theatre has a finite amount of space, so that doesnt work as an analogy either.
you are crowding the theatre, and taking up a finite resource.
downloading a copy of the movie is more like waiting until it ends and asking one of the people who watched it to tell you about it, and that person willingly agrees to tell you on their own time.
If it really is simply a access-control system, such as unix permissions, it has nothing to do with DRM and the article and writup are bald-faced trolling.
If it really is a form of DRM/Parental controls, then couching it as good because some cultural has a right to it is nothing more than an insidious attempt to promote "DRM" as a good thing.
You look at an example of why someone wants an access control system like this and you still have to ask?
The grandparent is correct and you are missing the point.
One of these two must be true: a) they want to honor their cultural taboos, and they don't need a system to enforce it upon them or b) they want to break their cultural taboos, and DRM is powerless to enforce it upon them.
Releasing an SDK means you have to support it. Putting together an SDK you can support, and that is easy for developers to use, takes time. It's not just documentation, which in of itself is a large task if you want it done right--it's API design, build toolchain design, getting the supporting websites together and ready, training your developer support people in the new stuff, etc. It's huge! But Apple is doing it.
Absolute nonsense.
You have to have an SDK to release any software for anything period.
And making it available is as simple as releasing it, or even just releasing the headers and describing the compiler setup.
The only reason there is no SDK available is because they dont really want one to be available.
Slashdot Mirror
>People think that adding encryption to something makes it more secure. No, it does not. Encryption is worthless without
> secure key exchange,
This is false; encrypting everything by default significantly increases the barrier to casual eavesdropping.
Letters are usually sent in sealed enveloped. Yes, someone could go to the trouble to steam them open, but
generally they dont bother. When they must bother, its expensive.
How to establish trust is a completely separate problem. Its even separable: (you could have the authentication
and tamper-resistance with no encryption at all.).
If you have been paying attention to recent events, mass-eavesdropping has been a big thing in the news lately.
>MITM detection needs to be implemented within the protocol. This is tricky, but possibl
um, no, thats not true at all...
> Because you can't have it both ways: Either the government regulates money for various reasons
>(crime, abuse, economic stability) or it doesn't.
This is a false dichotomy.
There are things than can be regulated (Fraud, crime, abusive behavior)
There are also things that can go unregulated (creation of money, spending and receiving of money) In a crypto currenct, these things are impossible to regulate save by global consensus.
The abuses that occurred during the 2008-9 crisis went largely un-punished even despite a clear cause for fraud. The bail-out amount to a huge inflationary minting of dollars, effectively governmental redistribution of wealth. Both of these things can be complained about and both are bad.
There was a time when >90% of all people had to be in agriculture, just to keep everyone fed. Now fewer than 1% are involved in agriculture, we grow way more food than anyone can eat, and somehow we still have jobs for most people.
Think of it from the POV of a business owner. Even if you can fire 80% of your workforce, you cannot simply rest on your laurels and pocket the savings: other businesses are out there finding new ways to outcompete you or make your industry obsolete, and you end up hiring people that can help you maintain your edge.
It turns out that human time is always valuable, and we find new things for people to do. Its a kind of stasis really: people have to learn new skills and do more creative thinking to remain employable. Brute force and repetitive thinking jobs are always at risk.
Those who are willing to learn and adapt have remained employed.
So giving a negative review of a piece of content is theft ?
it reduces the value of the original, doesnt it ?
>then it doesn't really matter how strong your password is
Well, thats not quite true. A password with 128 bits of entropy is still going to be strong even when hashed unsalted.
Leaked hash material is really only helpful for finding poor passwords via one of the brute force methods. Lack of salts, or poor salting, is only helpful for rainbow table or rainbow dictionary type attacks.
Choosing a good password will still help you. The only problem is websites that do one of the various bad behaviors:
* forcing an capital or digit reduces entropy
* limititng the max length reduces entropy.
I'm also a fan of unicode and i18n, however it doesnt add quite as much to security as it may seem.
the whole unicode codespace is only 22.1 bits, meaning that a unicode character is only adding about ~3 ascii characters
worth of entropy to the passphrase. It might be easier to memorize a larger number of bits. But if you know the native
language of the person who owns the password, you can eliminate the vast majority of the unicode code space from the
search space, most likely resulting in only 1 or 2 bytes of entropy per character. (more for languages with a larger
number of characters) However, a dictionary search will bring the entropy back down to the same or less than ascii,
unless the user uses random non-dictionary, or complex phrases.
There are additionally difficulties:
Some languages are not very easy to input without being able to see what you are typing.
A strong security system will prevent shoulder-surfing by showing circles, or even better nothing at all, as you type
Trying to HenKan Japanese or Chinese without being able see what is being written can be challenging.
In addition, using a device or computer without a given input method would make it virtually impossible to login. Not
every machine is setup with your idealized input method, or trained to your writing style.
In short: the downsides seems to dominate, and there is no significant security advantage. I use unicode passwords myself where
they work, just because I like them. (especially for throw-away accounts) I do think that software should accept passphrases in
utf-8, just for completeness sake. But I don't really think that they improve anything...
>The Japanese writing system is one of those monolithic, looming monstrosities
>of inefficiency and folly that make you question how it could ever have evolved,
You are espousing a very common opinion, typically held by those who dont know how to read
chinese or japanese.
>No linguistic theory can explain why they don't use an existing,
>nearly perfect syllabary they already have, and everyone already knows
You try reading an all kana document and you'll find out why, once your eyes stop bleeding.
It'll become real obvious to you if you bother to learn the language.
But you won't.
Yay for ignorance?
They are paying the "going rate" for "Intellectual property": zero. The concept of "intellectual property" is somewhat self delusional. "Information Services" would be a more accurate description.
We cannot blame China for not paying for work that has already been performed.
In a service model, you should collect money, or at least sign a contract to get paid, before you do the work, not after.
The problem with the "Intellectual Property Industry" is that their business model is the same as those aggressive window washers who try to force people waiting at red lights to pay for their dubious "service". at some point, people get fed up and tell you to buzz off.
>The solution is simple. Binaries are an accidental byproduct of the
>current technology so don't build the law around them. Solve the real problem.
Source vs Binary is neither temporary nor accidental: it is increasingly becoming a reality for all forms of copyrightable data. This is hardly limited to software.
Music exits in a polished final form. For proper re-use, the original source midi's, separated, tracks, sheet music, and other creation artifacts are much more valuable that the final .mp3.
For books, the original TeX or Word Processor files are much more valuable that a finalized, obfuscated, and DRM'd PDF file.
For movies, the original takes would allow you to make your own "director's cut".
If copyright law required all forms of copyrightable content to be released in the "preferred form of the work for making modifications to it" in order to gain protection, then society would benefit. Because when things revert to the public domain under the current law, they may still be effectively lost, or of diminished value.
OK, you missed the entire point of the maxim "Security != Obscurity".
It is a truism. The point is this: any secrets will eventually be leaked, whether you know it or not. Things that are easy to change, such as keys and passwords, are relatively low risk. Things that are very difficult to change, such as algorithms, are very high risk.
If you count on the fact that your crypto algorithm or operating system is secure because its obscure, then when its leaked you will be facing a catastrophic disaster. Instead of losing the data on one communication or one server, you face a organization wide vulerability, and compromise of past communications.
The extra security gained from keeping the algorithms secret pales in comparison to the disaster of having them be weak.
Getting as many eyes on this type of code as possible is the best way to mitigate risk.
After that, you still keep as much secret as possible.
If you need the helpdesk that often, then yes, you should never customize your machine.
I use dvorak for the same reason you dont: it keeps other people off my terminals.
If its better, which seems likely, thats a fringe benefit.
However, there's not enough of a bootlegging problem to lure young ATF or state revenue agents to spend time learning how to investigate them, Jackson said.
A quote from your article.
Proving his point ?
as I just explained: it would not be easier with base32, it would be harder. The length would be almost the same, well beyond whats convenient for people to memorize, and it would be impossible to understand the subnetting boundaries.
The people who designed ipv6 were pretty smart, give them some credit. They knew what they were doing.
your examples are wrong.
HEX: 4 bits per byte, takes 32 chars to encode IPv6 Address
Base32: 5 bits per byte, takes 26 char to encode an IPv6 address
Base64: 6 bits per byte, takes 22 chars to encode an IPv6 address
You can see the return on investment is pretty small for base32 and base64, since it costs you the transparency of the output.
try again.
>* No standardized pragmas
Jumbo Shrimp?
>* Macros after-thought and not type safe
Preprocessor macros are largely deprecated by C++, except where they make sense.
>* No 24, and 32 bit (unicode) chars
Have you missed the last 8 years of i18n progress ? Putting unicode datatypes into primitive is a failed model.
Wake up and smell the utf-8.
>* Compilers still limited to ASCII source
Ever use gcc ?
>* Inconsistent left-to-right declarations
Whats inconistent about them?
>* No binary constant prefix (even octal has one?!)
Learn hex already
But TCP does error checking per packet, not for the whole file at once. (so once per 1460bytes or so)
its unlikely that TCP is the culprit here, but with a file that big, there are many many places where things could
go wrong, and a single bit error is all it takes to mess things up in a compressed file.
I would bet on the HTTP client/server software being involved.
7bit ascii can show caps and uppercase just fine, no markup needed
a movie theatre has a finite amount of space, so that doesnt work as an analogy either.
you are crowding the theatre, and taking up a finite resource.
downloading a copy of the movie is more like waiting until it ends and asking one of the people who watched it to tell you about it, and that person willingly agrees to tell you on their own time.
The big deal is this:
If it really is simply a access-control system, such as unix permissions, it has nothing to do with DRM and the article and writup are bald-faced trolling.
If it really is a form of DRM/Parental controls, then couching it as good because some cultural has a right to it is nothing more than an insidious attempt to promote "DRM" as a good thing.
either way, something is wrong
Their system cannot do what is required.
The support for emeror's clothing style tech solutions here is unnerving
You look at an example of why someone wants an access control system like this and you still have to ask?
The grandparent is correct and you are missing the point.
One of these two must be true:
a) they want to honor their cultural taboos, and they don't need a system to enforce it upon them
or
b) they want to break their cultural taboos, and DRM is powerless to enforce it upon them.
Either way, DRM is useless.
If you believe that you are a sucker.
(or selling it)
Releasing an SDK means you have to support it. Putting together an SDK you can support, and that is easy for developers to use, takes time. It's not just documentation, which in of itself is a large task if you want it done right--it's API design, build toolchain design, getting the supporting websites together and ready, training your developer support people in the new stuff, etc. It's huge! But Apple is doing it.
Absolute nonsense.
You have to have an SDK to release any software for anything period.
And making it available is as simple as releasing it, or even just releasing the headers and describing the compiler setup.
The only reason there is no SDK available is because they dont really want one to be available.
"Eijuusha" darou :p