How great is the risk in publicly sharing part of a private key?

Providing any part of the private key makes it less secure, at least marginally, simply because it provides an attacker with a smaller potential key space to explore.

I fail to understand what you want to achieve. The only thing two people need to do to check if they hold the same information is exchange a hash.

If you are designing a protocol and are worried about replay attacks, you can protect against it by performing a challenge response using a HMAC.

Edit:

As suggested the comments and explained in D.W.'s insightful answer, I need to emphasis that the impact on the security of your private key will depends a LOT of exactly what algorithm you are using. In the worse case scenario, revealing only a small part of the private key will completely break the security of that key.

Revealing part of the private key can be catastrophic, for some asymmetric (public-key) cryptosystems. The exact level of risk depends on exactly which cryptosystem you are using. Some examples:

• If you are using RSA with e=3 for the public key, then revealing 1/4th of the private key (the low 1/4 bits of d) is enough to let an attacker reconstruct the entire private key. For instance, if you're using 2048-bit RSA and you reveal the 512 least significant bits of the private key, then an attacker can recover the rest of your private key. This result is due to Boneh, Durfee, and Frankel. There are other results like it in the literature (e.g., about the most significant bits, a random subset of bits, etc.).

• With DSA, if a few bits are leaked from the nonce used in each signature (for a variety of signatures), this is enough to recover the private key. For instance, if you can observe 5 bits of the secret nonce that was used in each of 4000 signatures, that's enough to recover a 384-bit ECDSA private key. This isn't exactly revealing the private key (it's revealing some other secret value generated during signing), but it's similar.

I realize other answers are saying it's no problem. Those answers might be assuming you are using a symmetric-key cryptosystem. For most symmetric-key cryptosystems, if you reveal part of the key, but enough of the key remains unrevealed, they'll likely still be secure. When it comes to asymmetric cryptosystems, things are different. Other answers appear to be assuming that brute force (exhaustively trying all possible private keys) is the best attack possible against the cryptosystem. For many asymmetric cryptosystems, this assumption is not accurate.

How much faster could an attacker crack the key given those 8 chars?

It's hard to answer without knowing what kind of key we are talking about and what algorithm it's used with.

In the case of symmetric encryption where the key is entirely random (understand each bit takes equal part in the global uncertainty of the key), then it mainly depends on what "1 char" represents in terms of binary data. In general, by revealing n bits, you are effectively reducing the number of possible keys by a factor of at least 2^n.

• In case of a binary textual representation where 1 character = (0 or 1) = 1 bit : 8 characters means a reduction factor of 2^8 = 256.
• In case of an hexadecimal representation where 1 character = 4 bits : 8 characters means a reduction factor of 2^32 = 4294967296.
• In case of a base64 representation where 1 character = 6 bits : 8 characters means a reduction factor of 2^48 = 281474976710656.

Which - depending on the amount of the revealed information - may (or may not) be used as a leverage to break your key depending of the possible (current or futur) weaknesses of your encryption algorithm.

Also note that in the case of asymmetric encryption where the key is not completely random (e.g. prime factor modulus and exponent in RSA), revealing n bits may actually reveal much more useful information and may lead to catastrophic loss of security.

But the real question is :

Why would anyone ever need to do that ?

Not only this method poses a potential security flaw, it doesn't seem to reliability fit your purpose, what about the remaining 248 bits ?

The method you describe is just a very trivial hash function that is completely continuous (very bad for integrity check) and partially reversible (very bad for security purpose).

If you really need to do this, use a secure and widely-available cryptographic hash function such as SHA-256 which will generate a hash that is much more secure (practically irreversible and computationally intensive) and much more collision-resistant than "the first 8 chars".

If you are using asymmetric encryption, you should never need too share any part (even a hash) of the private key, use the public key instead.