The precise status of the relevant number theoretic problems for SHA-256

[Altoidnerd]

This post is an inquiry as to the precise number theory questions relevant to the SHA-256 hashing algorithm.  This is NOT to raise doubt or uncertainty.  It is in fact for the opposite I pose the question.  

I have read some reports that some believe it is possible that the NSA, a proponent of the pseudorandom generator Dual_EC_DRBG, chose some suspiciously arbitrary constants based on elliptic curves on which the algorithm rests, and it was later suggested that such an arbitrary choice of initial values can present one who chose them the opportunity to generate or predict collisions in the mapping easily and at will.  See http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115

Whether or not those claims are legitimate, I am not sure, and for now it is not entirely important.  Here is what I note about SHA-256's constants. I understand ShA-256 is carried out twice for bitcoin's purposes; from the pseudocode offered on the wiki:

<sup>...
Initialize hash values:
(first 32 bits of the fractional parts of the square roots of the first 8 primes 2..19):
h0 := 0x6a09e667
h1 := 0xbb67ae85
h2 := 0x3c6ef372
h3 := 0xa54ff53a
h4 := 0x510e527f
h5 := 0x9b05688c
h6 := 0x1f83d9ab
h7 := 0x5be0cd19

Initialize array of round constants:
(first 32 bits of the fractional parts of the cube roots of the first 64 primes 2..311):
k[0..63] :=
   0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5, 0x3956c25b, 0x59f111f1, 0x923f82a4, 0xab1c5ed5,
   0xd807aa98, 0x12835b01, 0x243185be, 0x550c7dc3, 0x72be5d74, 0x80deb1fe, 0x9bdc06a7, 0xc19bf174,
   0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc, 0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da,
   0x983e5152, 0xa831c66d, 0xb00327c8, 0xbf597fc7, 0xc6e00bf3, 0xd5a79147, 0x06ca6351, 0x14292967,
   0x27b70a85, 0x2e1b2138, 0x4d2c6dfc, 0x53380d13, 0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85,
   0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3, 0xd192e819, 0xd6990624, 0xf40e3585, 0x106aa070,
   0x19a4c116, 0x1e376c08, 0x2748774c, 0x34b0bcb5, 0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f, 0x682e6ff3,
   0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208, 0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2
...</sup>


"32 bits of the fractional parts of the first k primes" is implemented twice - once for the first 8 primes and again for the first 64 primes.  These numbers are less suspicious than completely arbitrary points on elliptic curves.  They would only generate suspicion if there is a mathematical reason to believe there is a special property of some of the first either 8 or 64 primes' leading 32 bits of their truncated values that only 1 person or a few people know of.

The other part of the algorithm worth mentioning here is as follows:

 ^{Extend the first 16 words into the remaining 48 words of message schedule array:
    for i from 16 to 63
        s0 := (w[i-15] rightrotate 7) xor (w[i-15] rightrotate 18) xor (w[i-15] rightshift 3)
        s1 := (w[i-2] rightrotate 17) xor (w[i-2] rightrotate 19) xor (w[i-2] rightshift 10)
        w := w[i-16] + s0 + w[i-7] + s1}


I will be the first to admit I am not entirely positive how this works.  Whether the blocks are "rightshifted" and "rightrotated" through N units, or perhaps with the N'th index (it doesn't matter what is is), I do notice the appearance of the numbers 7 18 3 17 19 10 which I cannot immediately justify in this line.  

It is clear to me that it would be extremely hard, if not impossible, to provide a satisfying proof that the SHA-256 algorithm is 100% free of vulnerability to a backdoor through these constants.  What I am asking for is this.  First of all, can we discuss anything as to the safety of these constants, like, has it been asked (of the initial constants) what problem of number theory would need to be proposed, and subsequently prove to render the constants chosen decisively non-random?  What is the reason for the appearance of the numbers 7 18 3 17 19 10?

This post got insanely long, so I will leave it there.  Just let me know, people, if anyone knows the hard mathematical statements we CAN make about SHA-256, and if we can silence any n00bs who wonder if a backdoor is plausible.

[DeathAndTaxes]

