Silk Road forums

Libertarianism is a white man's ideology.  there's no way in fucking hell you could explain that to the average black man and get him on board.  in his ears he's hearing "lets completely abandon the people who built this country (africans) and allow the klan to run wild.  if you don't want to live in squalor, all you have to do is beat your way to the top of the white man's world with no laws against discrimination."

I thought that black people would be cool with freeing all of the drug prisoners etc. Black people are highly negatively affected by things libertarians want to legalize, even more so than white people. Everybody gets something in libertarianism. The rich people get freedom from taxation and the poor people get freedom from prosecution for victimless crimes. Sure, there should be no laws against discrimination. If people don't like discrimination they wont buy products from companies that are known to discriminate, etc. The market can deal with issues like this very well.

Black people tend to be more anarcho-socialist than anarcho-capitalist though. They want to free the drug prisoners still, but want to steal money from the rich. Anarcho capitalism doesn't play favorites for any race or socioeconomic status, it blindly grants freedom to everybody. I am sure there are some black libertarians though, hell there are black republicans. So it isn't so much a race issue but really more of a socioeconomic issue. Poor people largely are not gonna want to be told they cannot steal from the rich. But it doesn't matter, cuz totalibertarians are not going to let them steal from the rich any more than they are going to let the rich build prison empires filled with poor people

looks like Truecrypt uses the same hash functions for their PBKDF as well

Header key is used to encrypt and decrypt the encrypted area of the TrueCrypt volume header (for system encryption, of the keydata area), which contains the master key and other data (see the sections Encryption Scheme and TrueCrypt Volume Format Specification). In volumes created by TrueCrypt 5.0 or later (and for system encryption), the area is encrypted in XTS mode (see the section Modes of Operation). The method that TrueCrypt uses to generate the header key and the secondary header key (XTS mode) is PBKDF2, specified in PKCS #5 v2.0; see [7].

512-bit salt is used, which means there are 2512 keys for each password. This significantly decreases vulnerability to 'off-line' dictionary/'rainbow table' attacks (pre-computing all the keys for a dictionary of passwords is very difficult when a salt is used) [7]. The salt consists of random values generated by the TrueCrypt random number generator during the volume creation process. The header key derivation function is based on HMAC-SHA-512, HMAC-RIPEMD-160, or HMAC-Whirlpool (see [8, 9, 20, 22]) – the user selects which. The length of the derived key does not depend on the size of the output of the underlying hash function. For example, a header key for the AES-256 cipher is always 256 bits long even if HMAC-RIPEMD-160 is used (in XTS mode, an additional 256-bit secondary header key is used; hence, two 256-bit keys are used for AES-256 in total). For more information, refer to [7]. 1000 iterations (or 2000 iterations when HMAC-RIPEMD-160 is used as the underlying hash function) of the key derivation function have to be performed to derive a header key, which increases the time necessary to perform an exhaustive search for passwords (i.e., brute force attack) [7].

Header keys used by ciphers in a cascade are mutually independent, even though they are derived from a single password (to which keyfiles may have been applied). For example, for the AES-Twofish-Serpent cascade, the header key derivation function is instructed to derive a 768-bit encryption key from a given password (and, for XTS mode, in addition, a 768-bit secondary header key from the given password). The generated 768-bit header key is then split into three 256-bit keys (for XTS mode, the secondary header key is split into three 256-bit keys too, so the cascade actually uses six 256-bit keys in total), out of which the first key is used by Serpent, the second key is used by Twofish, and the third by AES (in addition, for XTS mode, the first secondary key is used by Serpent, the second secondary key is used by Twofish, and the third secondary key by AES). Hence, even when an adversary has one of the keys, he cannot use it to derive the other keys, as there is no feasible method to determine the password from which the key was derived (except for brute force attack mounted on a weak password).

I would be hesitant to go that route personally because of concerns due to entropy diffusion (I used to say distribution but seems everybody calls it diffusion so time to switch my terminology. Diffusion = the input entropy is evenly distributed throughout the output) from the hash function.

Some links and short quotes from them

