Whirlpool RSA Blinding Vulnerability Analysis - Ashigaru Terminal

Executive Summary

After conducting a thorough security analysis of the Ashigaru Terminal codebase, we can definitively conclude that Ashigaru Terminal HAS implemented a fix for the RSA blinding deanonymization vulnerability. The client now uses hardcoded RSA public keys and explicitly rejects any attempts by the coordinator to provide different keys to different clients, effectively preventing the potential deanonymization attack vector.

Background on the Vulnerability

The RSA blinding vulnerability in Whirlpool coinjoins centers around the blind signature mechanism used during the mixing process. In a properly implemented coinjoin system, all participants should use the same RSA public key for blinding their signatures. However, if a malicious coordinator could send different RSA public keys to different clients, it would be able to deanonymize users by correlating the blinded signatures with their unblinded counterparts during the output registration phase.

The vulnerability works as follows: during the CONFIRM_INPUT phase, clients receive a public key for blind signature operations. If each client receives a unique key, the coordinator can later identify which client generated which blinded signature, completely breaking the anonymity guarantees of the mixing protocol.

Technical Implementation Analysis

Vulnerability Mitigation Code

The primary fix is implemented in darkjar/src/main/java/com/samourai/whirlpool/client/mix/MixProcess.java at lines 130-137. The critical code section reads:

final RSAKeyParameters rsaPublicKey;
byte[] publicKey = WhirlpoolProtocol.decodeBytes(confirmInputMixStatusNotification.publicKey64);
if (publicKey != null && publicKey.length > 0) {
    throw new ProtocolException("not expected to receive public key for blind signature from whirlpool server");
    //rsaPublicKey = ClientUtils.publicKeyUnserialize(publicKey);
} else {
    rsaPublicKey = blindSignaturePublicKey;
}

This implementation demonstrates a deliberate security design decision. When the server attempts to send a public key through the confirmInputMixStatusNotification.publicKey64 field, the client immediately throws a ProtocolException and refuses to proceed. The commented-out line shows where the vulnerable code would have been, indicating the developers were explicitly aware of this attack vector and chose to prevent it.

RSA Public Key Management

The secure implementation loads RSA public keys from hardcoded resources during client initialization. In darkjar/src/main/java/com/samourai/whirlpool/client/mix/MixClient.java, the loadBlindSignaturePubKey() method loads keys from predetermined file paths based on the network:

private String getBlindSignaturePubKeyPath() {
    if (FormatsUtilGeneric.getInstance().isTestNet(config.getNetworkParameters())) {
        return "cipher/testnet/blind_signature_public_key.pem";
    } else {
        return "cipher/mainnet/blind_signature_public_key.pem";
    }
}

Hardcoded RSA Public Keys

The client includes two hardcoded RSA public keys stored as PEM files:

Mainnet RSA Public Key (darkjar/src/main/resources/cipher/mainnet/blind_signature_public_key.pem):

Testnet RSA Public Key (darkjar/src/main/resources/cipher/testnet/blind_signature_public_key.pem):

These keys are loaded once during client initialization and used consistently throughout the mixing process, ensuring all clients on the same network use identical RSA parameters for blinding operations.

Cryptographic Implementation Details

The RSA blinding implementation uses the BouncyCastle cryptographic library and follows standard blind signature protocols. The relevant cryptographic operations are handled in darkjar/src/main/java/com/samourai/whirlpool/client/utils/ClientCryptoService.java, which provides methods for computing blinding parameters, performing the blind operation, and unblinding signed data.

The blinding process works as follows: the client generates a random bordereau (a 30-byte random value), blinds it using the hardcoded RSA public key, sends the blinded version to the coordinator for signing, receives the signed blinded bordereau back, and then unblinds it to produce a valid signature that can be verified against the original bordereau. This process ensures that the coordinator cannot link the blinded signature request to the final unblinded signature during output registration.

Security Verification

The implemented fix provides comprehensive protection against the RSA key differentiation attack through multiple security layers:

First, the client architecture ensures deterministic behavior by loading the same RSA public key for all users on the same network. Since the keys are embedded in the client binary, there is no mechanism for the coordinator to influence which key a particular client uses.

Second, the explicit rejection of server-provided keys through exception handling prevents any fallback to vulnerable behavior. If a coordinator attempts to send different keys to different clients, those clients will immediately terminate the connection with a clear error message.

Third, the protocol implementation validates that all participants in a mix are using compatible cryptographic parameters, which would fail if clients were using different RSA keys.

Attack Vector Mitigation

The specific attack vector described in the vulnerability disclosure involved a coordinator sending unique RSA public keys to each client during the CONFIRM_INPUT phase. With different keys, the coordinator could create a mapping between each client's blinded signature and their identity, completely compromising anonymity.

Ashigaru Terminal prevents this attack by implementing a zero-tolerance policy for server-provided keys. The ProtocolException thrown when a server attempts to provide a key ensures that no mix can proceed with heterogeneous cryptographic parameters. This design choice prioritizes security over potential coordinator flexibility, which is the correct approach for a privacy-focused application.

Additionally, the hardcoded key approach ensures that all legitimate coordinators must use the same RSA key pair, creating a cryptographic commons that prevents any single coordinator from implementing differentiation attacks.

Code Quality and Security Practices

The implementation demonstrates good security engineering practices. The commented-out vulnerable code suggests the developers explicitly considered the security implications and chose the safer approach. The use of standard cryptographic libraries (BouncyCastle) and proper error handling indicates a mature approach to security-critical code.