Why so you keep referencing "elliptical curve"? SHA (or any hashing algorithm) has nothing to do with Eliptical Curve Cryptography. I misread the statement.

No numbers are repeated.  The first set of constants are the first 32 bits of the SQUARE ROOTS and the second set of constants are the first 32 bits of the CUBE ROOTS.  Cryptographic functions often need some set of constant values.  It becomes difficult to prove after the fact that a claimed random set of constant values don't hide malicious intent which is why most functions use a concept called "nothing up my sleeve numbers".  

http://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number

If SHA-256 uses a set of 48 "random" values I might be inclined to agree, at best it would be very difficult to prove there was not some unknown relationship between the numbers.  However SHA-256 uses the square root and cube roots of sequential primes which provides cryptographers a reference point rather than obscuring any potential weakness with a claim of "randomly chosen constants".


As for the use of various right and shift lengths.  That is the cross mixing function.  It is going to be difficult to "prove" that these numbers have no special significance.  Then again if they were 9 17 3 19 13 11 instead of 7 18 3 17 19 10 would that make you feel more secure?  I would imagine not. There possibly is a very large set of shift lengths which would work equally well however a single set is necessary.  It probably didn't need to be 7 18 3 17 19 10 but it needed to be something.

As for your final question can the algorithm be mathematically proven to be secure.  The answer is no.  AFAIK there is no hashing algorithm which is proven to be a one way function by any strict mathematical proof.
 

[Altoidnerd]

Why so you keep referencing "elliptical curve"? SHA (or any hashing algorithm) has nothing to do with Eliptical Curve Cryptography.

That's correct.  I mentioned the elliptic curve constants as they were a group of constants which received criticism last year for the very issue I want to discuss.

[gmaxwell]

Why so you keep referencing "elliptical curve"? SHA (or any hashing algorithm) has nothing to do with Eliptical Curve Cryptography.

He's referring to the potential backdooring of Dual_EC_DRBG, an ECC based RNG with a magic point constant which, if you knew the discrete log of it you could use to derive the rng state from a few of its outputs.

[Altoidnerd]

Why so you keep referencing "elliptical curve"? SHA (or any hashing algorithm) has nothing to do with Eliptical Curve Cryptography.

He's referring to the potential backdooring of Dual_EC_DRBG, an ECC based RNG with a magic point constant which, if you knew the discrete log of it you could use to derive the rng state from a few of its outputs.

I'm sitting here thinking about what the first 32 bits of a hex representation of prime(k)^(1/2) - floor(prime(k)^(1/2)), and again for prime(k)^(1/3), meaning kth prime, k = {1:64},  would mean in math words.  It is a question of divisibility or relative primeness?  Not sure if hex matters at all

[DeathAndTaxes]

Why so you keep referencing "elliptical curve"? SHA (or any hashing algorithm) has nothing to do with Eliptical Curve Cryptography.

That's correct.  I mentioned the elliptic curve constants as they were a group of constants which received criticism last year for the very issue I want to discuss.

Well that is the point of "nothing up my sleeve numbers" it simplifies the crypto-analysis.  Rather than try to determine if there is any special relationship between 72 seemingly random constants, the use of sequential primes simplifies the question to is there any special relationship between the square and cube roots of a set of sequential primes that would undermine this algorithm.  

Granted both questions are well beyond my capabilities however the later question is a far simpler question if only in scope.    The quick detection of the flaw (intentional backoor) in another cryptographic system, by the international community provides a level of assurance.   SHA-2 has been extensively studied for the better part of a decade being the prominent hashing algorithm in a variety of applications.  Finding a flaw (intentional or otherwise) in one of the (if not the) most widely used hashing function is a huge deal for cryptographers.  Any lack of evidence to a special relationship certainly isn't due to a lack of trying.  When you compare the speed at which flaws were found in Dual_EC_DRBG and consider that is a far less know/used algorithm than SHA-2 it would have to be an amazingly well hidden backdoor.

[Altoidnerd]

Why so you keep referencing "elliptical curve"? SHA (or any hashing algorithm) has nothing to do with Eliptical Curve Cryptography.

That's correct.  I mentioned the elliptic curve constants as they were a group of constants which received criticism last year for the very issue I want to discuss.