A class of functions called "message digests," "cryptographic checksums," etc. have a number of useful properties. They are designed for producing digital signatures, integrity checks, and so on, and to do so in the face of an adversary who wants to forge one of these. Digesters are designed in Ron Rivest's words to be secure in that, "It is computationally infeasible to find two messages that hashed to the same value. No attack is more efficient than brute force." Thus, if we hash a series of random samples, it is not practical to learn what those samples were. Note that this is the same thing as my definition of the output's being perfectly random, and thus the hash preserves the entropy found in the samples. This has the additional useful effect that many weakly entropic samples can be combined to carry entropy equivalent to the whole of the entropy of all the samples. Note that while these hashes distill entropy, they cannot hold more entropy than their size. They are bottles that you can shake up entropy in, but a 128-bit hash cannot hold 129 bits worth of entropy.

These characteristics make them excellent functions for our purposes. Common functions used today are MD2, MD4, and MD5 (done by Ron Rivest), SHA (the US government's Secure Hash Algorithm, also known as SHS, the Secure Hash Standard), GOST (the Russian hasher), RIPE-MD, and RIPE-MD160 (which are European standards for hashes).

www.iacr.org/archive/crypto2004/31520493/clean.pdf

    The tools used to derive a uniform key from these sources of imperfect ran-
domness are often referred to as randomness extractors. The amount of theo-
retical results in this area is impressive; moreover, some of the constructions
that have proven extraction guarantees are also efficient (see [Sha02] for a recent
survey). One such example is the so called “pairwise independent universal hash
functions” (also called ”strongly universal”) [CW79] which have quite efficient
implementations and provable extraction properties. In particular, [HILL99]
shows (see also [Lub96,Gol01]) that if an input distribution has sufficient min-
entropy (meaning that no single value is assigned a too-large probability even
though the distribution may be far from uniform) then hashing this input into a
(sufficiently) shorter output using a function chosen at random from a family of
strongly universal hash functions results in an output that is statistically-close
to uniform. (This result is often referred to as the “Leftover Hash Lemma”.)

Actually had some trouble digging up citations for these properties, I wish I could find the first thing I read when I first learned about cryptographic hash functions, it defined all of these properties. But hopefully these two quotes are enough to show my concern: the hash function distills randomness up to the maximum size of the output of the hash function, and it takes the possibly non-uniform randomness of the input and produces a uniformly random output. My concern about using SHA512 to produce a key for a 256 bit symmetric algorithm is that if only half of the output of SHA512 is used, perhaps only half of the randomness of the password is used, if the password contains less than 512 bits of entropy.

PBKDF2 doesn't XOR together bit pairs of the output, or take the SHA256 value of the output. It keeps running SHA512. So they really are keying AES-256 with partial output from SHA-512. I would love for someone to explain to me why entropy diffusion after hashing a password with less than 512 bits of entropy doesn't lead to a weakened key when half of the 512 output bits from the hash are used. I did ask about this in the past and someone said he would argue that using part of a SHA512 hash like this would be just as safe as using SHA256, but he didn't explain why or seem 100% certain. I would imagine it is safe or else there would be warnings about it with PBKDF2 or something I imagine, but to me it doesn't make sense.

If hashing an input uniformly distributes its entropy into the output, and the input has 256 bits of entropy, and the output has 512 bits, it seems that each bit of output has half a bit of entropy, and therefor taking 256 bits from this output to key AES-256 would have 128 bits of entropy only. Again, love for someone to explain to me why I am wrong (I wouldn't be surprised if I am, but I just don't see why), or explain to me why it is better to use half of a SHA512 hash versus just using a secure hash that produces the number of bits needed to key the symmetric algorithm in the first place.


In the case of using a hash function that produces less than 256 output bits I wouldn't see this concern, because the PBKDF can stretch the randomness of the password into an arbitrary length stream, but when using a hash function with more than 256 output bits it seems that although it can stretch the randomness of the password into pseudorandomness still, the entropy will still be diffused throughout the output bits (meaning with 256 bits of randomness in the password, you still have 256 bits of entropy in an arbitrary number of 512 bit outputs, but each of the output bits only has half a bit of entropy), which would seemingly cut the effective entropy of the password in half if it isn't enough to fill the limit of the hash function used (because 256 bits spread over 512 bits of output means each bit has half a bit of entropy, and when you use half of the final output to key the 256 bit algorithm, it means your key only has 128 bits of entropy. Or if your password has only 30 bits of entropy, the key has only 15 bits of entropy, since 30 bits of entropy diffused over 512 bits means each output bit has .05859375 bits of entropy, and .05859375 * 256 used bits = 15 bits of entropy). 

However even in the case of using a hash function with 160 bits of randomness, it seems that the limit of the security would be 160 bits. You can stretch a 160 bit seed out to an arbitrary length stream, but cracking the initial seed will always allow you to generate the entire stream. This is easy to prove, assume you have a single random bit, it is either 1 or 0. You can stretch this out indefinitely by hashing it with a counter for example, so:

H({1,0}) = O
H(O || 1) = O1
H(O1 || 2) = O2

but this only has 1 bit of security, because the attacker knows you either started with 1 or with 0. So I think you can stretch the initial entropic seed out indefinitely, but the total security of the system cannot be larger than the initial seed. So using a 160 bit hash function for the PBKDF to key a 256 bit algorithm means you cannot have more than 160 bit security.

So I am not sure how I feel about ANY of the hash functions that Truecrypt offers! Either we can use a 512 bit hash algorithm and diffusion of entropy will cut the effective keyspace of most passwords in half (it seems to me, please tell me why I am wrong), or we can use a 160 bit hash and the security of AES-256 is actually limited to 160 bits, since passwords with more than 160 bits of entropy don't contribute additional entropy to the PBKDF output . Why don't they include a 256 bit hashing algorithm??

I really doubt that gladiators were castrated, that would tremendously (totally?) reduce their testosterone and make for some pretty feminine looking guys having chick fights.

Quote from: EastCoastCollective on September 15, 2013, 05:59 pm

According to an article  published on 9/5/13 in USAtoday.com  NSA spent  many billions building a supercomputer that can crack any and all encryption software  After reading the article I wondered if its useless to encrypt??

OH EM GEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE!!!!

Ok, the NSA have no such supercomputer because no kind of supercomputer can get round the P vs NP problem (and there may be no way around it, but no one knows right now). This would be a mathematical breakthrough MUCH larger than finding the Higgs Boson.

I have heard some people say that quantum computers imply that P = NP, although the fact that this isn't breaking news seems to indicate that perhaps the people researching quantum computers are full of shit. None of them seem to directly make such a claim, but some people take the claims they make to imply it. In computer science quantum computers are actually kind of controversial it seems to me. Traditional computer scientists seem to dismiss them in many cases, but perhaps it is just because they don't know enough about them. Even cryptographers used to dismiss them, but they seem to be more and more accepting of the fact that they are real now. I think that quantum computers kind of go beyond traditional computer science and more into the realm of advanced physics applied to computation. Certainly that is the case with quantum cryptography, which is very different from traditional cryptography and has a very physics oriented slant to it. (IE: Traditional cryptography you may scramble a plaintext and transmit it on the line, such that if it is intercepted it cannot be deciphered between location A and B. With quantum cryptography, you may use quantum teleportation to transfer a plaintext from point A to point B such that it does not exist at any point between A and B to be intercepted in the first place.)

On the other hand, I don't think it has ever been proven that prime factorization is NP-complete, so perhaps quantum computers theoretic ability to trivially factor massive numbers into primes doesn't imply that P = NP, but rather implies that prime factorization was never NP-complete to begin with. So just because a quantum computer can factor huge numbers into primes doesn't mean that there has been an answer to P vs NP, but is more likely to imply that some problems thought to be, but never proven to be, NP-complete, were actually never NP-complete to begin with.

What NSA have apparently done is weaken commercial encryption algorithms (usually by making the entropy generators less than random) so that they CAN break the encryption, but strong encryption is still strong. For instance, on a desktop pc it would take 6.4 quadrillion years to brute-force 2048bit RSA encryption. Working using conventional algorithms the D-Wave2 can compute problems 3600x faster (according to the wiki page - the only place I could find that had actual facts, no just glossy brochure crap), which still places it at taking 1.8 trillion years to brute force.

A true quantum computer with enough stabilized qubits is allegedly able to trivially break RSA and ECC and DH and most public key encryption. It is also allegedly able to cut the bit strength of a symmetric algorithm in half. It is true that right now it looks primarily like the NSA has subverted cryptography via influence over the standards as well as releasing some backdoored things, such as the PRNG dual_ec_drbg. However, the NSA is also very likely at the cutting edge of quantum computing, and that is a risk to take into account as well. On the other hand, the NSA is also at the cutting edge of traditional computing, and it is possible that their super computers are merely trying to brute force passwords and crack smaller traditional encryption keys (like RSA or DH 1,024).

Now, where quantum computers excel is in that they can execute Shor's algorithm - this can use unique properties of qubits to break encryption. Don't ask me how it works, I'm working on learning about this kind of thing, but am not that advanced yet. However, this is not just some kind of magic spell any old quantum processor can manage, there are requirements. For starters, the noise needs to be low enough, but let's assume that is for now. The main point is that you need enough qubits. 512 qubits is very respectible, but as far as I can tell you need more qubits than the number of bits in the encryption key. Most sources say twice as many, did find this which suggest RSA768 can be broken with 1154quibits - about 1.5x the bit of the encryption key:

CLEARNET
http://www.nature.com/nature/journal/v499/n7457/fig_tab/nature12290_T1.html

So, to crack a 2048bit RSA they would need around 3000+ qubits. 512qubits is respectible, but not enough.

Sounds right, nice source I have never been able to find exact numbers for how many qubits are required to break an X bit RSA key. On the other hand we should be a bit worried, because over the past few years the number of qubits in quantum computers has grown by two orders of magnitude already. If they keep up at this rate, and they only need 1.5 times as many qubits as RSA key has bits, they may be able to break even 4,096 bit RSA keys in the next couple of years.

The final point is this - even if they did have a black box that could do this, it still takes some time and resources each time. They can't just decrypt everything in real time, and even if they could they do not have the HuMint resoruces to interpret it in real-time. The more encryption used, and the better the encryption, the harder and more costly it is for them and the more they have to use discretion over who they target.

Shors algorithm can decrypt things in nearly real time. If a quantum computer exists that can crack RSA-X, it can crack RSA-X almost instantly.

Quote from: kmfkewm on September 15, 2013, 05:25 pm

But you can key AES-256 with partial output from SHA-512. You would just split the output in half. But might as well just use SHA-256. I believe it is also debatable if it would be safer to use SHA-512 or SHA-256. I have read some things indicating that SHA-256 would be safer, but one cryptographer I talked with said he would make the case that it is equally safe to use half a SHA-512 output as it is to use an entire SHA-256 output.

The thing is, cryptographic hash functions distill and evenly distribute randomness. At least, this is according to one thing I read a long time ago when I was first learning about cryptographic hashes, and I think it is true. So if you feed SHA-256 1 bit of entropy, the output 256 bits will have 1 bit of entropy evenly distributed through out them. This is the distributive property of cryptographic hash functions, the distillation property is that if you feed it 1000 bits of data which contain 1 bit of entropy, the output hash will have 1 bit of entropy in 256 bits of data. So if this is a correct understanding of cryptographic hash functions, it would seem that it would be safer to use SHA-256 to key AES-256, because let's say your password contains 256 bits of entropy. You feed the password to the hash function and the output hash has 256 bits of entropy. If you use SHA-512 and feed it a password with 256 bits of entropy, the output also has 256 bits of entropy, but now it is spread over 512 bits. When you take half of those bits to key AES-256, it would seem like you are only actually getting 128 bits of security, as each bit from the hash function has half a bit entropy due to the distributive property of cryptographic hash functions.

I am not sure if this happens in practice. From what I have read about cryptographic hashing functions, it seems like it should happen this way, and that it would be safer to use SHA-256 for the hash function to generate a key for AES-256. But like I said, one crytpographer said he would argue that both methods are equally secure.

SHA-512 is largely identical to SHA-256 isn't it?  but operates on 64-bit, thus there are some computation artifacts of SHA-512 that make cracking programs like hashcat harder to use with GPUs, giving you a slight advantage to not being at the mercy of GPU cloud hashing.

I don't know the specification of SHA-256 or SHA-512, but their output hashes are totally different for the same input. To protect from GPU cloud hashing attacks on password hashes you would use a PBKDF with a lot of iterations. Some GPU's can produce SHA-256 hashes really fast, particularly AMD GPU's, as explained below

https://en.bitcoin.it/wiki/Why_a_GPU_mines_faster_than_a_CPU#Why_are_AMD_GPUs_faster_than_Nvidia_GPUs.3F

Firstly, AMD designs GPUs with many simple ALUs/shaders (VLIW design) that run at a relatively low frequency clock (typically 1120-3200 ALUs at 625-900 MHz), whereas Nvidia's microarchitecture consists of fewer more complex ALUs and tries to compensate with a higher shader clock (typically 448-1024 ALUs at 1150-1544 MHz). Because of this VLIW vs. non-VLIW difference, Nvidia uses up more square millimeters of die space per ALU, hence can pack fewer of them per chip, and they hit the frequency wall sooner than AMD which prevents them from increasing the clock high enough to match or surpass AMD's performance. This translates to a raw ALU performance advantage for AMD:

    AMD Radeon HD 6990: 3072 ALUs x 830 MHz = 2550 billion 32-bit instruction per second
    Nvidia GTX 590: 1024 ALUs x 1214 MHz = 1243 billion 32-bit instruction per second

This approximate 2x-3x performance difference exists across the entire range of AMD and Nvidia GPUs. It is very visible in all ALU-bound GPGPU workloads such as Bitcoin, password bruteforcers, etc.

Secondly, another difference favoring Bitcoin mining on AMD GPUs instead of Nvidia's is that the mining algorithm is based on SHA-256, which makes heavy use of the 32-bit integer right rotate operation. This operation can be implemented as a single hardware instruction on AMD GPUs (BIT_ALIGN_INT), but requires three separate hardware instructions to be emulated on Nvidia GPUs (2 shifts + 1 add). This alone gives AMD another 1.7x performance advantage (~1900 instructions instead of ~3250 to execute the SHA-256 compression function).

so yeah GPU's are currently more specialized for SHA-256 than SHA-512. However, by using a PBKDF you can strengthen your password by much more than you can by switching from SHA-256 to SHA-512. PBKDF will use SHA-256 (or whatever) and iterate perhaps a hundred thousand times. So if using SHA-512 takes twice as much time for the GPU to make a hash, using SHA-256 with PBKDF with 100,000 iterations will take 100,000 times as long. Of course you could switch to SHA-512 with so many iterations, but you can always just add more to SHA-256 as well. There is no problem to make key generation from a password take X amount of time with Y hardware, and it is just as effective to use a PBKDF with more iterations as it is to switch to a new hashing algorithm.

No idea about ASIC or FPGA's though, I would assume they don't have this problem.

I don't think even GPU's have this problem theoretically, they are just not as optimized for SHA-512 as they are for SHA-256. Although it is probable that SHA-512 takes longer than SHA-256 inherently anyway, but as I said before you can use a PBKDF to make key generation take as long as you want on any given hardware.

All the encryption I've seen to make containers and the like, are using SHA-512 (Schneier also advocates SHA-512, but says there's nothing wrong with any SHA-2) while all the software implementations to use bcrypt/encrypt databases, are using sha256, probably to avoid that password spreading problem you talked about when feeding in passwords to avoid the 72 byte limit (though Password1 is now using 512)

