You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

区块链加密货币公钥认证防枚举问题及SSH机制咨询

How SSH Mitigates Public Key Enumeration Attacks (and How to Adapt This to Your Blockchain Project)

Great question—this is a classic edge case when adapting public key authentication to new systems, and SSH has proven, battle-tested mechanisms to stop attackers from enumerating valid keys. Let’s break down how SSH handles this, then map those ideas to your blockchain-based cryptocurrency scenario.

SSH’s Core Anti-Enumeration Techniques

1. Uniform Error Messages + Delayed Responses

SSH servers intentionally avoid giving attackers actionable feedback. Whether you send a non-existent public key, a valid key without permissions, or even a malformed key, the server will return the same generic error (usually Permission denied (publickey)).

To make brute-force/enumeration even harder, SSH adds a small, random delay before sending the error. This prevents attackers from timing responses to distinguish between "key doesn’t exist" (fast rejection) and "key exists but no access" (slower processing).

2. Hashed Public Key Storage

Instead of storing public keys in plaintext, SSH servers store cryptographic hashes of the keys (typically SHA-256, with a unique salt per key). When a client sends a public key, the server computes its hash and compares it to the stored hashes—never exposing the full list of valid keys or allowing direct plaintext matching.

Even if an attacker gains access to the server’s authorized keys file, they can’t reverse the hash to get the original public key, making bulk enumeration impossible.

3. Optional (Disabled-by-Default) Key Hint Mechanism

Some SSH setups support sending a list of valid key hashes to clients (via the PubkeyAcceptedKeyTypes extension), but this is off by default. When enabled, it only lets clients check if their own key’s hash is present—attackers can’t iterate through possible keys to find matches, since they don’t have the corresponding private keys to generate valid hashes for verification.

Adapting These to Your Blockchain Scenario

Blockchains are inherently public, which changes things—you can’t hide the list of admin keys entirely like an SSH server can. But you can adapt SSH’s principles to prevent enumeration:

1. Standardize Error Responses + Add Random Delays

Whenever someone submits a transaction to modify a block, return identical chain-wide responses regardless of whether their public key is in the admins list. For example:

  • Instead of "Invalid admin key" vs "Success", use a generic "Transaction processed" message for both cases (only actually apply the change if the key is valid).
  • Inject a short, random delay into the validation process for all requests—this stops attackers from using response timing to guess if a key is valid.

2. Store Admin Key Hashes (Not Plaintext)

Instead of listing raw public keys in the block’s admins field, store their cryptographic hashes (use a strong, collision-resistant algorithm like SHA-256). When a client attempts to modify the block:

  1. They submit their public key along with the modification request.
  2. The chain computes the hash of the submitted key and checks it against the stored admin hashes.
  3. Only if there’s a match does the modification go through.

Since hashes can’t be reversed to get the original public key, attackers can’t take known public keys, compute their hashes, and check against the blockchain’s admin list to find valid keys.

3. Add a Challenge-Response Step

Before validating the public key, require the client to sign a unique, random challenge generated by the chain (or a trusted validator). This way:

  • Attackers can’t just send random public keys to test validity—they need the corresponding private key to sign the challenge.
  • You can return a generic "Invalid signature" error for both cases where the key isn’t an admin or the signature is invalid, hiding whether the key itself was in the admin list.

4. Avoid Exposing Permission State On-Chain

Don’t log any events or metadata that reveals whether a public key is an admin. For example, don’t emit a "Admin key verified" event for valid keys and "Unauthorized key" for invalid ones—keep all on-chain logs generic so attackers can’t scrape them to build a list of valid admin keys.


内容的提问来源于stack exchange,提问作者user14304565

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.05.09 12:08:10