Well that is the point of "nothing up my sleeve numbers" it simplifies the crypto-analysis.  Rather than try to determine if there is any special relationship between 49 seemingly random constants the constants are sequential primes so the question becomes if any cryptographer aware of any special relationship between the square and cube roots of a set of sequential primes. 

Granted both questions are well beyond my capabilities however the later question is a far simpler question.  The detection of the flaw (intentional backoor) in another cryptographic systems provides a level of assurance.  Finding a flaw (intentional or otherwise) in SHA-256 which is one of the most widely uses cryptographic systems is a huge deal for cryptographers.  While the lack of a proof of a flaw doesn't mean there isn't a flaw, SHA-256 has been subject to extensive scrutiny for a very long time.

I was thinking rather than wondering about magic numbers which caused the hard fork, or whatever, we could think for a moment about what exact number theory problem we are asking.  Is there a known open problem which, if shown to be true or false, would be relevant to the prime^1/2 and prime ^1/3 constants and their use in SHA-256?  What property of the digits in fractional powers of primes are we relying on to assure these are safe?  Just that the powers are irrational, or something else?

[DeathAndTaxes]

I was thinking rather than wondering about magic numbers which caused the hard fork

You lost me here.

Is there a known open problem which, if shown to be true or false, would be relevant to the prime^1/2 and prime ^1/3 constants and their use in SHA-256?  What property of the digits in fractional powers of primes are we relying on to assure these are safe?  Just that the powers are irrational, or something else?

We are relying on the fact that the constants are psuedo random.  Any 49 truly random constants would be equally secure however the issue with that is if NIST provided you a list of 32 bit numbers they "randomly" generated would you trust them?  Essentially trust of SHA-2 would hinge on trust of NIST. If the constants are random then the algorithm is trusted and if they are not then it may hide a flaw.  Given that that randomness of the constants could never be proven it presents an interesting problem to public adoption.

The use of first 32 bits of square and cube root sequential primes is merely a method to introduce entropy into the algorithm.  We aren't relying on any specific property of square and cube roots merely that no exploitable relationship exists.  As for proving that, I doubt believe that is possible. 

[Altoidnerd]

Why so you keep referencing "elliptical curve"? SHA (or any hashing algorithm) has nothing to do with Eliptical Curve Cryptography. I misread the statement.

No numbers are repeated.  The first set of constants are the first 32 bits of the SQUARE ROOTS and the second set of constants are the first 32 bits of the CUBE ROOTS.  Cryptographic functions often need some set of constant values.  It becomes difficult to prove after the fact that a claimed random set of constant values don't hide malicious intent which is why most functions use a concept called "nothing up my sleeve numbers".  

http://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number

If SHA-256 uses a set of 48 "random" values I might be inclined to agree, at best it would be very difficult to prove there was not some unknown relationship between the numbers.  However SHA-256 uses the square root and cube roots of sequential primes which provides cryptographers a reference point rather than obscuring any potential weakness with a claim of "randomly chosen constants".


As for the use of various right and shift lengths.  That is the cross mixing function.  It is going to be difficult to "prove" that these numbers have no special significance.  Then again if they were 9 17 3 19 13 11 instead of 7 18 3 17 19 10 would that make you feel more secure?  I would imagine not. There possibly is a very large set of shift lengths which would work equally well however a single set is necessary.  It probably didn't need to be 7 18 3 17 19 10 but it needed to be something.

As for your final question can the algorithm be mathematically proven to be secure.  The answer is no.  AFAIK there is no hashing algorithm which is proven to be a one way function by any strict mathematical proof.
 

Thanks.  I will note here that you seem to be taking the stance that it is my opinion somehow that the constants are malicious, and that is not the case.

I am asking if it can be stated (and perhaps it cannot, or no one has done so...I have so far been unable to ponder it myself) what property, precisely, of real numbers we are clinging to here.  I will throw out my opinion in this regard - there probably IS at the very least a way to state in precise mathematical terms, what property of numbers we HOPE is in fact true.  Number theory always wins...that is not to say there is a weakness.  Asking the question - and what I am doing is saying "it can probably be asked more succinctly than simply stating the SHA-256," - asking if there is a property that must hold true is not to say "there is something up the sleeve of these choices."