What are they using them for though, is the important question. Also, how are they using them. It is literally impossible to use a 512 bit output for an AES-256 key, AES-256 needs a key that is exactly 256 bits. The only way you could use a SHA-512 hash for AES-256 is if you only use half of the output bits. In which case I would probably just use SHA-256, since it matches up. If I was using a password based key and wanted to make an attacker spend more time to guess passwords, I would use SHA-256 with a PBKDF with as many iterations as the user could stand. I am not positive if the entropy distribution problem actually will come into play, but from what I have read on hash functions I would be afraid that it would. A cryptographer friend said he would argue that both methods are equally as secure. I noted that he didn't say they are equally secure. I would therefore lean toward caution by using SHA-256 to key a 256 bit encryption algorithm, rather than using half the output bits of SHA-512.

Example:  $h=crypt(hash('sha256', $p),'$2y$......................');  bcrypt and scrypt make it really hard for GPUs to crack anyways. There's also this, which is a bcrypt 256 implementation to separate keys from server and encrypt the hashes as well http://sebsauvage.net/paste/?a99d7b619aa2a028#Ey6MdAyxEywI7JAox7afg7wBBSf0bh/qS6wnQ2MD1OU=

Meanwhile TC is using SHA-512, Whirlpool (512), and RIPEMD-160 hashes for AES256 keys.

