Silk Road forums
Discussion => Security => Topic started by: bynter on January 09, 2013, 05:52 am
-
In my Computer Science class, I recently learned how encryption works. If I remember correctly, it's by using a large number for encrypting a file and two prime factors for encryption.
My question is how come this cannot be applied to PGP. Wouldn't it just be a matter of processing power and time for finding factors and thus, the encryption key?
-
Yes, it would. 512 bit keys can already be cracked, which is why it's mind-boggling stupid that some PGP programs use that as a default key size. 1024 bit keys will probably be cracked in the next 5 years, so those aren't safe anymore either. That's why we recommend at least a 2048 bit key, but 4096 bit is better because it buys you even more time.
So why don't we just use one million bit keys? Because it's computationally expensive to use them and that increases non-linearly with key size. Nobody wants to wait a few hours (or days or weeks) to encrypt a message. So there's a trade off: the level of security that we accept as convenient but still safe is usually something that can be broken in 20 years (instead of a million years), and we increase our security (in this case, key size) over time.
-
In my Computer Science class, I recently learned how encryption works. If I remember correctly, it's by using a large number for encrypting a file and two prime factors for encryption.
My question is how come this cannot be applied to PGP. Wouldn't it just be a matter of processing power and time for finding factors and thus, the encryption key?
It can, and it has. Maybe 15 years ago, a 384-bit key (that was listed as the 'personal' size in those days) was cracked. This key was generated by Tim C.May, one of the Cypherpunks, under the name "BlackNet". BlackNet was a pseudonymous entity that offered payments for government secrets leaked to them. Information was leaked by posting it to Usenet, encrypted with BlackNet's PGP key.
My understanding is that the largest RSA key broken to date is 768-bits, though I haven't looked at this in some time. Back in 2002, at the Financial Cryptography seminar, it was announced that a group was cracking 512-bit keys in a few weeks on spare hardware they had laying about the office.
Within the last year or two, a 1024-bit Mersenne Prime was cracked by a team including Arjen Lenstra. Lenstra is famed for being a factoring guru. A Mersenne prime is a special case of a prime number, and due to its special features, it is easier to factor than any randomly-chosen prime of the same size. The last time Lenstra cracked such a prime it was 5-7 years afterward that general primes could be factored of an equivalent size.
Given that this 1024-bit Mersenne prime break was about 1-2 years ago, it is expected that a randomly-chosen 1024-bit prime will be broken within the next 5 years or so.
Nightcrawler <Nightcrawler@SR>
PGP-Key: 4096R/BBF7433B 2012-09-22
Key fingerprint = D870 C6AC CC6E 46B0 E0C7 3955 B8F1 D88E BBF7 433B
http://dkn255hz262ypmii.onion/index.php?topic=174.msg633090#msg633090
-
LOL, a 384 bit key. And this is why even with encryption, you will want to destroy any messages more than 10 years old. Posting them on Usenet, which Google has cached for eternity, was not a good idea.
-
LOL, a 384 bit key. And this is why even with encryption, you will want to destroy any messages more than 10 years old. Posting them on Usenet, which Google has cached for eternity, was not a good idea.
This was intended as a joke/thought experiment, which is why May used a 384-bit key. I can remember versions of PGP that specified 384-bit keys for personal use, 512-bit for business use, and 1024-bits as a maximum key size. It was about 12-15 years ago that Phil gave every PGP user a Christmas present, when the software switched-on a flag on December 25th, allowing the generation/use of 2047-bit keys. (They were supposed to be 2048, but there was a bug.)
Since that keysize was enabled, anyone with even a lick of sense has been using 2048-bit keys. (I know I haven't used any key smaller than 2048-bits since then.) Additionally, anyone posting to Usenet should have used a layer of conventional encryption, if for no other reason than to frustrate traffic analysis.
Nightcrawler <Nightcrawler@SR>
PGP-Key: 4096R/BBF7433B 2012-09-22
Key fingerprint = D870 C6AC CC6E 46B0 E0C7 3955 B8F1 D88E BBF7 433B
http://dkn255hz262ypmii.onion/index.php?topic=174.msg633090#msg633090
-
Great thread.
Thanks for the info, guys.
-
Here's a great article on just what these motherfuckers are up to:
CLEARNET: http://www.wired.com/threatlevel/2012/03/ff_nsadatacenter/all/
The elephant in the room here is where quantum computing goes in the next 10 years. Sounds like the 4096 bit keys we have now should at least last until the statute of limitations runs out. But these asswipes will keep stealing our money and spending it on projects like this. All we can hope is that the code makers stay ahead of the code breakers, but even so it appears encryption will always have a expiration date.
-
Wow. It's actually really reassuring to see that my question wasn't nearly as stupid as I thought it would have been received.
So I guess that means that if you have access to a company with huge servers, it'd only take a few weeks to crack messages.
I have a feeling once this NSA thing is completed, this site will see a lot more arrests. Man, fuck post-9/11 paranoia.
but how come it isn't practical for banks to crack the encryption for competing banks, then publicly release that information and blame it on Anonymous?
-
Wow. It's actually really reassuring to see that my question wasn't nearly as stupid as I thought it would have been received.
It was not a stupid question.
So I guess that means that if you have access to a company with huge servers, it'd only take a few weeks to crack messages.
Only if the messages in question were encrypted with keys of 512-bits or less. Keys with moduli of 2048-bits are expected to be safe until around 2030 or thereabouts. 4096-bit keys are expected to be secure for perhaps another 10-15 years after that. These estimations are based on current knowledge of factoring, and assuming that Moore's law continues in effect. Naturally, breakthroughs can occur at any time, so these numbers should be taken with a grain of salt.
I have a feeling once this NSA thing is completed, this site will see a lot more arrests. Man, fuck post-9/11 paranoia. but how come it isn't practical for banks to crack the encryption for competing banks, then publicly release that information and blame it on Anonymous?
The facility currently being completed in Utah is expected to function primarily as a storage facility. Rather than choosing which targets to harvest information on, apparently the practice will be to surveil everyone, so if an individual (or group of them) become persons of interest, a wealth of information will already be available for data-mining.
As far as seeing a lot more arrests on this site? That's not at all likely to happen. You have to remember that, even if quantum computers actually existed in a state which could break the majority of currently enciphered traffic, this would be a state secret. It would be used against other governments, possibly against terror cells -- it is not likely to be used against individual drug users, especially small-time users.
Look back at history. The British (with the help of the Poles) managed to obtain some German Enigma cipher machines. Thanks to the efforts of a dedicated group of people (including Alan Turing) the British managed to crack the Enigma. They were reading high-level German cipher traffic as soon as the German generals themselves got it. This was considered _so_ important, that knowledge of this was classified until the mid-1970s.
Similarly, around 1970, Ellis & Cocks, two cryptographers at GCHQ, the British equivalent of the NSA, developed what they called "non-secret encryption." This was the first public-key cryptosystem. Several years later, Diffie, Hellman and Merkle independently struck upon the same concept, and published a paper, letting the cat out of the bag. Naturally, the British immediately classified Ellis and Cocks' work, and nothing further came of it. Even when Diffie visited Ellis in Britain, the man remained mum about his discovery. The closest he came to even admitting it existed, was a comment he made to Diffie to the effect that, "You did more with it then we ever did."
So, even if any breakthroughs have been made, information from these will not be used to prosecute small time drug users, or even pedophiles. Secrecy is too important to let it be endangered by such uses. Furthermore, you have to understand that agency rivalry is a major factor here -- the Intelligence agencies don't trust each other -- the NSA doesn't trust the CIA, and neither the CIA nor the NSA trust the FBI, let alone the DEA.
For their part, the NSA's prime directive, if you will, is to protect anyone from learning of their true capabilities. They're not going to be caught dead sharing information with other agencies that might shed light on their capabilities.
Finally, there is both politics as well as economics to contend with. In the past 40 years, since Nixon began the War on Drugs, America has changed dramatically -- from being a creditor nation, to a debtor nation. America's manufacturing infrastructure is hollowed-out, and the middle class is in real danger of becoming extinct. I would argue that the Drug War is a war that America can no longer afford. We're already beginning to see the cracks in that political position, with two states legalizing marijuana. This is just the tip of the iceberg. It may take another generation (or even two) but eventually Americans will conclude that the Drug War is unsustainable. The true irony is that both the U.S. government and the drug cartels are on the same side -- both of them are terrified of legalization. If drugs were legalized, the cartel's profits would vanish in a puff of smoke.
Nightcrawler <Nightcrawler@SR>
PGP-Key: 4096R/BBF7433B 2012-09-22
Key fingerprint = D870 C6AC CC6E 46B0 E0C7 3955 B8F1 D88E BBF7 433B
http://dkn255hz262ypmii.onion/index.php?topic=174.msg633090#msg633090
-
As far as seeing a lot more arrests on this site? That's not at all likely to happen. You have to remember that, even if quantum computers actually existed in a state which could break the majority of currently enciphered traffic, this would be a state secret. It would be used against other governments, possibly against terror cells -- it is not likely to be used against individual drug users, especially small-time users.
Nightcrawler <Nightcrawler@SR>
PGP-Key: 4096R/BBF7433B 2012-09-22
Key fingerprint = D870 C6AC CC6E 46B0 E0C7 3955 B8F1 D88E BBF7 433B
http://dkn255hz262ypmii.onion/index.php?topic=174.msg633090#msg633090
I don't even mean using their breakthroughs. I mean just diverting some of their computing power to decrypt messages tactically chosen for estimated importance and context from high profile SR sellers, which, with that sort of power, would only take a few hours and small fraction of a percent of their available processors.. That really doesn't seem too impractical. and only a few key arrests could really scare the rest the community.
Say, How many bits is the encryption banks use?
and +1 for your informational post.
-
Not all encryption is actually based on public-key cryptography (asymmetric ciphers). There's symmetric ciphers (basically you share the private key and use it to both encrypt & decrypt -- more "symmetry" in the process than public/private key pairs is how I remember it), and no doubt a bunch of stuff I don't even know about -- cryptography research isn't a trivial field of math/computer science, and I'm not even going to pretend that I try to keep up with the literature. Amusingly enough, the only encryption system I know of that's actually provably as secure as randomly generating characters (meaning it's as hard to break as pure gibberish) is a one-time pad. It's not very practical though; you can look it up if you're curious. Other than that, nobody's proven that our encryption schemes are actually secure. Nobody knows of a way to break them (presumably not even the big governments), but there's no guarantee that tomorrow some genius won't discover a mathematical shortcut that allows factoring huge numbers in seconds (which would make all our public key cryptography useless). Quantum computing isn't the only issue.
To answer your question though: basically brute forcing the encryption is much, much harder than finding a vulnerability in the surrounding software. Honestly I've never worked with large-scale financial systems personally and don't know what schemes they typically use, but that's just how all software is these days: it's easier to get around the mathematical encryption than it is to go through it.
-
generally asymmetric cryptography is used to transfer keys used for decrypting symmetrically encrypted messages
-
AFAIK, PGP keys of any size have never been "cracked" but rather were attacked through "brute-force" by going through all possible combinations. Some algorithms have been developed that can *slightly* reduce the amount of time needed to brute force a given key, but it still takes time and computing power to break even the 512bit keys.
With any sort of cryptography other than an OTP (one time pad, as mentioned by SelfSovereignty), it's important to think of security in terms of how long it would take a determined attacker with immense resources to decrypt the message with brute force. Any given message encrypted with 512bit encryption could probably be deciphered in a few days with government resources, 1024bit probably a few years, and 2048bit a few millennium (Moore's "law" notwithstanding). And remember this is the time for breaking any one particular message - any other messages encrypted with the same size key would also each require the same computational investment to decipher. And please note these numbers are approximations pulled out of my ass - I'd Google it all, but Tor is too slow for that kind of research.
Now the quantum computing bugaboo could render this all irrelevant, but it would also render the crypto used by governments and financial institutions irrelevant too. Fortunately quantum computing is 99% theoretical and the 1% that is actually achievable is essentially useless. QC has intractable problems related to decoherence and integrating input-output infrastructure which makes it nearly impossible to scale up to any useful applications. QC is mostly useful in investment scams and as disinfo to make people doubt their cryptographic security.
Just my 2-bits ;)
-
Now the quantum computing bugaboo could render this all irrelevant, but it would also render the crypto used by governments and financial institutions irrelevant too. Fortunately quantum computing is 99% theoretical and the 1% that is actually achievable is essentially useless. QC has intractable problems related to decoherence and integrating input-output infrastructure which makes it nearly impossible to scale up to any useful applications. QC is mostly useful in investment scams and as disinfo to make people doubt their cryptographic security.
Naw. They're too many professionals that are in favour of it. Quite a few professors at my college seem to be really excited about what it'll be doing thirty years from now.
-
AFAIK, PGP keys of any size have never been "cracked" but rather were attacked through "brute-force" by going through all possible combinations. Some algorithms have been developed that can *slightly* reduce the amount of time needed to brute force a given key, but it still takes time and computing power to break even the 512bit keys. [/.quote]
You're confusing factoring versus brute-force. PGP keys HAVE been factored, albeit small ones.
With any sort of cryptography other than an OTP (one time pad, as mentioned by SelfSovereignty), it's important to think of security in terms of how long it would take a determined attacker with immense resources to decrypt the message with brute force. Any given message encrypted with 512bit encryption could probably be deciphered in a few days with government resources, 1024bit probably a few years, and 2048bit a few millennium (Moore's "law" notwithstanding).
It was speculated about 11 years ago now, based on some of Bernstein's work, that the Feds may have the ability to factor 1024-bit keys in a reasonable amount of time. This is why Cypherpunk Lucky Green revoked all of his 1024-bit keys in the Spring of 2002.
And remember this is the time for breaking any one particular message - any other messages encrypted with the same size key would also each require the same computational investment to decipher. And please note these numbers are approximations pulled out of my ass - I'd Google it all, but Tor is too slow for that kind of research.
i believe this to be Incorrect. If, as was common with the original PGP key format, one key was used for signing, authentication, and encryption, then once a key is broken (i.e factored) then ALL messages encrypted with that key can be decrypted. Factoring or breaking the key essentially refers to the derivation of the private half of the key from the public half. With the modern dual-RSA key format, once an encryption sub-key is factored, all messages encrypted with that sub-key can be decrypted. That is why it is frequently recommended that the encryption sub-key be periodically destroyed and replaced, so as to yield forward secrecy.
Now the quantum computing bugaboo could render this all irrelevant, but it would also render the crypto used by governments and financial institutions irrelevant too. Fortunately quantum computing is 99% theoretical and the 1% that is actually achievable is essentially useless. QC has intractable problems related to decoherence and integrating input-output infrastructure which makes it nearly impossible to scale up to any useful applications. QC is mostly useful in investment scams and as disinfo to make people doubt their cryptographic security.
Just my 2-bits ;)
To the best of my knowledge, the largest number that has yet been publicly factored by a quantum computer is the number 15. This number can also be factored by a dog trained to bark 3 times.
Nightcrawler <Nightcrawler@SR>
PGP-Key: 4096R/BBF7433B 2012-09-22
Key fingerprint = D870 C6AC CC6E 46B0 E0C7 3955 B8F1 D88E BBF7 433B
http://dkn255hz262ypmii.onion/index.php?topic=174.msg633090#msg633090
-
Not a good answer has been given,yet.
Why can't pgp not be cracked quicker , so sooner then 28 years, by a row of supercomputers in conjunction?
I am wondering too why a number of 28 years is given, as the time necessary time to crack or brute-force , so to decrypt, the encryption.
Those 28 years should they not be linked to specs of the computer.
Is it 28 years with a simple zx 81 of Sinclair, or IBM's Blue, or B.O.I.N.C.?
Computers are becoming increasingly stronger.
So to rephrase the question:
""Is pgp's safety not depending on the computing power (cracking/decrypting) of the computer of the attacker?""
EDIT: Like Astor said, the 30 year timeframe includes the future use of quantum computers.
I will paste the proof a.s.a.p. , but right now , I can't seem to find the source, but remember the quantum-computer too.
And it is gpg now.
Pgp is not safe !
-
PGP can be cracked by an attacker with sufficient computing resources. Once you get to 4,096 + bit keys though it is not really feasible for someone to crack in our life times without having a quantum computer. Highly parallel traditional computers can mimic quantum computers, but the resources required to crack that strong of an RSA key with traditional computing power are extremely massive.
-
You're absolutely right, it is linked to the specs of the computers involved. But frankly, I think you may be underestimating just how many calculations are involved here; the fact is computing power progresses at a shockingly predictable rate, and short of mathematical breakthroughs, the things stated here can be taken as reliable information (2048-bit keys being pretty secure for awhile, 4096-bit keys being secure for many years to come).
If you actually get into computer science and analysis of algorithms, you don't stop and preface everything with "all time estimates are using my home first generation Pentium, please read on..." or something. You say it takes N calculations on average, or N calculations in the best case, or N in the worst case, or some other estimate that applies to a situation. It's up to the person who wants to get a feel for that number to translate that into a time frame on a given system; basically I'm saying these are typical answers and they aren't really leaving details out so much as ignoring them because they're meaningless for the subject at hand. Besides... most people find this stuff dry enough as it is without starting to throw in algorithmic jargon.
-
Underestimating?
BOINC has been developed by a team based at the Space Sciences Laboratory (SSL) at the University of California, Berkeley led by David Anderson, who also leads SETI@home. As a high performance distributed computing platform, BOINC has about 540,130 active computers (hosts) worldwide processing on average 7.296 petaFLOPS as of December 2012.[2]
If one computer needs 28 years to decrypt a 2048 bit encryption, boinc only needs a few hours,
I reckon with 100.000 days for 30 years.
There are over 500.000 computers, so I divided one day (24 hours) in five.
Not even 5 hours to decrypt the 28 year safety of a 2048 bit gpg encryption with the boinc specs of dec 2012.
-
except your computer needs more than 28 years to break 2,048 bit encryption
https://www.digicert.com/TimeTravel/math.htm
It is therefore estimated, that standard desktop computing power would take 4,294,967,296 x 1.5 million years to break a DigiCert 2048-bit SSL certificate. Or, in other words, a little over 6.4 quadrillion years.
(this assumption is based on a 2.2 Ghz AMD Opteron processor with 2GB RAM.)
-
If we can crack a 1024 bit key today and computing power doubles every year, then we could crack a 2048 bit key in about a thousand years, since the key space is 2^1024 times bigger than for a 1024 bit key.
The thing is, our ability to brute force keys appears to be increasing faster than Moore's Law. Assuming a doubling rate of one year, we would only be able to brute force 1 more bit per year, 10 bits per decade. The largest cracked key size is increasing much faster than that.
Nightcrawler said that 512 bit keys were cracked in 2002 and we're close to cracking 1024 bit keys now. That's an increase of almost 500 bits per decade, which is why 2048 bit keys won't be safe for more than 20 or 30 years, and that's assuming no disruptive technology comes along.
-
I'm not great with maths but why does cryptography get me a little bit moist... :-[
-
If we can crack a 1024 bit key today and computing power doubles every year, then we could crack a 2048 bit key in about a thousand years, since the key space is 2^1024 times bigger than for a 1024 bit key.
The thing is, our ability to brute force keys appears to be increasing faster than Moore's Law. Assuming a doubling rate of one year, we would only be able to brute force 1 more bit per year, 10 bits per decade. The largest cracked key size is increasing much faster than that.
Nightcrawler said that 512 bit keys were cracked in 2002 and we're close to cracking 1024 bit keys now. That's an increase of almost 500 bits per decade, which is why 2048 bit keys won't be safe for more than 20 or 30 years, and that's assuming no disruptive technology comes along.
Moore's law only refers to the number of transistors that can be put on a single chip of equal space, and since the speed of light is limited, Moore's law isn't going to be accurate by 2020. However, around 2030, when quantum computers take off, technology growth is practically going to by graphed with a vertical line.
Also, even though 1024^2 is a massive number, due to the nature of prime numbers, there are not going to be that many more primes compared to the amount of integers.
-
If we can crack a 1024 bit key today and computing power doubles every year, then we could crack a 2048 bit key in about a thousand years, since the key space is 2^1024 times bigger than for a 1024 bit key.
The thing is, our ability to brute force keys appears to be increasing faster than Moore's Law. Assuming a doubling rate of one year, we would only be able to brute force 1 more bit per year, 10 bits per decade. The largest cracked key size is increasing much faster than that.
2048 bit keys don't have 2^1024 times bigger key space than 1024 bit keys, key space only doubles with each bit for symmetric keys.
there are two 1 bit keys:
1
0
there are four 2 bit keys:
11
00
01
10
any combination of 1's and 0's can be used as a key, and thus (assuming the key is properly derived from an entropic enough passphrase), the attacker must try all possible combinations (or until they find the correct one).
With asymmetric crypto, the problem is a bit different. You are not guessing permutations of 128 or 256 bits until you get it right. Rather you have some number, perhaps a large composite number, and you need to find other numbers that are related to it, perhaps you need to find two prime numbers that are multiplied together to equal it. The difficulty of solving these problems generally does not double for each additional bit, where as the difficulty of finding a permutation of 2^x bits obviously doubles for each additional bit.
I am sure someone better at mathematics can explain it better than I can, unfortunately I am not aware of the exact algorithm used to calculate asymmetric key space for a certain algorithm / key strength. I know there have been several different algorithms of different efficiency for prime factorization, however none of them are efficient enough to be a threat to sufficiently large key spaces. But the point is that it is a bit more of a moving target I suppose. I am not sure when the last major break through regarding prime factorization algorithms was either. Here it says that 600 bit RSA is 25 times harder than 512 bit RSA, but obviously a 600 bit symmetric key is 2^88 times harder than a 512 bit key.
https://www.rsa.com/rsalabs/node.asp?id=2088
It might be argued that this historical data lies BELOW what was theoretically achievable at each data point; that the data represents only modest efforts to break large keys. For example, to do a 600-bit key is about 25 times harder than RSA-512 and would require 5 times the space.
-
That makes sense as to why PGP keys are being cracked so much faster. If 88 bits is 25 times harder, then 512 bits is about 145 times harder, and that would take log2 145 = 7.2 doublings of computational power. Realistically the doubling rate is more like 18 months, so 7.2 * 1.5 = about 10 years, which is what we're observing.
-
Here's the math for "brute-force" attacks on a 256-bit key
Let's start out knowing that with a 256-bit key there are 2^256 (1.1579209e+77) possible combinations.
Fastest computer per Wiki is the "Cray Titan" located in Oak Ridge, USA and it ranks at #1 with producing 17.59 petaFLOPS
So that would be 17.59e+15 regular FLOPS (FLOPS = floating point operations per second)
Number of FLOPS required per combination check: 1000 (very optimistic)
Number of combination checks per second : 1.759e+15 / 1000 = 1.759e+13
Number of seconds in one Year = 365 x 24 x 60 x 60 = 31536000
So the equation would go : 1.1579209e+77 / ( 1.759e+13 x 31536000) = 2.0874037e+56
2.0874037e+56 (2.0874037 x 10^56) years to crack by brute force using this computer alone
--------------------------------------------------------------------------------------------------------------------------------------------------------
Alright now let's take a look at this interesting equation
The Bitcoin network. One of the largest computing networks on the planet and at the current moment can produce 287.31 petaFLOPS of raw computing power.
287.31petaFLOPS = 287.31e+15 FLOPS
Number of combination checks per second : 287.31e+15 / 1000 =2.8731e+14
So the equation would go : 1.1579209e+77 / (2.8731e+14 x 31536000) = 1.2779726e+55
1.2779726e+55 (1.2779726 x 10^55) years to crack a 256-bit key via brute force
Hope that helps
-
You're talking about a symmetric key, like a 256 bit AES key. Read what kmf wrote about PGP keys.
Now that I think about it, the PGP key space must be smaller since 768 bit PGP keys have been broken but even 128 bit AES has not.
-
AFAIK, PGP keys of any size have never been "cracked" but rather were attacked through "brute-force" by going through all possible combinations. Some algorithms have been developed that can *slightly* reduce the amount of time needed to brute force a given key, but it still takes time and computing power to break even the 512bit keys.
You're confusing factoring versus brute-force. PGP keys HAVE been factored, albeit small ones.
Mea culpa! :-[ Point taken. I was trying to say that the PGP protocol (OpenPGP to be specific) wasn't shown to have any security vulnerability or exploit that lets someone decode an encrypted message or derive the private key without going through trial and error factorization (which is what "PGP being cracked" would mean to me).
And remember this is the time for breaking any one particular message - any other messages encrypted with the same size key would also each require the same computational investment to decipher. And please note these numbers are approximations pulled out of my ass - I'd Google it all, but Tor is too slow for that kind of research.
i believe this to be Incorrect.
I believe you are right (what can I say, I was a bit spun when I wrote that ;D). I just meant that factoring a 512 bit key is not the same as breaking PGP or finding a weakness that compromises the other 512 bit keys, it just means key sizes of 512 bits can be feasably broken within a resonable amount of time and are therefore not useful for resisting a determined adversary.
Also, even though 1024^2 is a massive number, due to the nature of prime numbers, there are not going to be that many more primes compared to the amount of integers.
That might seem plausible - until you consider how many primes there really are. A key space of 1024 bits contains approximately 2.5x10^305 prime numbers! To get a feel for how incomprehensibly large a number that is, consider in comparison that the number of atoms in the ENTIRE UNIVERSE is postulated to be a mere 10^80.
That means there are over 1,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 prime numbers that could be used in a 1024 bit key! We would not even be able to go through the tiniest fraction of a percent of the total pool before the heat death of the universe.
I recommend checking out the "PGP Attack Faq" at http://www.iusmentis.com/technology/encryption/pgp/pgpattackfaq/ for a glimpse of the remarkable security PGP provides when used correctly. As it stands now, a key of 2048 bits or larger is most definitely secure unless some as-yet unknown method of polynomial-time prime-factorization is developed. The only realistic attacks on PGP are side-channels and rubber hoses.
-
I remember the distributed.net days when they used tens of thousands of home computers to break 56 bit (symmetric) encryption, and that took a few years. I don't know what a few tens of thousands of computers today would be capable of cracking in a few years. 64 bit? 72 bit? Probably not more than that. On reflection, it was stupid of me to estimate the PGP key space based on that.
-
You're talking about a symmetric key, like a 256 bit AES key. Read what kmf wrote about PGP keys.
Now that I think about it, the PGP key space must be smaller since 768 bit PGP keys have been broken but even 128 bit AES has not.
As far as I know PGP uses a symmetric-key cryptography. PGP also compresses the data and uses a cryptographic hash function. So I'm guessing the cracking "break" would arise from that?
-
AFAIK, PGP keys of any size have never been "cracked" but rather were attacked through "brute-force" by going through all possible combinations. Some algorithms have been developed that can *slightly* reduce the amount of time needed to brute force a given key, but it still takes time and computing power to break even the 512bit keys.
You're confusing factoring versus brute-force. PGP keys HAVE been factored, albeit small ones.
Mea culpa! :-[ Point taken. I was trying to say that the PGP protocol (OpenPGP to be specific) wasn't shown to have any security vulnerability or exploit that lets someone decode an encrypted message or derive the private key without going through trial and error factorization (which is what "PGP being cracked" would mean to me).
And remember this is the time for breaking any one particular message - any other messages encrypted with the same size key would also each require the same computational investment to decipher. And please note these numbers are approximations pulled out of my ass - I'd Google it all, but Tor is too slow for that kind of research.
i believe this to be Incorrect.
I believe you are right (what can I say, I was a bit spun when I wrote that ;D). I just meant that factoring a 512 bit key is not the same as breaking PGP or finding a weakness that compromises the other 512 bit keys, it just means key sizes of 512 bits can be feasably broken within a resonable amount of time and are therefore not useful for resisting a determined adversary.
Also, even though 1024^2 is a massive number, due to the nature of prime numbers, there are not going to be that many more primes compared to the amount of integers.
That might seem plausible - until you consider how many primes there really are. The number of primes in a 1024 bits key space is approximately 2.5x10^305! To get a feel for how incomprehensibly large these numbers are, consider in comparison that the number of atoms in the ENTIRE UNIVERSE is postulated at a mere 10^80.
That means there are over 1,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 prime numbers to choose from in a key size of 1024 bits! The list of available primes will never be exhausted.
I recommend checking out the "PGP Attack Faq" at http://www.iusmentis.com/technology/encryption/pgp/pgpattackfaq/ for a glimpse of the remarkable security PGP provides when used correctly. As it stands now, a key of 2048 bits or larger is most definitely secure unless some as-yet unknown method of polynomial-time prime-factorization is developed. The only realistic attacks on PGP are side-channels and rubber hoses.
What? How is that possible? 1024bit encryption has been cracked before.
-
What? How is that possible? 1024bit encryption has been cracked before.
Mind-blowing, huh? There is an enormous amount of disinfo out there that aims to reduce people's confidence in PGP security. The "story" whose headline loudly scream "1024 bit key cracked in 100 hours" is pure sensationalism and con-artist style hype. Look at the details, you'll see it was just an experimental side-channel attack on a server's OpenSSL key. No encryption was cracked at all.
http://web.eecs.umich.edu/~valeria/research/publications/DATE10RSA.pdf
The only way they were able to derive the key was by having physical access to the server and subjecting the HDD to carefully controlled electrical discharges during authentications. This produced faults in the OpenSSL signature generated by the server during authentication. Finally when they had obtained 10,000 of these corrupted SSL signatures they sorted through them to find the ones that only had a single bit fault on them (no mention at all about how long the experiment had been going on at this point). Then their computers went numbercrunching on the those signatures for 104 hours to produce the private key.
Their experiment doesn't impress me and sure doesn't give me anything to worry about as far as PGP security goes. Besides the fact that it was a side channel attack that could only work under very controlled and limited circumstances, and also leaving aside the question of whether zapping someone's server while reauthenticating thousands of times (for god knows how long) is even remotely possible to do without them knowing something was up, it's important to point out that none of this affects the security of keys or message encryption/decryption.
So no - a 1024 bit key has never been cracked, but it it could probably be done by someone who is either wealthy enough to buy a warehouse full of Cray supercomputers and patient enough to wait a few years, At this point the largest key that's been sucessfuly factored is 768 bits (RSA-768) back in 2009 by a team who worked on it for 3 years. RSA-1024 is estimated to be a thousand times more difficult to factor Crypto geeks do this kind of stuff for the challenge and prestige that comes from being first, but I think the time and resources needed to undertake a 1024 bit key pushes it far into the realm of diminishing returns. Something like 2048 bit keys, I doubt will ever be factored simply because the time, money, and effort is too great (who would set out to work on a problem that with current and reasonably foreseable technology would still require far more time than remains in your expected lifespan? There's a limit to how long the trend of "Moore's Law" can continue, and the chance that "Quantum Computers" will ever be developed into something useful is somewhere between slight and impossible. It's not inconceivable that there could be a way to drastically simplify prime factoring - and a discovery like that would change everything - but I don't see any reason to think something ike is at all likely to happen.
Go ahead and have fun with PGP, just make sure to use key sizes of 2048 bit or larger and then rest easy that no ones going to crack the key. There's practically zero chance that the government would every make any effort to crack keys of that size - they know the time and resources required to do that make it a no-go. Nah, if they decide they want your key they'd just do it the old fashioned way and crack you! That's the way those swine roll. Best to avoid their attention.
-
So I checked with someone who knows crypto better than I do, and the answer is that technically the key space for an RSA key is the number of prime numbers that can be represented with less bits than the key strength, however practically it is the number of prime numbers that can be represented with one bit less than the key strength. So the key space for a 128 bit symmetric algorithm is 2^128 and the key space for a 128 bit RSA key is pretty much the number of 127 bit prime numbers.
-
+1 that makes sense, and we would expect it to be much smaller than all the numbers represented by 127 bits.
3 bits can represent 8 numbers, of which half are prime (2, 3, 5, 7).
4 bits can represent 16 numbers, of which 6 (37.5%) are prime.
8 bits can represent 256 numbers, of which 57 (22.2%) are prime.
It is probably unknown how many primes are in 127 bits (1.7e38 numbers), but given the trend, it's a tiny percentage .
-
You're talking about a symmetric key, like a 256 bit AES key. Read what kmf wrote about PGP keys.
Now that I think about it, the PGP key space must be smaller since 768 bit PGP keys have been broken but even 128 bit AES has not.
As far as I know PGP uses a symmetric-key cryptography. PGP also compresses the data and uses a cryptographic hash function. So I'm guessing the cracking "break" would arise from that?
OpenPGP is a standard and a collection of algorithms. GPG is an OpenPGP compliant software tool that provides these algorithms. It is not in itself an encryption algorithm, rather it is a cryptosystem. GPG is called a hybrid cryptosystem because it uses a combination of asymmetric and symmetric algorithms. There is actually quite a lot that goes into encrypting a message with GPG, although almost all of this is hidden from the user. First a pseudo random number generator is seeded with entropy from some sources (not sure exactly where, probably /dev/random on unix like machines and cryptgenrandom on windows) and outputs a pseudorandom string that is used as a session key. The session key is used in combination with a symmetric algorithm to symmetrically encrypt your communications, which are first compressed. Then the session key is asymmetrically encrypted with the public key of your correspondent. Upon receiving the message, your correspondent types in a passphrase in order to derive a symmetric key that is used for decrypting their stored private key, then their private key is used to asymmetrically decrypt the session key, which is then used in combination with the symmetric algorithm to decrypt your encrypted message. Then it is decompressed and the plaintext is made available.
From a cryptographic point of view, the asymmetric encryption is the weakest link. From a practical point of view, your private key / the system you run GPG on is the weakest link.
-
It is probably unknown how many primes are in 127 bits (1.7e38 numbers), but given the trend, it's a tiny percentage .
The number of primes less than any number, n, is approximated by the formula n/ln(n)
So between 0 and 2^127, there are about 1,932,770,406,530,700,000,000,000,000,000,000,000 or ~2^120 that are prime.
(it comes out to slightly more than 0.01%)
-
OpenPGP is a standard and a collection of algorithms.
Right, instead of PGP key space I should have said RSA, DSA, Elgamal, etc.
-
The number of primes less than any number, n, is approximated by the formula n/ln(n)
So between 0 and 2^127, there are about 1,932,770,406,530,700,000,000,000,000,000,000,000 prime numbers.
(it comes out to slightly more than 1%)
Nice, thanks. So for 512 bits, that's 3.78e151, and for 600 bits, that's 9.98e177. Thus the key space is 2.6e26 times bigger for a 600 bit key, which doesn't explain why it's only 25 times harder to crack, per what kmf said earlier. In fact, 2.6e26 is 2^88, which is the same difference as if these were symmetric keys.
There must be something more to it, because if 1% of the numbers are primes, then it would only be 100 times harder to brute force a 512 bit symmetric key compared to a 512 bit asymmetric key, and that's clearly not the case. The real difference is more like TENS of orders of magnitude.
-
It is probably unknown how many primes are in 127 bits (1.7e38 numbers), but given the trend, it's a tiny percentage .
The number of primes less than any number, n, is approximated by the formula n/ln(n)
So between 0 and 2^127, there are about 1,932,770,406,530,700,000,000,000,000,000,000,000 or ~2^120 that are prime.
(it comes out to slightly more than 0.01%)
But it is not 0 ... 2^127 in practice, because you know that two 8 bit primes are not going to be multiplied into a 128 bit composite number. Although technically the key space is all primes between 0 and 127 bits, in practice I was told the key space is closer to the number of primes that are 127 bits.
-
The number of primes less than any number, n, is approximated by the formula n/ln(n)
So between 0 and 2^127, there are about 1,932,770,406,530,700,000,000,000,000,000,000,000 or ~2^120 that are prime.
(it comes out to slightly more than 0.01%)
But it is not 0 ... 2^127 in practice, because you know that two 8 bit primes are not going to be multiplied into a 128 bit composite number. Although technically the key space is all primes between 0 and 127 bits, in practice I was told the key space is closer to the number of primes that are 127 bits.
That's an excellent point! 8)
I'll have to look into this some more when my brain is working again to see what kind of key space we're looking at. I've been up for about 55 hours now and starting to get a little too loopy for math. :P :-X
-
The key size alone doesn't define how computationally expensive it is to find the corresponding key. It is also the particular algorithm that is used. One algorithm might be twice as expensive to resolve for each key possibility for example.
True, true.
Also realize that adding a single bit to the key size increases the number of possible keys by a factor of two. A 512 bit key isn't 256 times more difficult to resolve than a 256 bit key. It is 2^256 times more difficult.
Right, as I pointed out, a 600 bit key is 2^88 times bigger than a 512 bit key.
-
Gentleman. Ladies. Both (if there are any out there who qualify as "both"). This thread and its participants represent the reasons I'm still around these forums (and with SorryMario it really does represent all the reasons).
You have my thanks for existing and for being here. I hope you all continue to do both.
-
Gentleman. Ladies. Both (if there are any out there who qualify as "both"). This thread and its participants represent the reasons I'm still around these forums (and with SorryMario it really does represent all the reasons).
You have my thanks for existing and for being here. I hope you all continue to do both.
This. This is why I made this thread: http://dkn255hz262ypmii.onion/index.php?topic=70907.0
It's actually really reassuring to see someone as respected in the community such as yourself to see what I was talking about.(and I hope I'm not just positively biased & subliminally ass-kissing you after you defended me in the meth review thread)
I really cannot think of any other forum or website(besides on that would be specifically made for the that particular topic) where it's just sort of taken for granted that everyone else is going to know how encryption works and what quantum computers are.
-
Thank you for the sentiment, but... I don't think I'd go that far, hah.
http://stackexchange.com is full of pretty decent sites, but you can't say "fuck, I'm too spun for this shit... I'll come back tomorrow," or something. And there's something about those who accept drugs and believe they should be legal that makes them more agreeable to me, but I admit this may just be my own wishful projection. Anyway, enough bumping for off-topic "thanks." :)
-
There are campaigns against vendors that require FE.
Should there be a campaign against vendors that are using weak PGP keys?
Is there really any reason to use less than 4096 bits in today's SR world?
I have come across a few vendors that are using very weak keys created online through igolder.com. It is all done server side. For a vendor to use that should be a crime.
It even worries me that most vendors appear to be running Windows systems.
-
keys created online through igolder.com.
Does anybody remember that old TV commercial "you can learn a lot from a dummy".
I have argued that we should hide our PGP versions to increase our anonymity, but now I'm reconsidering.
You can learn a lot about a vendor from their PGP version. Enough to stay away from them. :)
-
No. I don't think so. It's a shame that more people aren't aware of the ultimate facts pointed out in this thread, but to hold someone up to a standard "just incase" is a little bit... I don't know. You can't really go that far. But yeah, somebody should probably point out to buyers that an encryption key of, say, 512-bits isn't acceptable. Actually, I've gotten at least one vendor to switch. It's also hard for people to tell which key encrypts and which key decrypts though. For example:
pub:u:2048:1:314C3D3BE1177A52:1354199532:::u:::scESC:
fpr:::::::::8A792A304C2D1D799C196A55314C3D3BE1177A52:
uid:u::::1354199532::D95E9B30F7B580DF41900344009B698653A961D2::SelfSovereignty <SelfSovereignty@tormail.org>:
sub:u:2048:1:A7B2F0840239FC69:1354199532::::::e:
sub:u:4096:1:97D1891B5EB4507B:1357827971::::::e:
(nothing identifying in this output... right guys, lol?) My first public key is 2048-bit RSA, but it isn't used for encryption (there's no little "e" at the end of it). The 2 subkeys are used for encryption. I've seen vendors with 1024-bit DSA primary and 512-bit subkeys. Since DSA can't encrypt (only sign), it's pretty obvious which encryption key is used for messages.
This is all more than most people know or even want to know though. I think it's like everything else, really: it's regrettable that not everybody is fully educated on the topic, but we can't go around forcing people into things when they don't care or even want to know why.
-
Come to think of it, I've never seen your key, which begs the question, why do you hide it?
You should at least create a "public" key separate from the one you use to make purchases, which you distribute on the forum. Imagine SR goes down one day. Maybe we can find each other and reconvene somewhere else, but the only way we can prove our identity is through our keys.
-
keys created online through igolder.com.
Does anybody remember that old TV commercial "you can learn a lot from a dummy".
I have argued that we should hide our PGP versions to increase our anonymity, but now I'm reconsidering.
You can learn a lot about a vendor from their PGP version. Enough to stay away from them. :)
How do you think I manage to pick out the iGolder.com idiots and the Portable PGP cretins?
Through the Version: string, primarily... although as soon as you add their key to your ring, you can see just how strong it is (or not).
Nightcrawler <Nightcrawler@SR>
PGP-Key: 4096R/BBF7433B 2012-09-22
Key fingerprint = D870 C6AC CC6E 46B0 E0C7 3955 B8F1 D88E BBF7 433B
PGP Key: http://dkn255hz262ypmii.onion/index.php?topic=174.msg633090#msg633090
-
That is my second key. You've never seen it because I don't want my SR name linked to my forum name :P
I find it difficult to manage two totally separate identities (tried, fucked up and gave the wrong key to somebody once, stopped trying after that). But sure, why not. Here's the link: http://dkn255hz262ypmii.onion/index.php?topic=174.msg721302#msg721302
-
Not wanting to link identities is understandable. I keep a few separate identities myself. ;)
As for the confusion between keys...
Version: GnuPG v1.4.12 (GNU/Linux)
I don't know how you use PGP on Linux, but there's little room for confusion with command line gpg, especially in interactive mode. If you decrypt or verify, it selects the key for you. If you encrypt, it prompts you for the keys to use. The only source of confusion is during clear signing. For that...
Open ~/.gnupg/gpg.conf and find the line that says default-key. Pick the key you use most often and put the key ID there.
When you want to use the other one, use the --default-key argument.
gpg --default-key <my secret identity key> --clear-sign
-
To be honest, I don't recall exactly how or why I gave out the wrong key. I just remember doing it, sending the message, looking at it and saying "OMG FUCK NO," lol... I have no doubt it was a truly idiotic thing to do and totally my fault entirely, but I know myself and I know that I take drugs. Sometimes I make mistakes, and my entire life is setup to minimize those mistakes. When confronted with the multiple identities thing, I screwed up and couldn't think of a way to compensate for the same mistake, so I said "fuck it."
That's good info though, thanks :)
-
To be honest, I don't recall exactly how or why I gave out the wrong key. I just remember doing it, sending the message, looking at it and saying "OMG FUCK NO," lol... I have no doubt it was a truly idiotic thing to do and totally my fault entirely, but I know myself and I know that I take drugs. Sometimes I make mistakes, and my entire life is setup to minimize those mistakes. When confronted with the multiple identities thing, I screwed up and couldn't think of a way to compensate for the same mistake, so I said "fuck it."
That's good info though, thanks :)
The chances that your average person is going to have messaged you on both here and the marketplace is low to begin with. Even in the rare event that they did, it'd still be unlikely they'd be able to connect the two pieces of information. Even if they did, they probably wouldn't even think anything of it. And even if they did, they would probably not be motivated enough to "foil" you and your accounts. Even in the rare event that all those criteria were met, you still wouldn't suffer a huge loss. I mean, I know it's a matter of taking risks and making assumptions, but that still isn't the type of thing I'd lose sleep over.
And in a double feature post, I have some questions that are probably noobish(well, actually, only questions 1 &4) and may not even belong in this thread(but hey, my thread, my rules![Yes, I'm aware that's not how it works]).
1: When we're creating our key, how do we choose how many bits it is? If we don't know that information when we create the key, how would we learn that info? Does it say somewhere in the .asc file? but again, more importantly, how do we choose when making our key? (if it means anything, I'm using GNUPA)
2: When you're creating the key, why can't the generator simulate entropy by using random values?
3: If you make two keys with all the same information(passcode, email, etc), have the same processes running(which would easily be done by shutting off as much as you possibly can, even stuff like the file manager, using the task Task Manager) when you make them, have the same mouse movements (which could easily be done by putting the mouse in the far corner and entering your info in using only keystrokes) when you make them, will you end up with the same keys? (If GNU also uses different process states for making the key[process state being something like, "Key 1 was generated 32 seconds after Windows booted up and 14 seconds after GNU was started, but Key 2 was generated 44 seconds after Windows started up and 17 seconds after GNU started"], this could easily be circumvented by writing a script that would run immediately once the computer started. A script would also help solve the issue of killing processes and having the exact same keystrokes and mouse movements). If there is some sort of measure in place to prevent this from happening, what is it?
4: Why exactly is PGP important? The importance of it is beyond stressed. It just seems a bit paranoid to me, considering how secure Tor is. Is it primarily to prevent outside lines that could be listening in(which I'm pretty sure is fucking impossible with Tor) or is it only there if SR gets compromised(which may be more likely than the other, but is still relatively impossible)?
-
2. There are no truly random number generating algorithms. They're predictable. They will generate the same numbers in the same sequence until the end of time; you're more random than that, so they use you and your computer interaction as a source of randomness.
1. Import your own public key into gpg and look at it. Also, any program that doesn't even ask how many bits you want to use is either written by very good people who know to use big ones, or very bad people that I wouldn't trust.
3. I don't know how the program uses your computer interaction as a source of entropy, but I suspect there will be subtle differences. Besides, pseudorandom number generation algorithms generate enormous ranges of numbers and usually your computer keeps its place between boots (that's "seeding" the entropy).
4. It's to protect if SR is compromised and your order is still processing. It's also to protect against the vendor getting pinched and the law using his account. If your address is plaintext, well, you're their next person of interest (or they'll at least inform your local PD I should think). Basically, it's just a risk that isn't necessary. But it's not so that nobody can listen in. You're right, Tor protects against that (but only WITHIN the network, not outside it).
-
There *are* some negative aspects of PGP, however unlikely.
If your system and the vendor's gets compromised, it may worsen the case against you that you were the one that made the order.
-
There *are* some negative aspects of PGP, however unlikely.
If your system and the vendor's gets compromised, it may worsen the case against you that you were the one that made the order.
I'm not sure I agree. I mean I think the prosecution could present it in court as evidence, but... you didn't use your own key to encrypt the address. And I mean, if you get caught for drugs being mailed to you, obviously SOMEONE mailed them to you. Whoever did that encrypted your address and bought them on Silk Road, apparently.
Again, at that point it's kind of... well. Juries and all that. But until that point, I don't think there's any downside.
-
"but... you didn't use your own key to encrypt the address."
Correct, it would only be an issue if you corresponded back and forth with the seller or signed your messages. Parties would also have had to store messages. For the most part, PGP protects you.
When you said: "I've seen vendors with 1024-bit DSA primary and 512-bit subkeys.", does this mean that the raw length of a vendor's public key block doesn't indicate the number of bits of encryption it has?
-
There *are* some negative aspects of PGP, however unlikely.
If your system and the vendor's gets compromised, it may worsen the case against you that you were the one that made the order.
Obviously, if your computer is compromised, you're fucked. However, if the vendor is compromised...
If messages to the vendor are not also encrypted to yourself, there's no proof you encrypted the message.
If they are encrypted to yourself...
gpg --throw-keyid
That will remove the key id from the message. All the attacker will see is:
gpg: encrypted with RSA key, ID 00000000
-
Well it's abundantly clear why PGP should be used, as far as sellers are concerned.
But when buyers send their info, why should they encrypt it? LE doesn't care about buyers. LE cares about cracking down on sellers.
-
2. There are no truly random number generating algorithms. They're predictable. They will generate the same numbers in the same sequence until the end of time; you're more random than that, so they use you and your computer interaction as a source of randomness.
Couldn't an irrational number such as Pi be somehow utilized? and if that's the case, how do they attain random values in stuff like lotteries or videogames?
Thinking about it now, I can't possibly begin to imagine how a random number/tumbler would work, in terms of coding and algorithms. I guess computers being perfectly logical can be a double edged sword.
1. Import your own public key into gpg and look at it. Also, any program that doesn't even ask how many bits you want to use is either written by very good people who know to use big ones, or very bad people that I wouldn't trust.
Well does anyone here know how many bits GNUPA is? I assume it's secure, considering how popular it's.
3. I don't know how the program uses your computer interaction as a source of entropy, but I suspect there will be subtle differences. Besides, pseudorandom number generation algorithms generate enormous ranges of numbers and usually your computer keeps its place between boots (that's "seeding" the entropy).
Would it possible for my listed scenario to happen on the theoretical level?
-
2. Well pi isn't random either, I mean those are the same digits in the same order until the end of time as well. I see what you're thinking, but... no, I doubt it. I mean anything's possible and I don't know everything obviously, but it isn't random to begin with, and I can't think of any way that you'd actually get randomness out of something so supremely ordered...
Lotteries don't use pseudorandom number generators, they do stuff like use balls that bounce around -- that may or may not actually be predictable. I mean at the particle (quantum) level, yes, it appears to be the only true instance of randomness in all the universe. But when you add up all that randomness from the particles interacting together to be a huge object like a ping pong ball, not everything is possible, only certain movements. Actually what's really, really cool (well I think it is, lol) is that quantum mechanical formulas for large objects -- while immensely complex -- actually reduce to Newton's formulas of motion. For large objects, mind you. Brilliant man, that Newton :)
Video games are predictable. But again, the range of output from a pseudorandom number generator is enormous. I mean like, I think the Mersenne Twister algorithm could produce 10 numbers a second for years & years & years before it actually wraps around and starts repeating them. And computers save their place, basically, so that they don't just start over. Or they just use the current number of nanoseconds to seed the algorithm instead of carrying it over. That's in practice pretty damn good, but it's still 100% predictable. I mean when I say it's "predictable," it would always happen the same exact way if events were the same, but you're not going to have any luck predicting it practically unless you watch the output for years until you eventually know exactly where you are in the string of output produced & can then start predicting stuff. That's just not practical, even if it is possible technically. They just look random to us, but really they are not actually random at all is the point.
I don't know why people say computers are logical. I mean if you study computer engineering and logic gates and all that -- well they're even called "logic gates." But that doesn't make a computer logical, it just... no, I'm going to cut myself off there. I see it differently, that's all. I don't want to get too personal here though, I mean I admit to a lot of stuff on these boards I don't want tied to me in person, ya know.
3. No, not really, because there's also a component it gets from a pseudorandom number generator (I mean even beyond what you see). Try exporting your public key twice, then compare them. They'll be different (and yet the same! lol)
-
I don't know why people say computers are logical. I mean if you study computer engineering and logic gates and all that -- well they're even called "logic gates." But that doesn't make a computer logical, it just... no, I'm going to cut myself off there. I see it differently, that's all. I don't want to get too personal here though, I mean I admit to a lot of stuff on these boards I don't want tied to me in person, ya know.
Well every single time, (if not programmed to also factor in some other variable), one certain input will always result in the same output. and just look at how easy it is for a human to concoct a random number, vs a computer. Computers compute. If they weren't perfectly logical, they would cease to be called computers.
and now I'm very much anticipating learning whatever knowledge will be contained in your counter argument. and I'd just like to point out that that last sentence was paraphrasing my Computer Science teacher with over 45 years of experience in the field. (even if 45 years experience in the field isn't impressive, he held one of the top 10 most important positions for 2 different Fortune 300 companies)
-
No, actually... they won't produce the same output every single time. They only do that if they're functioning as intended. Take that away, and, well... they either do nothing of use or nothing predictable, anyway. Yet they still do stuff. I mean they're functioning... sort of.
I've met many, many people who think like your CS teacher. And I really have no argument, it's really just a matter of perspective. Think of it however you like. I just said that I don't understand why people think of them as cold, logical, and always doing as they're told. I see them differently, that's all.
-
Right. But how could you possibly write an algorithm to create such a degree of unpredictability? The malfunction would lie with the hardware, and that particular "computer"(quotation marks are because I don't think it'd be considered a computer at this point) would then be a different computer than every single other functional computer of that model. But that's of course assuming that such malfunction can only occur on the hardware side of things.
Just look at the human brain. It's just a biological machine. It's mechanism of abstract thought seems to be the ability to create algorithms, the ability to create thoughts that don't abide by logic, and the ability the create random values. Once we figure out an algorithm that allows computers to do the same(if such a thing is even possible), what would be different? If you made a machine with the same architecture as the human brain(I don't mean arranging binary architecture into something kind of like the brain, but instead similar architecture at the lowest level), nothing would change. Hell, maybe even quantum computers will be able to produce abstract thought.
-
Actually, quantum computers won't be able to do anything that regular computers can't do.
I'm not comfortable responding to the rest of your post, frankly. I just see it differently, I don't know what else to tell you. But you're not really wrong I guess.
-
"but... you didn't use your own key to encrypt the address."
Correct, it would only be an issue if you corresponded back and forth with the seller or signed your messages. Parties would also have had to store messages. For the most part, PGP protects you.
When you said: "I've seen vendors with 1024-bit DSA primary and 512-bit subkeys.", does this mean that the raw length of a vendor's public key block doesn't indicate the number of bits of encryption it has?
The 1024-bit DSA key is for signing -- the DSA stands for Digital Signing Algorithm. The 512-bit Elgamal encryption sub-key is for encryption. Given that you have two keys, each can be of differing sizes. According to the NIST standard, DSA keys should be a maximum of 1024-bits. Extensions to that standard have been implemented, raisng the DSA keys to 2048 or even 3072-bits. Elgamal encryption keys can be as large as 4096-bits.
Even when using RSA keypairs, it is entirely possible to have keys of different sizes. It is entirely possible to have an RSA signing key of 2048-bits, while the encryption sub-key is 4096-bits.
Nightcrawler <Nightcrawler@SR>
PGP-Key: 4096R/BBF7433B 2012-09-22
Key fingerprint = D870 C6AC CC6E 46B0 E0C7 3955 B8F1 D88E BBF7 433B
PGP Key: http://dkn255hz262ypmii.onion/index.php?topic=174.msg633090#msg633090
-
Well it's abundantly clear why PGP should be used, as far as sellers are concerned.
But when buyers send their info, why should they encrypt it? LE doesn't care about buyers. LE cares about cracking down on sellers.
Pretty much you have this backwards. Vendors have much less motivation to use GPG than customers do, it isn't like they are sending addresses in plaintext.
-
Pound randomly on your keyboard for a while and then hit enter:
okay here
...655785064......3303705127......3907849434......3131393684......3342769854......1858316424......468638835......2481738895...
Pound randomly on your keyboard for a while and then hit enter:
iijgierwjgiojgioewjgt34289ju84jg9j89gt489gj4389gj348gjerujgeru342
...546624317......3687457083......3870012936......2534952621......31580680......2384274536......259946410......1386766679...
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <openssl/sha.h>
int main()
{
printf("Pound randomly on your keyboard for a while and then hit enter: \n\n");
char* input = calloc(1, 1000);
fgets(input, 1000, stdin);
char* hash = calloc(1, 32);
SHA256((const char*)input, 1000, hash);
int x = 32 / sizeof(unsigned int*);
while(x-- > 0){
printf("...%u...", *(unsigned int*)&hash[sizeof(unsigned int) * x]);
}
}
-
Although we're getting very off topic, this 1999 example illustrates some of the hazards in generating sufficiently random numbers with a computer:
from: http://www.ibm.com/developerworks/library/s-playing/
How to cheat in online gambling
The Software Security Group at Reliable Software Technologies (RST) (see Resources) recently discovered a serious flaw in the implementation of Texas Hold 'em Poker that is distributed by ASF Software, Inc. (see Resources). The exploit allows a cheating player to calculate the exact deck being used for each hand in real time. That means a player using the exploit knows the cards in every opponent's hand as well as the cards that will make up the flop (cards placed face up on the table after rounds of betting). A cheater can "know when to hold 'em and know when to fold 'em" every time. A malicious attacker could use the exploit to bilk innocent players of actual money without ever being caught.
The flaw exists in the card shuffling algorithm used to generate each deck. Ironically, the code was publicly displayed at http://www.planetpoker.com/ppfaq.htm with the idea of showing how fair the game is to interested players (the page has since been taken down). In the code, a call to randomize() is included to produce a random deck before each deck is generated. The implementation, built with Delphi 4 (a Pascal IDE), seeds the random number generator with the number of milliseconds since midnight, according to the system clock. That means the output of the random number generator is easily predicted. As we've discussed, a predictable random number generator is a very serious security problem.
The shuffling algorithm used in the ASF software always starts with an ordered deck of cards, and then generates a sequence of random numbers used to reorder the deck. In a real deck of cards, there are 52! (approximately 2226) possible unique shuffles. Recall that the seed for a 32-bit random number generator must be a 32-bit number, meaning that there are just over 4 billion possible seeds. Since the deck is reinitialized and the generator reseeded before each shuffle, only 4 billion possible shuffles can result from this algorithm. Four billion possible shuffles is alarmingly less than 52!.
To make matters worse, the flawed algorithm chooses the seed for the random number generator using the Pascal function Randomize(). This particular Randomize() function chooses a seed based on the number of milliseconds since midnight. There are a mere 86,400,000 milliseconds in a day. Since this number was being used as the seed for the random number generator, the number of possible decks now reduces to 86,400,000. Eighty-six million is alarmingly less than four billion. But that's not all. It gets worse.
The system clock seed gave Reliable Software Technologies an idea that reduced the number of possible shuffles even further. By synchronizing their program with the system clock on the server generating the pseudo-random number, they are able to reduce the number of possible combinations down to a number on the order of 200,000 possibilities. After that move, the system is broken, since searching through this tiny set of shuffles is trivial and can be done on a PC in real time.
The RST-developed tool to exploit this vulnerability requires five cards from the deck to be known. Based on the five known cards, the program searches through the few hundred thousand possible shuffles and deduces which one is a perfect match. In the case of Texas Hold 'em Poker, this means the program takes as input the two cards that the cheating player is dealt, plus the first three community cards that are dealt face up (the flop). These five cards are known after the first of four rounds of betting, and are enough to determine (in real time, during play) the exact shuffle. The figure shows the graphical interface that RST slapped on its gambling exploit. The Site Parameters box in the upper left is used to synchronize the clocks. The Game Parameters box in the upper right is used to enter the five cards and initiate the search. The figure is a screen shot taken after all cards have been determined by the program. The cheating attacker knows who holds what cards, what the rest of the flop looks like, and who is going to win in advance.
The interface for Reliable Software Technology's Internet poker exploit
Once the program knows the five cards, it generates shuffles until it discovers the shuffle that contains the five known cards in the proper order. Since the Randomize() function is based on the server's system time, it is not very difficult to guess a starting seed with a reasonable degree of accuracy. (The closer you get, the fewer possible shuffles you have to look through.) Here's the kicker though: After finding a correct seed once, it is possible to synchronize the exploit program with the server to within a few seconds. This post facto synchronization allows the program to determine the seed being used by the random number generator, and to identify the shuffle being used during all future games in under one second!
Technical details aside, this exploit garnered spectacular press coverage. The coverage emphasizes the human side of any such discovery. Visit the RST Web site (listed in Resources) for the original press release, the CNN video clip, and a New York Times story.
-
char* input = calloc(1, 1000);
fgets(input, 1000, stdin);
char* hash = calloc(1, 32);
SHA256((const char*)input, 1000, hash);
Since SHA256 distills randomness, we know that hash points to 32 bytes with as much randomness in it as in the initial string the user types, which can be up to 1000 bytes. Since it is generally safe to assume that every byte the user types has one bit of entropy in it, if the user hits 256 keys before hitting enter, then hash points to 256 bits of randomness.
int x = 32 / sizeof(unsigned int*);
while(x-- > 0){
printf("...%u...", *(unsigned int*)&hash[sizeof(unsigned int) * x]);
}
this goes through the output hash 4 bytes at a time and prints the 4 bytes as an unsigned int. Since the hash value is 256 bits of randomness, each of the printed numbers are random and up to 32 bits. If you want to make more than sha256 bytesize / sizeof(unsigned int) random numbers with the same seed material you would do something like this:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <openssl/sha.h>
#define sha256_bytesize 32
#define input_bytesize_max 1000
int main()
{
printf("Pound randomly on your keyboard for a while and then hit enter: \n\n");
char* input = calloc(1, input_bytesize_max);
fgets(input, input_bytesize_max, stdin);
char* hash = calloc(1, sha256_bytesize);
SHA256((const char*)input, input_bytesize_max, hash);
int numbers_to_generate = 1024; // must be evenly divisible by 8
int cycles = numbers_to_generate / (sha256_bytesize / sizeof(unsigned int));
int x;
for(x = sha256_bytesize / sizeof(unsigned int); cycles; cycles--){
while(x-- > 0){
printf("%u, ", *(unsigned int*)&hash[sizeof(unsigned int) * x]);
}
SHA256_CTX digest_ctx;
SHA256_Init(&digest_ctx);
SHA256_Update(&digest_ctx, input, input_bytesize_max);
SHA256_Update(&digest_ctx, hash, sha256_bytesize);
SHA256_Final((unsigned char*)hash, &digest_ctx);
x = sha256_bytesize / sizeof(unsigned int);
}
return 1;
}
note that the original input is hashed to determine the original hash, and then from there the input is hashed together with the previous hash in order to determine the next hash. Without knowing the original input, which is the seed, an attacker can not determine what numbers will come next by knowing any of the given numbers.
Pound randomly on your keyboard for a while and then hit enter:
ewofkpewofkfkfkewpfkpoew
1131825061, 3688026824, 1231966063, 3835540840, 3895683430, 100125131, 2080584810, 1174908134, 3434929624, 3875039201, 3071522454, 4143845028, 3458178688, 1989285470, 1125142825, 676834196, 3650598165, 3459411485, 1406189030, 1376089312, 1399940066, 2028894875, 2571302588, 1895924890, 2177742134, 3327946134, 2223606966, 1002549878, 3489905312, 3744919418, 1058878650, 866029914, 395102763, 2740964949, 1034838232, 2554586916, 2048139009, 955301508, 2762861201, 1015224392, 700357896, 3078575593, 2610097327, 4011768463, 3911089829, 976734916, 1770142116, 913487976, 4126269859, 1586109218, 2362801860, 632276841, 4008883232, 611869321, 3564339646, 849225957, 2368641573, 730657830, 3915227568, 1905431881, 943347584, 2537902018, 925828280, 2416726404, 2085729931, 2839515556, 2840179316, 1041815396, 1071756885, 2971405229, 4288722269, 724981196, 2501557562, 3580583715, 3407327544, 2673202105, 1476378478, 522994926, 2423416914, 783203073, 3496945928, 1877228586, 2240303800, 1139669603, 1158863945, 3753521370, 4096674841, 2876740655, 4007404669, 3562863030, 2596617445, 2445288485, 3233054462, 1247761355, 3704164861, 3170364380, 3836729434, 2725146589, 4147929128, 3087740256, 1936047366, 4253737861, 252338802, 2218407517, 4003946582, 2324847090, 3082065373, 2938476361, 1855091543, 3181203504, 278679784, 3831819330, 3726952201, 4230906935, 1567772450, 2353106759, 2017912504, 2898707071, 927712183, 2748683864, 2034867947, 2286301538, 37316200, 146697774, 419575480, 3023900409, 1554208096, 2255379805, 2129178774, 1832306274, 3709693727, 1158945100, 3885577929, 108382223, 1681468813, 2222855059, 3538985238, 1781661, 325685693, 2574073320, 3682393197, 1935375562, 1824054295, 4255299601, 1374818890, 2432445517, 3320675812, 58168969, 1687243179, 2972579585, 41892015, 1131564771, 453564015, 2669395313, 543130798, 2944727200, 195685940, 1296584579, 3843488452, 184299526, 4130237899, 801814728, 1792487551, 648181115, 23257902, 571372193, 1001157529, 2791336529, 2971566889, 923682043, 3506482788, 3747088898, 900758611, 2709379818, 3266513084, 2020571485, 4224204788, 464648919, 210190141, 86858892, 3893707481, 343477454, 393472892, 2023636984, 1657329957, 3653942738, 798089328, 2934929443, 3168866288, 2010130405, 1132391558, 2846745634, 3641298431, 45068674, 4259134821, 3964381122, 1921911720, 3920526807, 1134800417, 1297631980, 202942715, 279485134, 311081715, 773855100, 3453975190, 769087683, 2604270473, 2635005511, 540049818, 3437818205, 3010282740, 1153327421, 2182921009, 3661448462, 1122928384, 3834425893, 1399432444, 2712126042, 3164621221, 3069351572, 281146602, 4128225209, 1698301003, 1169935036, 4141370673, 1338751159, 1468291099, 476242480, 4038722735, 456455532, 1873586460, 1066800148, 730158053, 439367008, 701573547, 2011690664, 3069062954, 504176327, 1949327869, 990165602, 2009068904, 1378914809, 2838828185, 3202093389, 1503479913, 1067524315, 3924953662, 2361424352, 1203789083, 278972846, 495474496, 3147856700, 1419929674, 2005992688, 298715854, 1230067326, 1820965332, 874744817, 1313337212, 2301344273, 2291389508, 3379599601, 2494210340, 4179941271, 2947071300, 1410664041, 852214619, 2091126356, 2340712558, 3371302046, 1638197237, 1988377879, 2843068184, 839910806, 3292734381, 2810624105, 1419489147, 3922079063, 1897039338, 575954582, 1980164931, 3019008623, 3334616146, 750479126, 1215510368, 574716984, 4156439648, 2672883897, 783651620, 995147558, 199794639, 1267660435, 2980399644, 1074630743, 3271238980, 2755642229, 409873928, 4151378132, 1711776621, 2668995087, 3078689802, 459755588, 1516623802, 3797715371, 2788089906, 2683535398, 2530337901, 4239447367, 3152018247, 911951204, 2159368386, 1120897222, 2935288821, 207926990, 1782127795, 3394933846, 2979939893, 3622123052, 2034789030, 2679150463, 2897795785, 87475486, 3994960773, 4131982448, 1884737313, 3504562954, 2560447894, 4112690194, 3318861311, 976451147, 1011861312, 2666536440, 3310435290, 3818496971, 2529605336, 1781567681, 1071862382, 709475180, 1393781558, 1927649894, 3106591565, 4048318678, 457889737, 4261246113, 2301456581, 1978726878, 40467572, 2678448096, 3940009970, 4152892592, 1195989556, 1490238979, 2933864626, 916963898, 1719008729, 4188873015, 1097339721, 2683727951, 2928864981, 1339696191, 3235732567, 2372639035, 1255613943, 2222450843, 3596715244, 1952805296, 3149719875, 3778488406, 3053723161, 894411363, 2311314654, 3342993995, 3788124544, 1764066626, 514424945, 135875307, 4200939669, 3852912621, 586166270, 1886516394, 592720731, 3915707150, 954526429, 4128085329, 3707671186, 2349835295, 1648919880, 2668617841, 3644165730, 952609991, 2358545089, 3450973756, 4006885596, 3136060004, 1000265955, 3728269305, 1728174558, 1947551414, 2025618422, 2174200413, 383732023, 1141303053, 2572426234, 3312726418, 1610926562, 2315720138, 2246548015, 3725991361, 3247741733, 807584781, 2973704356, 4046820802, 4276638001, 2502534087, 1987390684, 1024248478, 816451332, 2837656358, 1620496390, 1206616750, 4088876987, 2538011675, 1089443033, 4130105975, 1333065656, 597485786, 2970368116, 3379020716, 3693217128, 101700833, 2880003371, 3363899816, 2755469039, 572839881, 3713233411, 2799793260, 644708209, 729858670, 1023928487, 904411366, 1368678657, 1415153704, 1263528891, 2986888444, 412525905, 3776776372, 2007618083, 1023488133, 1360396902, 3085551208, 368780118, 472271455, 3368210622, 1486467650, 748038476, 2903780231, 926337708, 1913556323, 1769239640, 467775424, 884993483, 1880753682, 2678255172, 3115835871, 279085005, 1854137915, 3825887488, 2880145003, 4201376872, 996139613, 412950211, 3007160973, 2001193329, 1676883123, 164652730, 270667872, 2469936608, 656766275, 2225654456, 1466172415, 97558823, 3968500559, 2331929664, 387472071, 2776938806, 3133954, 3513609806, 1395751084, 3930376128, 58770381, 3543810575, 1555294880, 626559765, 3588798871, 620328231, 1868112306, 2065875284, 3024830291, 3516001110, 2065367968, 527997395, 699989490, 2122121007, 2474587956, 4264263019, 3108597240, 3716893556, 355206280, 4104366162, 1589387964, 991634136, 3258618709, 1939879522, 3943776049, 2310155274, 3394254311, 3058600296, 1694289090, 1350080016, 798367306, 4198928713, 3542558036, 3811717929, 438169574, 1624691559, 260745736, 1652629032, 1652265240, 713870369, 2868834775, 1451803791, 832979628, 2445086111, 3115520481, 1233633660, 2193585414, 2356264214, 1433628448, 1473526895, 1383053461, 3742702439, 309498954, 1927510607, 901502325, 2451078913, 1870117541, 1391022224, 1352089645, 2199761074, 3512828386, 4212129343, 3604566834, 2594348588, 3304255545, 2979465200, 3146868888, 2093601261, 601219291, 3154375867, 340827160, 138986795, 1611448895, 1830093050, 2356172326, 982079876, 2288335605, 1113125225, 3677868545, 3466453176, 1361204694, 159400349, 2677765674, 605714313, 3978227473, 3910292465, 4269661722, 159477487, 2665247188, 735150667, 789962098, 3892613157, 3630297165, 1387960633, 3483225739, 1209851284, 2356254422, 3386099698, 2037875474, 3763486769, 1984654262, 2221621758, 724779491, 3819447583, 1271605392, 4265058615, 43704700, 1906590300, 3537098683, 4190771444, 1779648299, 930942468, 2150555788, 3213078468, 2910886634, 3148695195, 3052957441, 573212002, 2258351227, 2913384306, 1632377868, 455885593, 4246220245, 2311233557, 3750072750, 3228307058, 825875749, 3000233838, 1746868973, 1168865672, 3348311454, 244319473, 2812813011, 22996684, 1635003376, 2392205837, 1382560930, 139888668, 2705243006, 3074408187, 2828550378, 3542558275, 43575779, 3385210032, 4091335036, 4182436998, 4159234675, 1208316006, 1844246200, 2535141270, 1101221750, 2367125474, 3529762512, 3563098040, 1459017302, 3304256957, 2367191695, 796560594, 958022359, 1170073188, 3897246010, 3560902677, 3478910850, 271093843, 547051433, 2236278945, 1539185203, 1880996255, 1425516773, 3056780989, 2836182936, 1798746482, 1333812486, 621213866, 2029554771, 4133584493, 1382812499, 3361468537, 3109562757, 3227199462, 3302729769, 1918794384, 1756969763, 1124566920, 1788140616, 2707459645, 4010666223, 2849734079, 4095286962, 1423376786, 2986606412, 3431489129, 565983202, 296383102, 3730050922, 242937688, 1386136462, 2070118049, 2700155719, 780737552, 3834461315, 1234973494, 3639979156, 281512671, 686339895, 3117180650, 3631078139, 3136793149, 2224183609, 1553157158, 495427809, 1440134354, 1897669267, 1822898799, 3667308203, 3550373038, 1806618457, 824096499, 916518988, 1375402600, 489583658, 34986332, 832626016, 1057095869, 399133961, 98139021, 4132711966, 2474824075, 2141450054, 806198962, 3553179879, 3810740226, 140069611, 3032816587, 3858261923, 226975308, 309794698, 1849459980, 774524394, 2384353573, 2605943766, 2789989015, 3487277111, 409038223, 3972173437, 1183545483, 3833899189, 868290187, 2129739952, 2735405174, 3578844194, 199772641, 476305441, 1945207422, 1047871028, 1772768521, 3259156476, 488663387, 3740319219, 3047318117, 3226812043, 2563434464, 2461664186, 2239949802, 1066519062, 994547509, 3869272, 3626920295, 1614634858, 3025445964, 485655704, 4187634557, 1059086460, 1391515319, 584093806, 352238135, 1466597256, 3319545112, 3548364901, 190114565, 3928573893, 3750021476, 3713931069, 1783831176, 3255583976, 2096470220, 4012412121, 524861224, 3854831713, 214360217, 1847763838, 3780377675, 2374201239, 942925124, 2063219874, 3346760477, 2467139008, 1125799132, 1094890806, 533518308, 2301805316, 558520212, 1628896753, 2966209252, 3214760426, 4213109246, 12663941, 4199851087, 2539889474, 946250346, 2704244124, 3411492275, 3490381440, 1825684, 1653354648, 1747579554, 3701169410, 1727418872, 429020278, 3450866749, 465004734, 1861867216, 1866874331, 3269910787, 3871402315, 2683416023, 2549787181, 761291181, 2948598568, 1666041973, 2755207629, 617441615, 122867073, 2122181977, 3584318163, 1004458475, 2765029722, 3999002898, 1633545143, 1912842402, 1843318491, 2814139584, 2201700300, 1618905503, 1942976337, 3656922810, 526725357, 3701480012, 996428986, 431055458, 2872103545, 3668284300, 826763806, 3587639843, 3652337444, 1289805244, 3762961529, 39101766, 1521828428, 1896940177, 3652712873, 339425432, 71528270, 3243575421, 994706306, 2607244426, 832707414, 1875448807, 2776470608, 4237012680, 183296027, 1766117880, 3589481863, 3091583589, 1379593361, 945065049, 3938551910, 2006427855, 892858433, 2035054014, 2134824116, 2324044766, 114634662, 2642336105, 3646394982, 1401013143, 1380120844, 3903196376, 824047721, 1629644109, 1970315500, 4040512079, 1128691294, 1106628811, 3246874665, 228991640, 3042266555, 994697508, 1978908948, 6659385, 2379273963, 317913210, 4125798411, 2968397034, 2847561279, 917989675, 768034685, 3914209855, 323687538, 126724290, 3243338145, 1211515296, 3025336532, 1607338720, 3751097049, 3041455699, 841715105, 2105657049, 466048154, 1077950036, 1425994784, 1181560686, 3819897593, 2944658783, 17704962, 4189717388, 300850250, 379234294, 3316845498, 588433034, 1334035997, 1405006497, 1777187009, 2148083835, 3474559801, 4256439249, 15352263, 2331132546, 2984307187, 847283779, 440435752, 134034903, 3177939388, 2429067152, 394863738, 182610078, 1268353682, 3122459933, 3342181794, 3533338887, 2486559530, 1989024990, 2947911781, 1333161597, 3698190411, 1287530203, 1575871295, 1230688809, 3016327265, 2969566583, 1918621877, 663201141, 3217233565, 865654647, 3725662001, 562493874, 3532567360, 3055374410, 196874216, 570726472, 2697994287, 2971268675, 3698284644, 2172308107, 167078127, 3271576499, 3017836962, 3680715643, 3057619064, 3396693870, 4112478828, 1581249777, 1681796512, 2250344043, 3241122766, 2547918020, 144619826, 2342225903, 2649173592, 1274740361, 2577013794, 188619481, 2899313883, 3376424600, 2113243967, 1662241018, 3390798238, 1539159943, 2054257230, 3321793510, 2134818401, 478547292, 1937269648, 2176201861, 1232911078, 1730672703, 517486047, 648971569, 366218610, 1742763735, 2803068129, 4164450963, 3641163288, 1969974907, 3726459121, 2146936566, 668283836, 1141288765, 1781560955, 2847764909, 1123447968, 2195479446, 4227370755, 247087828, 3556321491, 4027490605, 1392301047, 2139104139, 2837763224, 4256764867, 1366461607, 73316475, 2533963066, 2638526465, 47518757
-
Although we're getting very off topic, this 1999 example illustrates some of the hazards in generating sufficiently random numbers with a computer:
from: http://www.ibm.com/developerworks/library/s-playing/
How to cheat in online gambling
The Software Security Group at Reliable Software Technologies (RST) (see Resources) recently discovered a serious flaw in the implementation of Texas Hold 'em Poker that is distributed by ASF Software, Inc. (see Resources). The exploit allows a cheating player to calculate the exact deck being used for each hand in real time. That means a player using the exploit knows the cards in every opponent's hand as well as the cards that will make up the flop (cards placed face up on the table after rounds of betting). A cheater can "know when to hold 'em and know when to fold 'em" every time. A malicious attacker could use the exploit to bilk innocent players of actual money without ever being caught.
The flaw exists in the card shuffling algorithm used to generate each deck. Ironically, the code was publicly displayed at http://www.planetpoker.com/ppfaq.htm with the idea of showing how fair the game is to interested players (the page has since been taken down). In the code, a call to randomize() is included to produce a random deck before each deck is generated. The implementation, built with Delphi 4 (a Pascal IDE), seeds the random number generator with the number of milliseconds since midnight, according to the system clock. That means the output of the random number generator is easily predicted. As we've discussed, a predictable random number generator is a very serious security problem.
The shuffling algorithm used in the ASF software always starts with an ordered deck of cards, and then generates a sequence of random numbers used to reorder the deck. In a real deck of cards, there are 52! (approximately 2226) possible unique shuffles. Recall that the seed for a 32-bit random number generator must be a 32-bit number, meaning that there are just over 4 billion possible seeds. Since the deck is reinitialized and the generator reseeded before each shuffle, only 4 billion possible shuffles can result from this algorithm. Four billion possible shuffles is alarmingly less than 52!.
To make matters worse, the flawed algorithm chooses the seed for the random number generator using the Pascal function Randomize(). This particular Randomize() function chooses a seed based on the number of milliseconds since midnight. There are a mere 86,400,000 milliseconds in a day. Since this number was being used as the seed for the random number generator, the number of possible decks now reduces to 86,400,000. Eighty-six million is alarmingly less than four billion. But that's not all. It gets worse.
The system clock seed gave Reliable Software Technologies an idea that reduced the number of possible shuffles even further. By synchronizing their program with the system clock on the server generating the pseudo-random number, they are able to reduce the number of possible combinations down to a number on the order of 200,000 possibilities. After that move, the system is broken, since searching through this tiny set of shuffles is trivial and can be done on a PC in real time.
The RST-developed tool to exploit this vulnerability requires five cards from the deck to be known. Based on the five known cards, the program searches through the few hundred thousand possible shuffles and deduces which one is a perfect match. In the case of Texas Hold 'em Poker, this means the program takes as input the two cards that the cheating player is dealt, plus the first three community cards that are dealt face up (the flop). These five cards are known after the first of four rounds of betting, and are enough to determine (in real time, during play) the exact shuffle. The figure shows the graphical interface that RST slapped on its gambling exploit. The Site Parameters box in the upper left is used to synchronize the clocks. The Game Parameters box in the upper right is used to enter the five cards and initiate the search. The figure is a screen shot taken after all cards have been determined by the program. The cheating attacker knows who holds what cards, what the rest of the flop looks like, and who is going to win in advance.
The interface for Reliable Software Technology's Internet poker exploit
Once the program knows the five cards, it generates shuffles until it discovers the shuffle that contains the five known cards in the proper order. Since the Randomize() function is based on the server's system time, it is not very difficult to guess a starting seed with a reasonable degree of accuracy. (The closer you get, the fewer possible shuffles you have to look through.) Here's the kicker though: After finding a correct seed once, it is possible to synchronize the exploit program with the server to within a few seconds. This post facto synchronization allows the program to determine the seed being used by the random number generator, and to identify the shuffle being used during all future games in under one second!
Technical details aside, this exploit garnered spectacular press coverage. The coverage emphasizes the human side of any such discovery. Visit the RST Web site (listed in Resources) for the original press release, the CNN video clip, and a New York Times story.
Wow that is a pretty stupid mistake to make. I figured they forgot to remove their mod bias or something. One thing you do with big random numbers is use them to get smaller random numbers. For example, if you get the number 1000 it isn't so helpful by itself in telling you which position in a deck a given card should be in. So what you do is essentially 1000 mod 52 = 12
but imagine that you want a random number from 0 to 2 but your RNG gives you numbers up to 4. One thing you could do is rng_output mod highest_number_desired++ , which is guaranteed to give you a number that is no greater than the highest number you want. But:
0 mod 3 = 0
1 mod 3 = 1
2 mod 3 = 2
3 mod 3 = 0
4 mod 3 = 1
now you are more likely to select 0 or 1 than 2, even if the initial larger number is itself random. This is called mod bias, and if measures are not taken against it, it can be a critical security vulnerability in a system that generates smaller numbers from a range using a bigger random number as the initial seed.
-
I don't know how you use PGP on Linux, but there's little room for confusion with command line gpg, especially in interactive mode.
The only bad part about using a command line it means the plaintext message has to be saved on a file somewhere. Better to use a GUI front-end that let's you encrypt/decrypt text without it being in a saved file.
Nightcrawler turned me onto GPG4USB - it's the best crypto program I've used, but unfortunately no matter what I do I can't get it to run on Ubuntu 12.04 (works great in Windows though). Maybe give it a try and see if it works on your linux distro.
In Ubuntu after a little searching I finally found a front-end called "KGPG" that works great (it wouldn't work at all until I discovered a one little change I had to make in terminal) . It's got a feature that lets you do the crypto on copied text while it's in the computer's clipboard memory, so when you paste it's encrypted (it also works in reverse for decrypting). If that sounds a little too disembodied for you, it's also got a regular text editor (confusingly also called a "clipboard") that you can do the encryption/decryption operations on.
-
The only bad part about using a command line it means the plaintext message has to be saved on a file somewhere.
No it doesn't. Type gpg -e and hit enter. It will prompt you for a recipient. Hit enter twice after the last recipient and you get a blinking cursor where you can type your message. Hit ctrl+d and it encrypts it in the terminal. Nothing is saved to disk. I would go mad if I had to save every message in PGP Club to a file. :)
-
The number of primes less than any number, n, is approximated by the formula n/ln(n)
So between 0 and 2^127, there are about 1,932,770,406,530,700,000,000,000,000,000,000,000 or ~2^120 that are prime.
(it comes out to slightly more than 0.01%)
But it is not 0 ... 2^127 in practice, because you know that two 8 bit primes are not going to be multiplied into a 128 bit composite number. Although technically the key space is all primes between 0 and 127 bits, in practice I was told the key space is closer to the number of primes that are 127 bits.
That's an excellent point! 8)
I'll have to look into this some more when my brain is working again to see what kind of key space we're looking at. I've been up for about 55 hours now and starting to get a little too loopy for math. :P :-X
Ok, I think I've got the answer to this. First, the best primes are those that are about the same bit length, meaning they have to each be half the bit size of the key. According to the prime number theorem you can get a conservative estimate for the number of primes of a given bit size, m, with the formula
0.3*ln(2) * 2^m/(m-1)
So assuming I haven't screwed up the math, here's what it gives:
A 1024 bit key uses 512 bit primes. Number of 512 bit primes to choose from: 11.36*10^150 :o
A 2048 bit key uses 1024 bit primes. Number of 1024 bit primes to choose from: 7.61*10^304 :o :o
A 4096 bit key uses 2048 bit primes. Number of 2048 bit primes to choose from: 1.58x10^613 :o :o :o
The only bad part about using a command line it means the plaintext message has to be saved on a file somewhere.
No it doesn't. Type gpg -e and hit enter. It will prompt you for a recipient. Hit enter twice after the last recipient and you get a blinking cursor where you can type your message. Hit ctrl+d and it encrypts it in the terminal. Nothing is saved to disk. I would go mad if I had to save every message in PGP Club to a file. :)
That's a relief! I thought it only worked directly on saved files - didn't know it had a message interface. 8)