This.... from a bank.... I'm.... WTF?!
-
@Mole said:
There's one thing that TrueCrypt does that I don't believe KeyPass does (but correct me if I'm wrong) - hidden volumes. I can enter one password and get a list of passwords or enter a different password and get a completely different list of passwords. As of yet, I don't know anyone who has managed to prove that there is more than a single password to a TrueCrypt volume.
That's a neat feature, and I hate to be all "If you have nothing to hide, you have nothing to fear", but it seems the only use for that feature in the U.S. or western Europe is criminal enterprise. I mean, what real use do you have for that? I'm just curious.
-
@morbiuswilters said:
Two words: plausible deniability.
Which doesn't mean shit if they think you're hiding something.Two pairs of two words: socket wrench, rubber hose.
-
@morbiuswilters said:
@Mole said:
There's one thing that TrueCrypt does that I don't believe KeyPass does (but correct me if I'm wrong) - hidden volumes. I can enter one password and get a list of passwords or enter a different password and get a completely different list of passwords. As of yet, I don't know anyone who has managed to prove that there is more than a single password to a TrueCrypt volume.
That's a neat feature, and I hate to be all "If you have nothing to hide, you have nothing to fear", but it seems the only use for that feature in the U.S. or western Europe is criminal enterprise. I mean, what real use do you have for that? I'm just curious.
I carry that TrueCrypt volume around with me on my laptop. If I'm forced to hand over my encryption key I can do so. The fact that it worked makes the other party believe its correct. They would have no idea that a different password would open a completely different file system volume. The space taken up by the other volume is displayed as free space on the other, and yes, you could even overwrite one partition from the other, which makes it even more plausible.
It's not just for hiding stuff from government agents either - I do know someone who had their laptop stolen, and they were forced to hand over their power on password. Typically the second part is unlikely from a thief, but it's possible. I travel and I'm not taking the risk of allowing someone else to see all my logins and passwords for various systems.
-
@dkf said:
@morbiuswilters said:
That's only one pair...Two words: plausible deniability.
Which doesn't mean shit if they think you're hiding something.Two pairs of two words: socket wrench, rubber hose.
-
@Mole said:
I carry that TrueCrypt volume around with me on my laptop. If I'm forced to hand over my encryption key I can do so. The fact that it worked makes the other party believe its correct. They would have no idea that a different password would open a completely different file system volume.
...except that this is a well known feature of TrueCrypt, so I guess it sucks to be you if you genuinely don't have what they're looking for, because they'd just have to keep waterboarding you to extract the secondary keys you don't have for volumes you can't prove don't exist.
-
@morbiuswilters said:
But, anyway, I was mostly being facetious.
(faints)
-
@Ben L. said:
I want to protect a file containing the password to another encrypted file containing a 1×1px transparent png in about 100 more layers of encryption, just so I can "leak" it somewhere and watch "hackers" on the internet go crazy trying to brute force it open (by the way, the encryption keys will all be generated with various PRNGs using the same seed, something like 0xDEADBEEF or 0xAAAAAAAB) only to find that they wasted their parents electricity on the most expensive way to generate a useless file.
Or you could just collect a gig and a half of CSPRNG output, and leave it lying around with a name like insurance.aes256.
-
@alegr said:
@drurowin said:
I don't have Facebook. Does that mean I couldn't use those websites?Now if it was MANDATED that sites use Facebook Connect for logins, I'd be all for it.
Some websites require Facebook account to verify registration. Even if you don't login via facebook.
-
@Ben L. said:
only to find that they wasted their parents electricity on the most expensive way to generate a useless file.
Somebody already did this; I think they're calling it "bitcoin".
-
@dkf said:
@morbiuswilters said:
Two words: plausible deniability.
Which doesn't mean shit if they think you're hiding something.Two pairs of two words: socket wrench, rubber hose.
When the Soviets were in a hurry, they would use a soldering iron.
-
@aristurtle said:
@Ben L. said:
only to find that they wasted their parents electricity on the most expensive way to generate a useless file.
Somebody already did this; I think they're calling it "bitcoin".
-
@flabdablet said:
@Mole said:
I carry that TrueCrypt volume around with me on my laptop. If I'm forced to hand over my encryption key I can do so. The fact that it worked makes the other party believe its correct. They would have no idea that a different password would open a completely different file system volume.
...except that this is a well known feature of TrueCrypt, so I guess it sucks to be you if you genuinely don't have what they're looking for, because they'd just have to keep waterboarding you to extract the secondary keys you don't have for volumes you can't prove don't exist.
But of course first they have to prove that your porn collection is actually a TrueCrypt volume.
-
@Mole said:
@flabdablet said:
@Mole said:
I carry that TrueCrypt volume around with me on my laptop. If I'm forced to hand over my encryption key I can do so. The fact that it worked makes the other party believe its correct. They would have no idea that a different password would open a completely different file system volume.
...except that this is a well known feature of TrueCrypt, so I guess it sucks to be you if you genuinely don't have what they're looking for, because they'd just have to keep waterboarding you to extract the secondary keys you don't have for volumes you can't prove don't exist.
But of course first they have to prove that your porn collection is actually a TrueCrypt volume.
Since when do they have to prove anything?
-
@Buttembly Coder said:
@Mole said:
@flabdablet said:
@Mole said:
I carry that TrueCrypt volume around with me on my laptop. If I'm forced to hand over my encryption key I can do so. The fact that it worked makes the other party believe its correct. They would have no idea that a different password would open a completely different file system volume.
...except that this is a well known feature of TrueCrypt, so I guess it sucks to be you if you genuinely don't have what they're looking for, because they'd just have to keep waterboarding you to extract the secondary keys you don't have for volumes you can't prove don't exist.
But of course first they have to prove that your porn collection is actually a TrueCrypt volume.
Since when do they have to prove anything?
OK... So make sure your laptop has an encrypted file system on it, or someone somewhere might find a file on it, assume it's a hidden encrypted file system and force you to hand over a set passwords which don't exist.
Meanwhile, someone with something to hide could have two or more encrypted file systems on their laptop.
Are you just going to keep asking, just in case they may have another partition?
-
@Mole said:
@Buttembly Coder said:
@Mole said:
@flabdablet said:
@Mole said:
I carry that TrueCrypt volume around with me on my laptop. If I'm forced to hand over my encryption key I can do so. The fact that it worked makes the other party believe its correct. They would have no idea that a different password would open a completely different file system volume.
...except that this is a well known feature of TrueCrypt, so I guess it sucks to be you if you genuinely don't have what they're looking for, because they'd just have to keep waterboarding you to extract the secondary keys you don't have for volumes you can't prove don't exist.
But of course first they have to prove that your porn collection is actually a TrueCrypt volume.
Since when do they have to prove anything?
OK... So make sure your laptop has an encrypted file system on it, or someone somewhere might find a file on it, assume it's a hidden encrypted file system and force you to hand over a set passwords which don't exist.
Meanwhile, someone with something to hide could have two or more encrypted file systems on their laptop.
Are you just going to keep asking, just in case they may have another partition?
The people waterboarding you are going to keep asking, because they want to keep waterboarding you.
-
@Buttembly Coder said:
@Mole said:
All in favor of continuing to waterboard Mole? Aye! Opposed? . . . . . . . . The ayes have it. Carry on.OK... So make sure your laptop has an encrypted file system on it, or someone somewhere might find a file on it, assume it's a hidden encrypted file system and force you to hand over a set passwords which don't exist.
Meanwhile, someone with something to hide could have two or more encrypted file systems on their laptop.
Are you just going to keep asking, just in case they may have another partition?
The people waterboarding you are going to keep asking, because they want to keep waterboarding you.
-
@dkf said:
Which doesn't mean shit if they think you're hiding something.
Which is why I keep a list of people to rat on. Torture me all you like, you won't get any information out of me, except the names, addresses and physical descriptions of every person I know who's committed so much as misdemeanor, along with an encyclopedia recounting of their sins.
@dkf said:
Two pairs of two words: socket wrench, rubber hose.
How do you torture someone with a socket wrench? My normally-fertile mind is drawing a blank. I mean, you could hit them with it, but you could do that with about anything blunt and hard.
-
@Mole said:
I carry that TrueCrypt volume around with me on my laptop. If I'm forced to hand over my encryption key I can do so. The fact that it worked makes the other party believe its correct. They would have no idea that a different password would open a completely different file system volume. The space taken up by the other volume is displayed as free space on the other, and yes, you could even overwrite one partition from the other, which makes it even more plausible.
I get how it works, was just curious why you needed it.
@Mole said:
It's not just for hiding stuff from government agents either - I do know someone who had their laptop stolen, and they were forced to hand over their power on password. Typically the second part is unlikely from a thief, but it's possible. I travel and I'm not taking the risk of allowing someone else to see all my logins and passwords for various systems.
I thought about that, but it seemed so remote. I mean, a snatch-and-grab criminal mostly just wants the laptop. I could see them wanting passwords and such, but you can't boot from TrueCrypt, right? So they'd have to be digging around on your system and find a TrueCrypt volume and then ask you to give the password, all the while keeping you hostage. Anywho, if it works for you, good luck with that.
-
@flabdablet said:
@Mole said:
I carry that TrueCrypt volume around with me on my laptop. If I'm forced to hand over my encryption key I can do so. The fact that it worked makes the other party believe its correct. They would have no idea that a different password would open a completely different file system volume.
...except that this is a well known feature of TrueCrypt, so I guess it sucks to be you if you genuinely don't have what they're looking for, because they'd just have to keep waterboarding you to extract the secondary keys you don't have for volumes you can't prove don't exist.
In my day, muggers just stole your laptop and tried to fence it for drug money, I didn't know they'd started waterboarding people. I guess the economy's been hard on everyone..
-
@Buttembly Coder said:
The people waterboarding you are going to keep asking, because they want to keep waterboarding you.
I wouldn't say that I want to keep waterboarding him. It's just that, how do I know for sure that his TrueCrypt volume only has three keys?
-
@morbiuswilters said:
How do you torture someone with a socket wrench?
They have to have hexagonal pinkies.
Protip: research your victim in advance so you're prepared with either a US Standard or Metric set.
-
-
@blakeyrat said:
most pinkies are a metric 14 so when you're done torturing you can change your oil
Most useful.
-
@morbiuswilters said:
@locallunatic said:
Yeah but on long inputs you can feed the first set of bytes in, then the second, and so on XORing the outputs (minus the identifiers) and feeding that in to get a final. Of course this doesn't actually deal with the limited input space but it is a way of faking it larger.
Off-the-cuff, that sounds like it would substantially weaken the algo. Do you have a cite on how this works? It's probably just me being paranoid, but I'd like to see a crypto professional explain it.
Not a crypto professional, but I don't see any reason why the algo would be weakened. Re-hashing the ouput is common in key stretching, and xoring a hash with anything but itself is not going reduce entropy. Actually, xoring two different hashes from the same algorithm only reduces output bit bias.
-
@Faxmachinen said:
@morbiuswilters said:
Already had one answer. Another is that since two inputs (A and B) are XOR'd together (to produce C), then it's entirely possible for two other, different, inputs (D and E) to produce the same result (C) - i.e a collision; not an ideal situation for a hash function.@locallunatic said:
Yeah but on long inputs you can feed the first set of bytes in, then the second, and so on XORing the outputs (minus the identifiers) and feeding that in to get a final. Of course this doesn't actually deal with the limited input space but it is a way of faking it larger.
Off-the-cuff, that sounds like it would substantially weaken the algo. Do you have a cite on how this works? It's probably just me being paranoid, but I'd like to see a crypto professional explain it.
Not a crypto professional, but I don't see any reason why the algo would be weakened. Re-hashing the ouput is common in key stretching, and xoring a hash with anything but itself is not going reduce entropy. Actually, xoring two different hashes from the same algorithm only reduces output bit bias.
-
@Faxmachinen said:
@morbiuswilters said:
@locallunatic said:
Yeah but on long inputs you can feed the first set of bytes in, then the second, and so on XORing the outputs (minus the identifiers) and feeding that in to get a final. Of course this doesn't actually deal with the limited input space but it is a way of faking it larger.
Off-the-cuff, that sounds like it would substantially weaken the algo. Do you have a cite on how this works? It's probably just me being paranoid, but I'd like to see a crypto professional explain it.
Not a crypto professional, but I don't see any reason why the algo would be weakened. Re-hashing the ouput is common in key stretching, and xoring a hash with anything but itself is not going reduce entropy. Actually, xoring two different hashes from the same algorithm only reduces output bit bias.You're not rehashing the output, though. I already mentioned this, but you're taking the output of a symmetric cipher and xoring it with the next 55 bytes of the password and then using that as a key. Each iteration would have to use the same salt. Also, the bcrypt output is only going to be 184 bits, so it will only xor the first half of the 55 byte input. Anyway, it seems much safer to just pre-hash the password using straight SHA-256/-512 if you want to let users use longer passwords. Or just limit them to 55 bytes, which is the Morbs Way.
-
@morbiuswilters said:
You're not rehashing the output, though. I already mentioned this, but you're taking the output of a symmetric cipher and xoring it with the next 55 bytes of the password and then using that as a key. Each iteration would have to use the same salt. Also, the bcrypt output is only going to be 184 bits, so it will only xor the first half of the 55 byte input. Anyway, it seems much safer to just pre-hash the password using straight SHA-256/-512 if you want to let users use longer passwords. Or just limit them to 55 bytes, which is the Morbs Way.
Isn't limiting the passwords to 55 bytes showing everyone that you could be using bcrypt for hashing your passwords? Kind of like the 72 byte limit of crypt? (I think it's 72 bytes...)
-
@Mole said:
@morbiuswilters said:
You're not rehashing the output, though. I already mentioned this, but you're taking the output of a symmetric cipher and xoring it with the next 55 bytes of the password and then using that as a key. Each iteration would have to use the same salt. Also, the bcrypt output is only going to be 184 bits, so it will only xor the first half of the 55 byte input. Anyway, it seems much safer to just pre-hash the password using straight SHA-256/-512 if you want to let users use longer passwords. Or just limit them to 55 bytes, which is the Morbs Way.
Isn't limiting the passwords to 55 bytes showing everyone that you could be using bcrypt for hashing your passwords? Kind of like the 72 byte limit of crypt? (I think it's 72 bytes...)
shrug Not something I'm really worried about. I mean, what is someone going to do with that info? If it does worry you, just limit it to something non-specific, like 48 characters.
-
@morbiuswilters said:
@Mole said:
@morbiuswilters said:
You're not rehashing the output, though. I already mentioned this, but you're taking the output of a symmetric cipher and xoring it with the next 55 bytes of the password and then using that as a key. Each iteration would have to use the same salt. Also, the bcrypt output is only going to be 184 bits, so it will only xor the first half of the 55 byte input. Anyway, it seems much safer to just pre-hash the password using straight SHA-256/-512 if you want to let users use longer passwords. Or just limit them to 55 bytes, which is the Morbs Way.
Isn't limiting the passwords to 55 bytes showing everyone that you could be using bcrypt for hashing your passwords? Kind of like the 72 byte limit of crypt? (I think it's 72 bytes...)
shrug Not something I'm really worried about. I mean, what is someone going to do with that info? If it does worry you, just limit it to something non-specific, like 48 characters.
Or 10?
-
@Mole said:
@morbiuswilters said:
@Mole said:
@morbiuswilters said:
You're not rehashing the output, though. I already mentioned this, but you're taking the output of a symmetric cipher and xoring it with the next 55 bytes of the password and then using that as a key. Each iteration would have to use the same salt. Also, the bcrypt output is only going to be 184 bits, so it will only xor the first half of the 55 byte input. Anyway, it seems much safer to just pre-hash the password using straight SHA-256/-512 if you want to let users use longer passwords. Or just limit them to 55 bytes, which is the Morbs Way.
Isn't limiting the passwords to 55 bytes showing everyone that you could be using bcrypt for hashing your passwords? Kind of like the 72 byte limit of crypt? (I think it's 72 bytes...)
shrug Not something I'm really worried about. I mean, what is someone going to do with that info? If it does worry you, just limit it to something non-specific, like 48 characters.
Or 10?
That seems a little short..
-
-
@mott555 said:
@morbiuswilters said:
That seems a little short..
That's what she said.Yeah, tell your wife I'm sorry. Normally we do a 6 hour session, but this week I was double-booked.
-
@PJH said:
Already had one answer. Another is that since two inputs (A and B) are XOR'd together (to produce C), then it's entirely possible for two other, different, inputs (D and E) to produce the same result (C) - i.e a collision; not an ideal situation for a hash function.
Already had one answer that didn't make any fucking sense, you mean. And potential collisions when you cram a large number of bytes into a smaller number of bytes? No shit, Sherlock. Yet file checksums are still useful somehow?
-
@Faxmachinen said:
Already had one answer that didn't make any fucking sense, you mean. And potential collisions when you cram a large number of bytes into a smaller number of bytes? No shit, Sherlock. Yet file checksums are still useful somehow?
XOR itself isn't a problem (unlike an OR or AND) but it needs additional operations too (e.g., shifts) to spread the bits around. Ideally, every bit in the resulting hash has some contribution (however small) from the input data. A checksum would actually be a fairly reasonable hash function; they've got a lot in common. (There are also perfect hashes, but they're very specialised and you don't want to waste time on them unless you've got a very fancy use-case.)Collisions are to be expected with hashing. It's bad when they can be forced (very bad in the case of cryptographic hashes!) but otherwise it's not suspicious, just a fact of life due to greatly reducing the number of significant bits.
-
@dkf said:
Collisions are to be expected with hashing.
Not if the number of possible hash results is as astronomical as 2128; there simply aren't enough things you could hash and/or enough time to have hashed them. Which is why GUIDs work about as well as RAM does.
-
@flabdablet said:
@dkf said:
Collisions are still possible (in fact, are guaranteed by the pigeonhole principle), it's just the odds are better that your collision searching program will run until the heat death of the universe before actually finding one.Collisions are to be expected with hashing.
Not if the number of possible hash results is as astronomical as 2128; there simply aren't enough things you could hash and/or enough time to have hashed them. Which is why GUIDs work about as well as RAM does.
-
@joe.edwards said:
@flabdablet said:
Truly pedantic dickweeds would point out that the probability of your collision searching program running until the heat death of the universe is negligible. The program, hardware running it, and reason for seeking a collision will have all become obsolete eons before then.@dkf said:
Collisions are still possible (in fact, are guaranteed by the pigeonhole principle), it's just the odds are better that your collision searching program will run until the heat death of the universe before actually finding one.Collisions are to be expected with hashing.
Not if the number of possible hash results is as astronomical as 2128; there simply aren't enough things you could hash and/or enough time to have hashed them. Which is why GUIDs work about as well as RAM does.Filed under: This distinction is crucially important to dickweeds.
-
@joe.edwards said:
...the odds are better that your collision searching program will run until the heat death of the universe before actually finding one.
Like The Last Question, but gay!
-
@HardwareGeek said:
@joe.edwards said:
@flabdablet said:
Truly pedantic dickweeds would point out that the probability of your collision searching program running until the heat death of the universe is negligible. The program, hardware running it, and reason for seeking a collision will have all become obsolete eons before then.@dkf said:
Collisions are still possible (in fact, are guaranteed by the pigeonhole principle), it's just the odds are better that your collision searching program will run until the heat death of the universe before actually finding one.Collisions are to be expected with hashing.
Not if the number of possible hash results is as astronomical as 2128; there simply aren't enough things you could hash and/or enough time to have hashed them. Which is why GUIDs work about as well as RAM does.Filed under: This distinction is crucially important to dickweeds.
In point of fact, I considered this, but I still considered it more likely to happen than to actually find a collision in that space. The collapse of our civilization, extinction of the human race, even destruction of the planet earth don't necessarily have to halt our program. Perhaps our last act as a species was to launch an autonomous AI vessel to continue the execution of this program.
-
@joe.edwards said:
it's just the odds are better that your collision searching program will run until the heat death of the universe before actually finding one.
If the expected time to find a collision exceeds the expected lifetime of the human species and all its technological works, I think it's safe to say that collisions in a sufficiently large hash will never, in fact, occur. Yeah yeah pigeonhole principle, but when the number of pigeonholes available exceeds the number of items that will ever need pigeonholing to the extent that a 128-bit or wider hash gives you, ignoring the number of theoretically possible hash inputs becomes completely sound from an engineering point of view.
In other words, given a sufficiently good hash function with a sufficiently wide output, collisions are absolutely not "to be expected".
Hash collisions are something you worry about if your hash value is going to be used as an array index, not if it's a nice wide crypto-grade fingerprint.
-
@flabdablet said:
Hash collisions are something you worry about if your hash value is going to be used as an array index, not if it's a nice wide crypto-grade fingerprint.
The possibility of collisions remains even with cryptographic hashes. It's just that they take great care to make sure that it's very unlikely that you'll find two meaningful plaintexts that hash to the same value. Yes, that's also why the canonicalization part is important, or it becomes “easy” to pad with crap in a comment and generate a value with the same hash as some other document but significantly different apparent content. (I'd not want to try matching one particular hash, but rather generating the same hash as one message from a substantial corpus; key reuse substantially weakens security, even if it is part of the freaking point.)If you really want message security, embed it as a modulation on the track of a prog rock yodelling session…
-
@dkf said:
or it becomes “easy” to pad with crap in a comment and generate a value with the same hash as some other document but significantly different apparent content
No, with a cryptographically strong hash function it really doesn't become easy; that's what "cryptographically strong" means. When deliberately creating collisions becomes possible (as has happened with MD5 and its descendants SHA-0 and SHA-1) it's because of specific exploitable weaknesses discovered in the hash function, which is then pretty much disowned by the crypto community.
-
@flabdablet said:
...crypto community
For some reason, I Imagine that whole community speaking lojban and snorting when they laugh...
Like me and my D&D buddies in college, minus the lojban part (not even we were that aspie)
-
@DrakeSmith said:
@flabdablet said:
...crypto community
For some reason, I Imagine that whole community speaking lojban and snorting when they laugh...
Like me and my D&D buddies in college, minus the lojban part (not even we were that aspie)Technically nobody is "aspie" anymore. Fucking pedantic DSM5 dickweeds.
-
@Ben L. said:
@DrakeSmith said:
@flabdablet said:
...crypto community
For some reason, I Imagine that whole community speaking lojban and snorting when they laugh...
Like me and my D&D buddies in college, minus the lojban part (not even we were that aspie)Technically nobody is "aspie" anymore. Fucking pedantic DSM5 dickweeds.
Pff.. nobody uses the DSM-5.
-
@flabdablet said:
If the expected time to find a collision exceeds the expected lifetime of the human species and all its technological works, I think it's safe to say that collisions in a sufficiently large hash will never, in fact, occur.
If you can't turn the hash back into the original data then it's safe to say that collisions will always occur at some moment in time. You might say now that it'll take 10 billion years, but tomorrow, Intel might introduce the 1024-core 3Ghz processor that can do it inside a weekend.
-
@Mole said:
You might say now that it'll take 10 billion years, but tomorrow, Intel might introduce the 1024-core 3Ghz processor that can do it inside a weekend.
Um, 1024 cores wouldn't get you even close to close. Do you people really not get how vast the numbers we're talking about are?
-
@morbiuswilters said:
@Mole said:
You might say now that it'll take 10 billion years, but tomorrow, Intel might introduce the 1024-core 3Ghz processor that can do it inside a weekend.
Um, 1024 cores wouldn't get you even close to close. Do you people really not get how vast the numbers we're talking about are?
Ok, let's say Intel releases a 1461501637330902918203684832716283019655932542976 core processor the day after tomorrow.
-
@morbiuswilters said:
@Mole said:
You might say now that it'll take 10 billion years, but tomorrow, Intel might introduce the 1024-core 3Ghz processor that can do it inside a weekend.
Um, 1024 cores wouldn't get you even close to close. Do you people really not get how vast the numbers we're talking about are?
OK, how about 1024 custom ASICS ?
We thought MD5 was secure until some people broke it and then did a live demonstration at 25C3 to spoof SSL certificates.
It's just a matter of time.
-
@Ben L. said:
Ok, let's say Intel releases a 1461501637330902918203684832716283019655932542976 core processor the day after tomorrow.
Finally, $GAME will run at 60 FPS!