Truecrypt uses those hash functions as part of its custom PRNG, it doesn't directly use them to produce keys. Truecrypt produces keying material with its PRNG, the hash functions it uses as entropy distributors (entropy diffusers they call them).

http://www.truecrypt.org/docs/random-number-generator

I can't really comment on the way their PRNG works. I would have done it a little bit differently, and more straight  forward imo. After getting the raw input from mouse position etc, I would concatenate it together into a single buffer every few seconds, then take the SHA-256 sum. Then I would take this SHA-256 sum and use it as the basis for the next round, with new raw input being concatenated to the previous SHA-256 sum, and then after a few seconds the new value being hashed, etc, for however long the user desires. Another property of a cryptographic hashing algorithm is that the output hash should contain exactly as much entropy as the input fed to it. So if I feed SHA-256 1000 bits that contain 1 bit of entropy, the output SHA-256 hash should have 1 bit of entropy. If I use this hash for the basis of the next output, and concatenate 1000 bits with 1 bit of randomness to it, when I hash this the next SHA-256 output should have 2 bits of entropy. At this rate, it will take 256 cycles to have 256 random bits. Then I would key AES-256 directly with this hash value.

Of course the hash value used to key AES-256 is not based on a password. Truecrypt generates a random key for AES-256 and then it encrypts this key with another key generated by the users password.