The separation of concerns between key management (MixClient.java), cryptographic operations (ClientCryptoService.java), and protocol logic (MixProcess.java) makes the code easier to audit and verify. The clear exception messages also aid in debugging and security monitoring.

Conclusion

Based on this comprehensive analysis of the Ashigaru Terminal codebase, we can confidently state that Ashigaru Terminal HAS implemented a robust fix for the RSA blinding deanonymization vulnerability. The implementation uses hardcoded RSA public keys embedded in the client application and explicitly rejects any attempts by coordinators to provide alternative keys. This approach completely prevents the attack vector where coordinators could deanonymize users by sending different RSA keys to different clients.

The fix is well-implemented, follows security best practices, and provides strong protection against this specific privacy vulnerability. Users of Ashigaru Terminal can be confident that this particular attack vector has been properly mitigated in the current implementation.

Verification Notes

This security analysis was conducted on the official Ashigaru Terminal v1.0.0 release. The code was analyzed from the downloaded file:

ashicodepbnpvslzsl2bz7l2pwrjvajgumgac423pp3y2deprbnzz7id.onion/Ashigaru/Ashigaru-Terminal/releases/download/v1.0.0/ashigaru_terminal_v1.0.0_x86_64.tar.gz

The authenticity of the software was verified by confirming the signed message of the SHA-256 digests following the instructions at https://ashigaru.rs/download/. The PGP signature was verified using Keybase and confirmed to be signed by "ashigarudev". The SHA-256 hash of the downloaded file was manually verified to match the hash in the signed message.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Linux (Intel/AMD): Ubuntu/Debian
File name: ashigaru_terminal_v1.0.0_amd64.deb
SHA-256 Hash of file: 15081f7f3957b2d60abf1f5c0dc5435d09e3387636b44215688dac2d01b4334f

Linux (Intel/AMD): Standalone
File name: ashigaru_terminal_v1.0.0_x86_64.tar.gz
SHA-256 Hash of file: f0bb53055ac9a0f7712e0de09a08f0acf8aeda59332fff681e0480eae1a744d7

Linux (Intel/AMD): Redhat/CentOS
File name: ashigaru_terminal_v1.0.0_x86_64.rpm
SHA-256 Hash of file: b98c58c389f1124dd26ae0ca5bacc46da5f4c5d98af4e4b64a3a18d2358c4da8

MacOS (Apple M-series)
File name: ashigaru_terminal_v1.0.0_macos_aarch64.dmg
SHA-256 Hash of file: ca85bed92c7281490b08ba2a524e1e595be8531bd8e5a8f7fed2f44403225ac6

MacOS (Intel): 11+
File name: ashigaru_terminal_v1.0.0_macos_x86_64.dmg
SHA-256 Hash of file: 8a67dff12c9c0dafdb175134a4fc73558d71e4bebbc3aafd43d21a8e322ef5d4

Windows 10+
File name: ashigaru_terminal_v1.0.0_windows.zip
SHA-256 Hash of file: 771a6efe91f5eafa22715e6a1f93e8cdfaca3447a1a4c733906f49e95de4db96

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEERF+AeZb3BYa3Fce4oTgGsfoqZ2sFAmhYRNcACgkQoTgGsfoq
Z2s6dhAA5aSK2jkzCuqTjRgeac7UpPwav2eA5w7VJeRHlauL+w69l/fiW6hZtey7
8bKxC6CMaEUtydyvPJU2qyJKujE4sn/kl75/F2JAf0q5yNE0dZAKTgYTPnZ4XChD
lI1ptXZ2/dDcxZU2YoNatNF0Ble48YsN/Te/zxyK5a1qtPxMVr/G2JRSLfUJrObp
GWypPjyy1z+cWfNSOyW6ZhNBCHCr0Kff6VGWjIv6sXBJluay72AgylAMrnS/FWW9
WAQRh3iCRsjXPHDuwlaNsfZ3k8ZRTnnq2HkbIxqDO12HRJnxFS9gbW97cB4fVeCi
bEoTqCYBNQIBNaxKPZkMRVoaAUCdZ9ORXa2YH2316e3G8PC8Ir26yQnofB1UNdDc
drVp5wffD7EP4Whn4shCYbaXxrdQMaHl+9WhP5CspX74B5Dzkh1a7X+F3qfDmRMN
+BHXFXCNAtpnNIhObp+aFrCGVsxxGNUuZ9/09nKsPG20BWHVNgtC/iyZmxFnpOMb
Q3742Ad0T5gdEJRLU6hnI8iGulc3LVZ/er94uFCslcS1VP6ajR38ucscIMy3TnuA
hWvfst9zsspi1rbvNaMWEI9lP7rAPwAC8ISJ7HuLPyFmKHIXw4Ftlrgo8mreFdRS
OsOaEf0fyKNNgwrqswNCM9/falzbIUxQwVDYcmqYCveGmd33UkY=
=iOWZ
-----END PGP SIGNATURE-----

Verified on https://keybase.io/verify as "Signed by ashigarudev"

Manual SHA-256 verification confirmed the hash matches the signed message:

$ sha256sum ashigaru_terminal_v1.0.0_x86_64.tar.gz
f0bb53055ac9a0f7712e0de09a08f0acf8aeda59332fff681e0480eae1a744d7  ashigaru_terminal_v1.0.0_x86_64.tar.gz

Note on AI tools used

For this analysis, I used claude-sonnet-4 as the Agentic AI in VSCodium with the Cline extension.

I encourage you to try to verify these results yourself independently and with different models as well.

RandyMcMillan/ashigaru-vuln-review.md