[DeathAndTaxes]

I am asking if it can be stated (and perhaps it cannot, or no one has done so...I have so far been unable to ponder it myself) what property, precisely, of real numbers we are clinging to here.  I will throw out my opinion in this regard - there probably IS at the very least a way to state in precise mathematical terms, what property of numbers we HOPE is in fact true.  Number theory always wins...that is not to say there is a weakness.  Asking the question - and what I am doing is saying "it can probably be asked more succinctly than simply stating the SHA-256," - asking if there is a property that must hold true is not to say "there is something up the sleeve of these choices."

AFAIK the constants merely need to be psuedo-random values.  Using truly random values would provide security but wouldn't provide transparency (are those randoms really random).  The use of squares/cubes of primes is soley to be a "nothing up my sleeve number".  It could have been first 240 digits of Pi instead or a sequence of true random numbers based on radioactive decay or quantum RNG.

If the constants aren't randomly distributed it could undermine the security of the algorithm.

[Altoidnerd]

I was thinking rather than wondering about magic numbers which caused the hard fork

You lost me here.

Is there a known open problem which, if shown to be true or false, would be relevant to the prime^1/2 and prime ^1/3 constants and their use in SHA-256?  What property of the digits in fractional powers of primes are we relying on to assure these are safe?  Just that the powers are irrational, or something else?

We are relying on the fact that the constants are psuedo random.  Any 49 truly random constants would be equally secure however the issue with that is if NIST provided you a list of 32 bit numbers they "randomly" generated would you trust them?  Essentially trust of SHA-2 would hinge on trust of NIST. If the constants are random then the algorithm is trusted and if they are not then it may hide a flaw.  Given that that randomness of the constants could never be proven it presents an interesting problem to public adoption.

The use of first 32 bits of square and cube root sequential primes is merely a method to introduce entropy into the algorithm.  We aren't relying on any specific property of square and cube roots merely that no exploitable relationship exists.  As for proving that, I doubt believe that is possible.  

I don't think I lost you - you know what I'm asking.  What is the compliment then, of the set of pseudo random numbers?  Numbers in which some relationship is known between the digits?

I don't actually even think it is that simple.  If some rotational property of the prime's fractional powers' digits were known, it is another source of trouble...possibly.

Please keep in mind it is for science I am trying to attack the problem in a scholarly way.  I see not only the constants' digits themselves to be under scrutiny, but also the image of the function through which they are put.  

Here is a really simple example of a function f(h_i) which would be a bad function to follow the selection of the constants.

f(h_i) = (h_i)^2 + floor(p_i)

Why?  Because that function's image under the set {h0,h1,h2...} is the first 8 primes.

Obviously that is not even the type of function which follows.  It is only to illustrate the concept that the image is the questionable space, rather than the domain.

[Altoidnerd]

I'm gonna stop and say right now I need to better visualize what this mixing of fractional parts of fractional powers of primes that follows is and how it plays out before I continue to blubber about this.  The discussion helped me clear my thoughts.  

Are any of the indexed, fractional prime powers from the length 8 list met with ones from 64 length list?  If so, the numbers {p - p^5/6| p is prime} would be relevant.  

no no.  wrong, ignore.

[razorfishsl]

I will be the first to admit I am not entirely positive how this works.  Whether the blocks are "rightshifted" and "rightrotated" through N units, or perhaps with the N'th index (it doesn't matter what is is), I do notice the appearance of the numbers 7 18 3 17 19 10 which I cannot immediately justify in this line.  

Please please just STOP...
Don't go copying bits of code and then start spouting about how you enjoy wearing a tinfoil hat, but that you  are not certain about all the details of  why you think you need one.


crack open the web version of xilinx tools then GO WALK the code, it's so simple even a complete MORON can follow it....
(yep I know you can use C++ or assembler, but following digital logic is WAY more expressive and clear)

an example:

hash & nonce (please note I pre-found the nonce thats why I know it is what it is)

Code:

00000001c3bf95208a646ee98a58cf97c3a0c4b7bf5de4c89ca04495000005200000000024d1fff8d5d73ae11140e4e48032cd88ee01d48c67147f9a09cd41fdec2e25824f5c038d1a0b350c:5eb01f04