I wouldn't use SHA-512 because I would be too worried that the user would only accumulate 256 bits of entropy, and that they would be distributed evenly thoughout the 512 bit output, leading to the AES key only having 128 bits of entropy. Though I suppose you could use SHA-512 and XOR every pair of bits together to get a 256 bit key. Or you could take the SHA-256 value of the SHA-512 value. Using half of the SHA-512 value seems risky though. And I don't see a reason to use SHA-512 and then SHA-256 versus just using SHA-256 to begin with.

Jack N Hoff - you are very correct in that - where would the DEA be if we changed these laws, What would the companies that build prisons do?  What would all the parole officers do? It almost seems that there is a sub economy in the USA that is built around just drugs and making sure that they make money for big government!!!

Slavery never died in the USA it has only changed the way it manifests itself. USA is a nation that is highly dependent on slavery.

Why be so mad at me? I am just one person, I cannot do anything to change the fascist countries that imprison people for victimless crimes. Why not be mad at Japan or Russia or the other countries that allow people to legally view CP? Why not be mad at Germany or Italy or Estonia or any of the other countries that allow people to legally have sex with 14 year olds? Do you really think I am sick because I think Germany has a good age of consent system? Do you really think I am such a sick fuck for thinking Japan has the best CP laws? Anybody who disagrees with the law of your country is a sick fuck I take it. So are you a nationalist or what?

You think Germans all want to fuck 14 year olds (well, they probably mostly do, just like most men probably do, but whatever)? Or do you think they just don't want to criminalize behavior that doesn't cause harm to others? You think anyone who thinks weed should be legal is a pothead then? Do you think Germany and Estonia etc are nations ruled by child abusers who want to exploit children? Because they have laws that are in line with what I think the laws of the world should be, in regards to age of consent. You think I am a sick fuck because I think Germany has the best age of consent system, so it seems you think all Germans are sick fucks then.