Euler's totient function algorithm compatible with SHA-256?

[Killuminati1]

I'm working on a new project and could use some help from anyone that has worked on or understands the SHA-256 algorithm. Basically I need to know how compatible the two cryptography algorithms are if at all and whether or not a new alt coin could be designed around Euclid's Algorithm using the Euler's totient function. Im not sure this is the best place to raise the question but was hoping someone with a bit of knowledge in cryptography could help me out.

 (Euclid's algorithm) for calculating the greatest common divisor (g.c.d.) of two numbers a and b in locations named A and B. The algorithm proceeds by successive subtractions in two loops: IF the test B ≥ A yields "yes" (or true) (more accurately the number b in location B is greater than or equal to the number a in location A) THEN, the algorithm specifies B ← B − A (meaning the number b − a replaces the old b). Similarly, IF A > B, THEN A ← A − B. The process terminates when (the contents of) B is 0, yielding the g.c.d. in A.

[divine_core]

I don't understand. SHA-256 has nothing to do with computing Euler's totient function, and neither does computing the GCD (well, you can use it to compute the totient function, but it's not the most efficient way). And I'm not sure how you'd use the totient function as a proof-of-work.

[charleshoskinson]

I'm working on a new project and could use some help from anyone that has worked on or understands the SHA-256 algorithm. Basically I need to know how compatible the two cryptography algorithms are if at all and whether or not a new alt coin could be designed around Euclid's Algorithm using the Euler's totient function. Im not sure this is the best place to raise the question but was hoping someone with a bit of knowledge in cryptography could help me out.

There is no connection between SHA and the ETF. ETF relies upon integer factorization, which is a slow process and thus used as the foundation of RSA. SHA is a cryptographically secure file integrity check. Essentially it's a very special function that maps arbitrary files to a rather large domain in a process constrained by something called the avalanche effect.   

[Killuminati1]

Thx guys I understand RSA works better with larger prime integers and that there is a difference in functionality concerning Elliptic Curve Digital Signature Algorithm when processing using SHA-256. The reason I bring up the question concerning compatibility with public key encryption and signature using RSA and its association to the Euler's totient function is to determine if the size differences between RSA and ECDSA signatures could be resolved using faster computers and if so how this would effect the DNSSEC transmission of keys and signatures. The key size of the Elliptic curve needs to match the hash algorithm in order to prevent weaker halves of the signature from being attacked. So I guess what I was trying to ask is with faster computers in the future using Graphene chips if RSA could be utilized using SHA-256 and SHA-384 to speed up validation at the cost of slower ECDSA signing or would this weaken the signing algorithm to much using 3072 bit keys instead of 2048 bit keys? I understand that RSA is much slower with ECDSA signing but validation would greatly be increased by using RSA. I guess I should of explained what I was looking for a bit better before asking.

Super computers are just a few years out so instead of working with the limitations of what we currently have I wanted to see if there was a way to speed up validation using RSA and if this is possible hashing with SHA-256, if that makes any sense.

[DeathAndTaxes]

That was a random jumble of buzz words and phrases saying absolutely nothing.

[Killuminati1]

That was a random jumble of buzz words and phrases saying absolutely nothing.

Ok could you explain why using ECDSA keys are more viable over RSA keys short of the difference in speed and size of the key. I am a bit new to this and trying to understand the functionality of SHA-256.

[Killuminati1]

Also was wondering if anyone knew if Lamport Signatures would work with SHA3 in the inevitable case that someone was able to find collisions with SHA256. Quantum computing it rapidly approaching with the use of graphene.

Here is the article I found on the topic http://cleantechnica.com/2013/12/23/mit-team-shows-how-graphene-could-work-in-quantum-computer/

I guess collisions wont really matter in the future with preimage resistance.

[Killuminati1]

I don't understand. SHA-256 has nothing to do with computing Euler's totient function, and neither does computing the GCD (well, you can use it to compute the totient function, but it's not the most efficient way). And I'm not sure how you'd use the totient function as a proof-of-work.

I was reading an article on entropy problems concerning public keys and was wondering if the algorithm would work better with RSA. Eurler's totient fuction came to mind as I have been looking more into phi's relationship to scalar and vector fields and had an idea is all. Clip from the article is below.

"If the initial seed to the pseudorandom number generator is generated with low entropy, this could result in multiple devices generating different moduli which share the prime factor p and have different second factors q. Then both moduli can be easily factored by computing their GCD: p = gcd(N1, N2).

OpenSSL’s RSA key generation functions this way: each time random bits are produced from the entropy pool to generate the primes p and q, the current time in seconds is added to the entropy pool. Many, but not all, of the vulnerable keys were generated by OpenSSL and OpenSSH, which calls OpenSSL’s RSA key generation code.

Computing the GCDs of all pairs of keys

If any pair of RSA moduli N1 and N2 share, say, the same prime factor p in common, but have different second factors q1 and q2, then we can easily factor the moduli by computing their greatest common divisor. On my desktop computer, computing the GCD of two 1024-bit RSA moduli took about 17µs.

For the mathematically inclined, I’ll explain how we were able to use this idea to factor a large collection of keys.

The simplest way that one might try to factor keys is by computing the GCD of each pair of RSA moduli. A back of the envelope calculation shows that doing a GCD computation for all pairs of moduli in our data sets would take 24 years of computation time on my computer."

Here is a link that explains in part why i brought up the subject http://en.reddit.com/r/crypto/comments/1l886l/some_thoughts_on_proofofwork_systems/

[divine_core]

Quantum computers don't actually help you find SHA256 collisions. Even if they did, you could just go up to SHA3 with 512-bit output or something.

ECDSA was probably chosen over RSA because ECDSA keys and signatures are much smaller than RSA keys and signatures, at the cost of being somewhat more computationally expensive to verify.

Your statement about "phi's relationship to scalar and vector fields" reads like nonsense to me.

[DeathAndTaxes]

Ok could you explain why using ECDSA keys are more viable over RSA keys short of the difference in speed and size of the key. I am a bit new to this and trying to understand the functionality of SHA-256.

Not sure why you keep linking ECDSA with SHA-256?  

ECDSA has smaller keys for a given key strength than RSA.  Since the blockchain is a historical ledger and the size of a transaction directly correlates to the size of the keys and signatures RSA would be a far inferior choice.  ECDSA achieves 128 bit security using a 256 bit private key (and 256 bit compressed public key).  That would require 3,076 bit RSA keys to provide the same level of security.  That means signatures and pubkey on the input side of a transaction would be ~12x larger.  If we assume a block was filled with 2 input and 2 output tx then for a given number of transactions Bitcoin-RSA would have blocks which are 8x larger.

Bitcoin doesn't "require" SHA-256.  It is possible to pay directly to the pubkey.  The using of a hashing function is completely separate from the use of a public key cipher.  So what is confusing is you keep asking about ECDSA and then say you are trying to understand the functionality of SHA-256. 

Bitcoin (as it relates to address & transactions) uses SHA-256 to provide the following benefits
a) reduction in the size of transactions (payments are to pubkeyhash not pubkey)
b) reduction in the size of addresses
c) (combined with checksum and address format) provide a method to detect invalid addresses and thus prevent human error
d) provide a level of quantum computing resistance.  Shor's algorithm only works against a private key when the pubkey is known.  Addresses are an encoded and checksumed representation of the pubkeyhash not the pubkey.

Bitcoin or Bitcoin-RSA could either be used with or without SHA-256 so if you question is on ECDSA why keep bringing up SHA-256?

[Killuminati1]

Thx death I wanted to see if there was a way to make an algorithm based on phi and had read this article earlier. http://crypto.stackexchange.com/questions/11293/hmac-sha256-vs-rsa-sha256-which-one-to-use

[rethaw]

That was a random jumble of buzz words and phrases saying absolutely nothing.

This should point you in the right direction.