here is the "midstate" and "data" for above number string not including  the nonce

Code:

mid state 															data
5f50aa41db2439f27a0ea72a235e32446edd55d3cd596f9ade16dd67df321701 		0c350b1a8d035c4f82252eec

And here is an example  of 'finding' the correct nonce



If you cannot figure out how to use the VHDL emulation tools, then you are not going to be able to figure out the  algorithm.
go watch the absolute magic of a value on a prior clock cycle, having absolutely no zero's at the top end... then wham.... They just appear...
Then step back each clock cycle and watch HOW they appear.. it's so simple.... but it is not... and that is the magic.

What does this give you?

well it gives you a complete bit level model of how it all works at each and every stage,  go play with it then go figure out answers to your very basic questions (by watching each stage at each CLK cycle you will SEE exactly what happens when you shift shit out of a bit container...)

As regards 'seeing' certain numbers..... have you ever noticed  that in base 2 you see a lot of '0' &  '1' or that  certain random numbers come up more often?

Unless you have a collaborative statistical analysis.. thenI'm afraid it is just your mind playing tricks.

[Altoidnerd]

I will be the first to admit I am not entirely positive how this works.  Whether the blocks are "rightshifted" and "rightrotated" through N units, or perhaps with the N'th index (it doesn't matter what is is), I do notice the appearance of the numbers 7 18 3 17 19 10 which I cannot immediately justify in this line.  

Please please just STOP...
Don't go copying bits of code and then start spouting about how you enjoy wearing a tinfoil hat, but that you  are not certain about all the details of  why you think you need one.


crack open the web version of xilinx tools then GO WALK the code, it's so simple even a complete MORON can follow it....
(yep I know you can use C++ or assembler, but following digital logic is WAY more expressive and clear)

an example:

hash & nonce (please note I pre-found the nonce thats why I know it is what it is)

Code:

00000001c3bf95208a646ee98a58cf97c3a0c4b7bf5de4c89ca04495000005200000000024d1fff8d5d73ae11140e4e48032cd88ee01d48c67147f9a09cd41fdec2e25824f5c038d1a0b350c:5eb01f04

here is the "midstate" and "data" for above number string not including  the nonce

Code:

mid state 															data
5f50aa41db2439f27a0ea72a235e32446edd55d3cd596f9ade16dd67df321701 		0c350b1a8d035c4f82252eec

And here is an example  of 'finding' the correct nonce



If you cannot figure out how to use the VHDL emulation tools, then you are not going to be able to figure out the  algorithm.
go watch the absolute magic of a value on a prior clock cycle, having absolutely no zero's at the top end... then wham.... They just appear...
Then step back each clock cycle and watch HOW they appear.. it's so simple.... but it is not... and that is the magic.

What does this give you?

well it gives you a complete bit level model of how it all works at each and every stage,  go play with it then go figure out answers to your very basic questions (by watching each stage at each CLK cycle you will SEE exactly what happens when you shift shit out of a bit container...)

As regards 'seeing' certain numbers..... have you ever noticed  that in base 2 you see a lot of '0' &  '1' or that  certain random numbers come up more often?

Unless you have a collaborative statistical analysis.. thenI'm afraid it is just your mind playing tricks.

I get the feeling you are ignorant to number theory. The zeros do not just appear out of then air - they are deterministically manifest in the calculation steps prior to their appearance.

Do you fail to realize that SHA-1 was broken in a number of ways?  Tin foil hat my ASS.  It's mathematics - script kiddie isn't going to teach you how to do this sort of thing, so try this

http://link.springer.com/chapter/10.1007/11799313_9#page-1

Notice there how the big boy analysts don't whip out their computers, make a single calculation, and proceed to go online and play video games.  They could have said "well, ma, ain't no collisions yet, ain't n'er guna be none."  No, they actually quantified similarities between SHA-256 and SHA-1, like men with brains would do before crying on a forum that they understand something.

Secondly, while I'll admit this is off toipic, but just because you are a such an asshole, do you not suppose that I prefer to look at the algorithm as a mathematical object acting on sets rather than a particular programming language's implementation, holy shit, that's what I got my education in? Fucking math?

