While I'm not new to technology, programming, or computers at all, I am fairly new to encryption. I'm slowly making my way through Applied Cryptography - but, from skimming the chapters ahead I don't think I'd get the answer I'm looking for.
When you sign code, what exactly is done to the code - is the whole (or sections, I'd imagine) chunk of machine code converted into an integer and then encrypted? Just certain parts of the program, etc? I can't find the actual process of encrypting a program - or, am I on the wrong path, and it's actually getting encrypted just like any data file, and the hardware (or software) decrypts the executable. Somewhat like you would an encrypted text file and then the machine runs it?
And as for factoring, I know it's a horridly long process - but, let's assume I had access to 6-10 10gigahertz machines - would the PSP's 1024-bit encryption, on my babies, compare to the average 6 weeks for 512-bit brute-force that is possible? I realize there is an exponential difference between 512 and 1024-bit encryption, was hoping an exponential increase in cpu cycles could counteract.
I'm also assuming, that if the private key is factored, no firmware version could block homebrew signed code with that key, correct?
Are there any sites out there with more details on signing, bruteforce factoring, or even code examples - with this sort of thing? Maybe I just suck at searching on the internet, but I'm not finding anything worth reading that a non-mathmatician can understand.
And - just to get this now, I can't talk about how I have access to those machines, or where I work, etc.
Factoring question.
Not the right place, thread moved.
To answer your question, the asymetric encryption process (such as described by Diffie Hellmann - google for it a bit, but I'm not sure about the spelling) provides way to sign and/or crypt any portion of data. Asymetric encryption involves key pair: public and private. The private key is kept safe, while the public one is provided wide. To make it short: the private key can decrypt and can sign. The public key can encrypt and can verify the signature. Signature is only something like "hashing thru a hash function that depends on the private key", that is, think of a custom MD5 algo that'll involve the private key to run.
As for bruteforcing a crypted chunk of data, I am not sure wherever we have enough of a grasp about the involved crypto process to write any kind of bruteforcer. Think about it: bruteforcing a known algorithm is like sending a spaceship thowards Alpha Centauri. Will quite take forever, but may work. Bruteforcing an unknown crypto process is like sending a spaceship thowards Alpha Centauri, without knowing its actual coordinates in space.
Btw, is it "factoring" or "factorizing" ? Or both ?
Ah, and, last thing: if you want to amend one of your post, you still have the tiny shiny "edit" button.
To answer your question, the asymetric encryption process (such as described by Diffie Hellmann - google for it a bit, but I'm not sure about the spelling) provides way to sign and/or crypt any portion of data. Asymetric encryption involves key pair: public and private. The private key is kept safe, while the public one is provided wide. To make it short: the private key can decrypt and can sign. The public key can encrypt and can verify the signature. Signature is only something like "hashing thru a hash function that depends on the private key", that is, think of a custom MD5 algo that'll involve the private key to run.
As for bruteforcing a crypted chunk of data, I am not sure wherever we have enough of a grasp about the involved crypto process to write any kind of bruteforcer. Think about it: bruteforcing a known algorithm is like sending a spaceship thowards Alpha Centauri. Will quite take forever, but may work. Bruteforcing an unknown crypto process is like sending a spaceship thowards Alpha Centauri, without knowing its actual coordinates in space.
Btw, is it "factoring" or "factorizing" ? Or both ?
Ah, and, last thing: if you want to amend one of your post, you still have the tiny shiny "edit" button.
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.
Sorry about it being in the wrong area...
I appreciate your reply, and that caused more questions...all of these might be moot, since you said that the encryption process is not fully known for the PSP hardware. However, hopefully some of these questions might have an answer. I'm more curious now, than actually considering a factoring solution. And perhaps someone else will learn from this as well.
When the ELF executable is encrypted, is it treated as just a data file during the process?
plain text - > algo -> cypher text (non executable - because it's jibberish gobbilygook.)
Essentially, the encryption process doesn't care that it is an executable.
Or, are just certain elements in the ELF file encrypted - like the ELF header, or segment table and everything else is dandy. Just encrypting a couple headers will do the necessary bit of blocking someone.
I'm wondering this because of the library calls that were/are being bruteforced - in a fully encrypted executable, wouldn't those NID's be encrypted to different numbers?
Also, along those lines, I've read in the forums about disassembling - wouldn't that also not be possible on a fully encrypted executable?
As for signing - assuming and simplifying - 1,2,3,4,5 is executable code.
1+2+3+4+5=15
15 is the signature. So if you change 2 to 3...
1+3+3+4+5=16, we know the data was tampered with because the "hash" we did does not match the signature that was embedded, or attached as a certificate. Is this correct?
So the PSP code we buy from Sony is encrypted and signed, right? Or is it just signed, and we don't have the primes involved in creating that same signature value, with the same data?
I'm rather long-winded...
As for the edit button - my mistake.
dictionary.com -
factorizing: To factor
factoring: To determine or indicate explicitly the factors of.
I always treated it like, vertexes - vertices. Both are valid: one is British, and the other is correct.
I appreciate your reply, and that caused more questions...all of these might be moot, since you said that the encryption process is not fully known for the PSP hardware. However, hopefully some of these questions might have an answer. I'm more curious now, than actually considering a factoring solution. And perhaps someone else will learn from this as well.
When the ELF executable is encrypted, is it treated as just a data file during the process?
plain text - > algo -> cypher text (non executable - because it's jibberish gobbilygook.)
Essentially, the encryption process doesn't care that it is an executable.
Or, are just certain elements in the ELF file encrypted - like the ELF header, or segment table and everything else is dandy. Just encrypting a couple headers will do the necessary bit of blocking someone.
I'm wondering this because of the library calls that were/are being bruteforced - in a fully encrypted executable, wouldn't those NID's be encrypted to different numbers?
Also, along those lines, I've read in the forums about disassembling - wouldn't that also not be possible on a fully encrypted executable?
As for signing - assuming and simplifying - 1,2,3,4,5 is executable code.
1+2+3+4+5=15
15 is the signature. So if you change 2 to 3...
1+3+3+4+5=16, we know the data was tampered with because the "hash" we did does not match the signature that was embedded, or attached as a certificate. Is this correct?
So the PSP code we buy from Sony is encrypted and signed, right? Or is it just signed, and we don't have the primes involved in creating that same signature value, with the same data?
I'm rather long-winded...
As for the edit button - my mistake.
dictionary.com -
factorizing: To factor
factoring: To determine or indicate explicitly the factors of.
I always treated it like, vertexes - vertices. Both are valid: one is British, and the other is correct.
Signed code work with public/private keys. in this scheme private keys can decrypt things encrypted by the public key, and VICEVERSA, the public key decrypts things encrypted by the private key. Well...
Usually signing works as follow.
we have message(code) A
now we made a HASH of A. SHA1, SHA256, MD5... let's call it H(A)
now we encrypt H(A) with the PRIVATE key, lets call it Pr(H(A))
we put this sign after or before the message.
The psp does the following (aprox.) to chek the sign
made a hash of the code A -> H(A)
now take the sign of the header Pr(H(A)) and aplies the PUBLIC key
the psp obtains H(A) the public key decrypt the hash
and finally chek H(A) = H(A) if the code is altered the PSP will show a error message.
You can't take the sign of an executable and put it in another, becase the hashes will be diferent.
My english is rather bad... sorry.
Usually signing works as follow.
we have message(code) A
now we made a HASH of A. SHA1, SHA256, MD5... let's call it H(A)
now we encrypt H(A) with the PRIVATE key, lets call it Pr(H(A))
we put this sign after or before the message.
The psp does the following (aprox.) to chek the sign
made a hash of the code A -> H(A)
now take the sign of the header Pr(H(A)) and aplies the PUBLIC key
the psp obtains H(A) the public key decrypt the hash
and finally chek H(A) = H(A) if the code is altered the PSP will show a error message.
You can't take the sign of an executable and put it in another, becase the hashes will be diferent.
My english is rather bad... sorry.