Skip to main content
Glama

CipherHUB Cryptography Toolkit

ml_dsa_sign

[pqc_signature] 使用 ML-DSA 私钥对消息签名(FIPS 204)。 【双模式】sign_mode 支持 RAW(默认)和 EXTERNAL_MU 两种模式。

  • RAW 模式:直接签名原始消息(liboqs,最大 256 字节)

  • EXTERNAL_MU 模式:先计算 mu = SHAKE-256(tr||M', 64),再通过 OpenSSL 3.5+ mu 模式签名(最大 2048 字节),与 AWS KMS ML-DSA EXTERNAL_MU 语义等价 【消息长度策略】

  • RAW:最大 256 字节,空消息合法

  • EXTERNAL_MU:最大 2048 字节,空消息合法

  • 256 且 <= 2048 字节:使用 EXTERNAL_MU

  • 2048 字节:拒绝 【算法】algorithm 支持 ML-DSA-44 / ML-DSA-65(默认)/ ML-DSA-87。 【参数】

  • private_key_in_hex:ml_dsa_keygen 返回的私钥 hex

  • public_key_spki_in_hex:EXTERNAL_MU 模式必填,ml_dsa_keygen 返回的公钥 hex(SPKI DER)

  • message_in_hex:待签消息 hex

  • context_in_hex:可选上下文 hex(最大 255 字节)

  • sign_mode:RAW 或 EXTERNAL_MU(默认 RAW) 【输出】signature_in_hex、signature_in_base64、algorithm、message_bytes、signature_bytes。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
algorithmNo密码算法名称(具体可选值因工具而异,见工具描述)ML-DSA-65
sign_modeNoML-DSA 签名模式,可选值:RAW(默认,直接签名原文)/ EXTERNAL_MU(先计算 mu 再签名,与 AWS KMS 语义等价)RAW
context_in_hexNoML-DSA 上下文的十六进制字符串(可选,最大 255 字节)
message_in_hexNo消息的十六进制字符串(空字符串表示空消息)
private_key_in_hexNoML-DSA 私钥的十六进制字符串(PKCS#8 DER 编码)
public_key_spki_in_hexNoML-DSA 公钥的十六进制字符串(SPKI DER 或裸公钥均可)

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure and does so excellently. It reveals the exact message-length limits, the auto-switch behavior between RAW and EXTERNAL_MU, the acceptance of empty messages, the algorithm options, and the full output field set. This goes well beyond a simple 'sign' statement and gives the agent a reliable mental model.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively long but well-structured with clear section headers and bullet points. It is front-loaded with the tool's purpose, then systematically covers modes, length policy, algorithm, parameters, and output. While some redundancy exists (e.g., length limits repeated for each mode), every sentence contributes necessary information, making it concise enough for its complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given six parameters, dual modes, length constraints, and no output schema, the description is remarkably complete. It explicitly lists all output fields, describes when each parameter is needed, covers edge cases like empty messages and oversize rejection, and even adds domain context (FIPS 204 and AWS KMS equivalence). There are no obvious missing pieces that an agent would need for successful invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Though schema coverage is 100%, the schema descriptions are generic (e.g., '十六进制字符串'). The tool description adds crucial semantics: private_key_in_hex is sourced from ml_dsa_keygen, public_key_spki_in_hex is mandatory only for EXTERNAL_MU, context_in_hex is capped at 255 bytes, and sign_mode values are explained with their behavioral consequences. This is essential for correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with '使用 ML-DSA 私钥对消息签名(FIPS 204)', which is a clear and specific verb+resource statement. It distinguishes the tool from siblings like ml_dsa_verify and ml_dsa_compute_mu by clearly marking it as the signing operation, and even elaborates the two signing modes, leaving no doubt about its primary function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance: RAW mode for messages up to 256 bytes, EXTERNAL_MU for up to 2048 bytes, an automatic switching rule for 256–2048 bytes, and a rejection rule above 2048 bytes. It also states that public_key_spki_in_hex is required only in EXTERNAL_MU mode, giving the agent clear when-to-use and prerequisite information.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Most tools target a distinct algorithm+operation pair (e.g., rsa_sign vs sm2_sign vs ml_dsa_sign), and descriptions are detailed. However, block_cipher and stream_cipher both perform symmetric encryption, and ecc_key_exchange and hybrid_kex overlap as key exchange, requiring careful reading to distinguish.

Naming Consistency3/5

Naming is inconsistent across algorithm families: key generation mixes generate_ecc/generate_rsa with ml_dsa_keygen/ml_kem_keygen, and encryption mixes rsa_encryption/sm2_encryption with block_cipher/stream_cipher. Within each family (e.g., rsa_sign/rsa_verify, ml_dsa_sign/ml_dsa_verify), names are predictable, but the overall pattern is not uniform.

Tool Count2/5

32 tools is far above the typical 3-15 range for a well-scoped server. While every tool has a distinct function, the large surface makes the set heavy and harder to navigate, especially with multiple algorithm families and niche utilities.

Completeness5/5

The toolkit gives comprehensive coverage: key generation, encryption/decryption, signing/verification for RSA, ECC, SM2, ML-DSA, ML-KEM, plus symmetric ciphers, hashing, and key exchange. Full workflows are supported with no dead ends, and even helper tools for debugging are included.