You are HIGH as a kite if you think looking at a terminal is going to illuminate more about this algorithm than a robust mathematical analysis of not only the statistics of the algorithm but the underlying number theory.  You are equally stoned, and on wacky shit, if you think what you did is an analysis of any sort.  

You might be too far behind, but if you want to be able to ever convince yourself the algorithm is not magic..far from it in fact, you can start by learning some new words

https://en.wikipedia.org/wiki/Prime_number
https://en.wikipedia.org/wiki/Rotation_(mathematics)

[razorfishsl]

I get the feeling you are ignorant to number theory. The zeros do not just appear out of then air - they are deterministically manifest in the calculation steps prior to their appearance.

I get the idea you do not understand 'irony'

As regards the rest of the drivel you posted..., I can see from the fact that you 'cited' 'prickypidia' that your education is most possibly below BA level, anything about that level, you would have been educated in 'research skills' which in turn would have lead you to several papers on partial 'cracks' of the SHA256 algorithm.. upto about 25 bits.
There is also research on Hash prediction, something I myself have been interested in.

The fact that you do not  appear to be aware of these research areas (as you used neither to try and negate my post)  would lead me to believe you are more likely to be a fuckwit
who managed to pickup a couple of buzzwords

[poiuytr4]

Wow, razorfishsi, you should have taken more time to read this post as Altoidnerd was asking some valid questions and you might have missed some points and Altoidnerd you should not react so quickly and defensively. 
 Anyway, Altoidnerd, I think that often, the whole point of these maths/science things is asking what are the questions and not just what are the answers. If you can break these things down into what are the number theoretic questions that need to be answered then that is just as much of the work as providing the answer.
 Some of the most interesting/difficult mathematics is about providing the questions that need to be answered. So I don't think that what you're asking for is so straightforward.
 Hypotheses are just questions and Riemann, for example, is famous for asking a question, and not for providing an answer to it.

 
 

[Loozik]

He's referring to the potential backdooring of Dual_EC_DRBG, an ECC based RNG with a magic point constant which, if you knew the discrete log of it you could use to derive the rng state from a few of its outputs.

Newbie question:: to the best of anyone's knowledge, do Bitcoin-Qt, other clients or Bitcoin related services use this Dual_EC_DRBG something?

[EmperorBob]

I don't know why you think number theory can actually shine any light on this.
Taking the fractional part of a floating point number and multiplying it by 2**32 essentially gets you a nice garbage integer.
Because square/cube roots are believed to be normal numbers in base 2 http://mathworld.wolfram.com/NormalNumber.html (Their digit distribution certainly is random for the relevant part anyways), their decimal expansion is essentially a string of random (the important part) garbage. It has no interesting number theoretic properties left.
More importantly, the round constants are mixed through essentially bitwise operations, the number theory surrounding primes would have very little of interest to tell you, since it does not deal with the representations of numbers, while hash algorithms are essentially only bit twiddling, which mostly don't care about the numeric values used (only their binary representation).

[jedunnigan]

Something to go on here: http://arxiv.org/abs/1308.0219

Abstract:The secure hash function SHA-256 is a function on bit strings. This means that its restriction to the bit strings of any given length can be computed by a finite instruction sequence that contains only instructions to set and get the content of Boolean registers, forward jump instructions, and a termination instruction. We describe such instruction sequences for the restrictions to bit strings of the different possible lengths by means of uniform terms from an algebraic theory.

To phrase it more precisely, the standard describes an algorithm that computes the hash function SHA-256 by means of pseudo-code. In this paper, unlike the standard, an algorithm that computes a function is distinguished from the computed function.
...
It is shown in [6] that, in the case of instruction sequences of the kind that we have dealt with in this paper, instruction sequence length is a computational complexity measure closely related to non-uniform time complexity. An option for future work is investigating the possible role of this complexity measure in issues concerning the complexity of the different kinds of attack on secure hash functions like SHA-256.

edit: for clarity, this is not about the current discussion, just a direct response to the OP.

[RagnarDanneskjold]

This conversation has been wildly hilarious & informative. Thank You all.