At first glance, you think "serves him right" of course, I'm no exception.
But where I live, there are things you can do if someone fraudulently sells you non-working stuff as working.
This is vigilante justice, plain and simple. I don't think the proportionalities match here.
The seller should be forced to refund the money or provide a working laptop and the buyer should face charges for whatever crimes he committed by posting this stuff.
Halo did do something very nice that every FPS game should copy. Give grenades their own controls so you can throw them with your main weapon equipped. Brilliant.
You mean like Team Fortress Classic (Multiplayer Half-Life 1 mod) did years ago?
'Course, what's the point of hiding the encrypted volume, if it's hidden using a mechanism that's widely published and open-source?
But with hidden volumes, the header at the end is - just as the normal header at the beginning - indistinguishable from random data. TrueCrypt tries decrypting the hidden header "blindly". There is no header that says "here be hidden volume".
Telling someone hoe hidden volumes work helps him nothing to _prove_ that you actually used that feature.
Some countries have a principle that says you don't have to incriminate yourself. Everything that's supposed to prove a crime has to be brought up by the prosecuters on their own.
If they can break the safe, tough luck for you.
If they can break the encryption, fine. If they cannot, tough luck for them. Nothing to see here, move along and try to find something else.
The software provides something called Plausible Deniability and it is further enhanced by the so-called hidden volume method.
You should at least understand the terminology of the software you are using. TrueCrypt has a feature called hidden volumes that provide plausible deniability.
Plausible deniability means just that: You can plausibly deny that there is some encrypted data beyond the first level, i.e. the other party cannot prove that there is such data.
Since you can nest hidden volumes, there can always be another hidden volume behind the one you just gave up.
I know you joke, but the 40% are possibly even real. Conroe aka Core 2 is _seriously_ kicking ass. Check overclocking forums where people are pushing non-EE engineering samples beyond 3GHz on air cooling and break world records in most benchmarks, which were previously held by insane nitro-cooled P4 or Opteron setups.
Preview, preview, preview. Anyway, there sould be a final pipe element that reads "< remove all non-alphanumeric characters and truncate the result to 16 chars >"
To conquer this whole password mess of mine (dozens of password for forums/shops/accounts/etc.) I use a scheme I came up with. I'm certainly not the first to do this, but it goes like this:
I remember only one password, let's call it master password. Then I use the following algorithm to derive all passwords I need from it:
USER and DOMAIN are just reminders of where I logged in with which username. ITERATION is a number starting from 1 that I can increase to change a single password. All triplets can be stored because they are almost useless without the master password (apart from disclosing that I frequent forum X as user Y).
The only problem with this approach is that I must never lose or disclose the master password. That's why currently, I only enter it on a non-connected machine which outputs the result over a one-way serial connection to my desktop. This algorithm could also be implemented on a PDA for example to make the approach portable.
The article doesn't appear to mention this, but there is a C99 standard header stdint.h, which defines fixed width types. I haven't seen any OSS project use it, for some reason, but it has all the types you need for portable development; int32_t, uint64_t, constant wrappers like UINT64_C, and, of course, limit constants for all of the fixed-size types. Using these is much better than all those size-based #ifdef'ed typedefs I see people use all over their code.
Umm, try NetBSD maybe? It's the most portable system there is. They don't port it to dozens of archs to be cool. It helps write cleaner code if you have all kinds of mixes of big-endian, little-endian, 32bit, 64bit. Each arch compiles from the same source without many warnings, if any at all.
"These programs have been around for years (CIPE goes back to 1996 and vtun
to 1998) and (apparently) have quite sizeable user communities without
anyone having noticed (or caring, after flaws were pointed out) that they
have security problems. I only heard of CIPE when a friend of mine
mentioned it to me in passing, and came across vtun by coincidence when I
was looking for more info on CIPE. Who knows how many more insecure Linux
crypto-tunnel products there may be floating around out there."
To a non-expert in cryptography, an Open Source security program may just be as obscure as a closed one. So if you rely on an Open Source program, then actually go out and seek reviews. Don't just think "it's Open Source, _someone_ surely must have audited it".
I was wrong. Indeed, Hamachi only serves to bring peers together which then establish a connection among themselves. But how is this better than using OpenVPN with static hostnames? DynDNS should be common enough.
Perhaps you should complain about GCC having separated the code generator from the parser?
Maybe I should, if one generator supported MMX while another supports SSE and yet another SSE2 and so on, but no single one supported them all.
Or maybe you want to grumble that the whole concept of having seperate drivers from the kernel is equally flawed and that they should always be in one monolithic kernel, hmmm?
Again, if there was one disk driver that only supported reading and one that only supported writing, I'd probably complain. But as it is, both providers of the GCC parser and most kernels also provide a _working_ code generator and drivers that are fully functional and don't lack features that are considered vital in their area.
What do multiple storage engines actually buy you, apart from leaving out features to get some speed? I still think modularisation in this case is somewhat useless.
For where you see problems, I try to see a possible solution.
It's a solution necessary because the prerequisite is flawed to begin with IMHO. You say that the storage engine providers have to implement feature X. Where did the idea come from that a separated storage and parser is actually a good idea?
Are you willing to sponsor such a feature?
To be blunt, why should I help the mediocre player if I could just go with a superior one that has an even more free license? Yes, I mean PostgreSQL.
No speed advantage could make up for the feeling of kludginess that surrounds MySQL - an advantage that only applies if you ignore crucial features.
So what else is there except pretended speed? What does MySQL actually do better than other free databases? Granted, it's available on almost any web hoster. But that's akin to saying "Eat shit. Millions of flies can't be wrong!"
Slashdot Mirror
At first glance, you think "serves him right" of course, I'm no exception.
But where I live, there are things you can do if someone fraudulently sells you non-working stuff as working.
This is vigilante justice, plain and simple. I don't think the proportionalities match here.
The seller should be forced to refund the money or provide a working laptop and the buyer should face charges for whatever crimes he committed by posting this stuff.
Since TFC was before Halo, that's sufficient to claim "prior art". I never said TFC was the first to have this.
Halo did do something very nice that every FPS game should copy. Give grenades their own controls so you can throw them with your main weapon equipped. Brilliant.
You mean like Team Fortress Classic (Multiplayer Half-Life 1 mod) did years ago?
What you are saying is essentially that you happily bend over as long as the other one pays for the lube?
It amazes me that people first and foremost think about costs and how this thing could technically work/not work.
Who cares about rights..
'Course, what's the point of hiding the encrypted volume, if it's hidden using a mechanism that's widely published and open-source?
But with hidden volumes, the header at the end is - just as the normal header at the beginning - indistinguishable from random data. TrueCrypt tries decrypting the hidden header "blindly". There is no header that says "here be hidden volume".
Telling someone hoe hidden volumes work helps him nothing to _prove_ that you actually used that feature.
Some countries have a principle that says you don't have to incriminate yourself. Everything that's supposed to prove a crime has to be brought up by the prosecuters on their own.
If they can break the safe, tough luck for you.
If they can break the encryption, fine. If they cannot, tough luck for them. Nothing to see here, move along and try to find something else.
The software provides something called Plausible Deniability and it is further enhanced by the so-called hidden volume method.
You should at least understand the terminology of the software you are using. TrueCrypt has a feature called hidden volumes that provide plausible deniability.
Plausible deniability means just that: You can plausibly deny that there is some encrypted data beyond the first level, i.e. the other party cannot prove that there is such data.
Since you can nest hidden volumes, there can always be another hidden volume behind the one you just gave up.
Enter TrueCrypt and hidden volumes made for exactly that reason: http://www.truecrypt.org/hiddenvolume.php
"Four boxes to be used in defense of liberty: soap, ballot, jury, ammo in this order!"
At which point are you guys now? I'd say it's already past the third, no?
(And don't give me any lip about Goodwin's Law. This is serious.)
It's scary that not invoking Godwin's Law actually seems reasonable whenever there's a discussion about the latest US behaviour.
I know you joke, but the 40% are possibly even real. Conroe aka Core 2 is _seriously_ kicking ass. Check overclocking forums where people are pushing non-EE engineering samples beyond 3GHz on air cooling and break world records in most benchmarks, which were previously held by insane nitro-cooled P4 or Opteron setups.
Conroe will be fun.
I'm still trying to find the catch with the BSD I'm using. Can you help me there?
Correct. It's a security measure that doesn't prevent all possible problems.
Except it's not. It's seen as that by amateurs, correct.
If you can also tell me how you would do that?
The password is made with Diceware and is 7 words long and is never entered on a connected machine.
I think IT departments concerned about security should make it a stated policy that they will try to find out your password
:)
I'm sure $PHB will happily spew some cash for the extra password-cracking cluster in the closet.
$ echo -n "$USER:$DOMAIN:$ITERATION:$MASTERPASS" | openssl ripemd160 -binary | openssl base64 |
Preview, preview, preview. Anyway, there sould be a final pipe element that reads "< remove all non-alphanumeric characters and truncate the result to 16 chars >"
To conquer this whole password mess of mine (dozens of password for forums/shops/accounts/etc.) I use a scheme I came up with. I'm certainly not the first to do this, but it goes like this:
I remember only one password, let's call it master password. Then I use the following algorithm to derive all passwords I need from it:
$ echo -n "$USER:$DOMAIN:$ITERATION:$MASTERPASS" | openssl ripemd160 -binary | openssl base64 |
USER and DOMAIN are just reminders of where I logged in with which username. ITERATION is a number starting from 1 that I can increase to change a single password. All triplets can be stored because they are almost useless without the master password (apart from disclosing that I frequent forum X as user Y).
The only problem with this approach is that I must never lose or disclose the master password. That's why currently, I only enter it on a non-connected machine which outputs the result over a one-way serial connection to my desktop. This algorithm could also be implemented on a PDA for example to make the approach portable.
Windows: Where do you want to go today?
Linux: Where do you want to be tomorrow?
BSD: Are you guys coming or what?!
The article doesn't appear to mention this, but there is a C99 standard header stdint.h, which defines fixed width types. I haven't seen any OSS project use it, for some reason, but it has all the types you need for portable development; int32_t, uint64_t, constant wrappers like UINT64_C, and, of course, limit constants for all of the fixed-size types. Using these is much better than all those size-based #ifdef'ed typedefs I see people use all over their code.
Umm, try NetBSD maybe? It's the most portable system there is. They don't port it to dozens of archs to be cool. It helps write cleaner code if you have all kinds of mixes of big-endian, little-endian, 32bit, 64bit. Each arch compiles from the same source without many warnings, if any at all.
It's true that, with Closed Source, you can never be sure. That doesn't mean, however, that Open Source is guaranteed to be secure.
v pn.txt:
There are not only crypto algorithms but also many details surrounding an implementation that are equally important.
My famous example being http://www.cs.auckland.ac.nz/~pgut001/pubs/linux_
"These programs have been around for years (CIPE goes back to 1996 and vtun
to 1998) and (apparently) have quite sizeable user communities without
anyone having noticed (or caring, after flaws were pointed out) that they
have security problems. I only heard of CIPE when a friend of mine
mentioned it to me in passing, and came across vtun by coincidence when I
was looking for more info on CIPE. Who knows how many more insecure Linux
crypto-tunnel products there may be floating around out there."
To a non-expert in cryptography, an Open Source security program may just be as obscure as a closed one. So if you rely on an Open Source program, then actually go out and seek reviews. Don't just think "it's Open Source, _someone_ surely must have audited it".
I was wrong. Indeed, Hamachi only serves to bring peers together which then establish a connection among themselves. But how is this better than using OpenVPN with static hostnames? DynDNS should be common enough.
Perhaps you should complain about GCC having separated the code generator from the parser?
Maybe I should, if one generator supported MMX while another supports SSE and yet another SSE2 and so on, but no single one supported them all.
Or maybe you want to grumble that the whole concept of having seperate drivers from the kernel is equally flawed and that they should always be in one monolithic kernel, hmmm?
Again, if there was one disk driver that only supported reading and one that only supported writing, I'd probably complain. But as it is, both providers of the GCC parser and most kernels also provide a _working_ code generator and drivers that are fully functional and don't lack features that are considered vital in their area.
What do multiple storage engines actually buy you, apart from leaving out features to get some speed? I still think modularisation in this case is somewhat useless.
For where you see problems, I try to see a possible solution.
It's a solution necessary because the prerequisite is flawed to begin with IMHO. You say that the storage engine providers have to implement feature X. Where did the idea come from that a separated storage and parser is actually a good idea?
Are you willing to sponsor such a feature?
To be blunt, why should I help the mediocre player if I could just go with a superior one that has an even more free license? Yes, I mean PostgreSQL.
No speed advantage could make up for the feeling of kludginess that surrounds MySQL - an advantage that only applies if you ignore crucial features.
So what else is there except pretended speed? What does MySQL actually do better than other free databases? Granted, it's available on almost any web hoster. But that's akin to saying "Eat shit. Millions of flies can't be wrong!"
And so original.
I can't believe what I just read. Someone shoot me please.
It's nice to experience first-hand the mindset that MySQL is developed with. Did I say nice? I meant scary.