# QSL卡片的数字签名 1. 前言近年来, 越来越多的电台不再发送纸质QSL卡片, 转而使用电子版QSL卡片或使用在线日志服务.我们意识到在线日志服务过于依赖某些中心化网站, 且不足以展示电台个性, 因而无法完全取代纸质QSL卡片. 同时, 不含有签名电子版QSL卡片极易被伪造, 不能独自有效证明通联的真实性. 本文提出了一种可行的数字签名方案, 在不影响电子QSL卡片功能、个性化QSL卡片的前提下, 对QSL卡片上的信息进行数字签名. 2. 范围本文定义了一种对数字QSL卡片进行数字签名的方法. 但本文不对公钥的分发、信任和吊销流程做出要求. 3. 要求本文提出的数字签名满足以下要求： i. 数字签名可以被方便的识别、验证且不依赖中心化第三方服务. ii. 数字签名不对QSL卡片设计、美观性产生显著影响 iii. 接收方对收到的QSL卡片进行格式转换等操作不影响签名有效性 iv. 接收方可以打印含有数字签名的QSL卡片, 打印后的卡片可以被独立验证. 4. 规范性引用文件 GB/T 1.1-2020 标准化工作导则第1部分：标准化文件的结构和起草规则. 本文中粗体“**（不）应**”、“**（不）宜**”、“**可**、**不必**”、“**（不）能**”、“**（不）可能**”的使用符合《GB/T 1.1-2020 标准化工作导则第1部分：标准化文件的结构和起草规则》中附录C的定义. 5. 定义 5.1 基本定义 - **字节** 由8位二进制组成的符号 - **签名有效载荷** 实际被签名的数据中, 有意义的部分 - **被签名数据** 数字签名算法的输入 - **签名** 由文件头、签名算法描述和数字签名等部分组成的文件 5.2 SSH消息本文多次描述SSH消息结构体, 在本文的语义下, 用到的类型有: - `ssh-string` 四个字节、大端序表示的字符串长度和由前述长度指定的字节串, 串中可以有Unicode NUL字符, 串位不含有多余的Unicode NUL字符. - `uint32` 四个字节、大端序表示的32位无符号整数. - `byte[N]` N个字节, 无其它信息 - `varint` 变长数字，其最高位表示是否为该数最后一位（1为非，0为是），如150表示为`10010110 00000001`，16进制转写为`96 01`. 注：此类型非SSH消息定义. 6. 具体实现 6.1. 数字签名算法选择在本设计中, 我们将使用SSH密钥对QSL卡片上的信息进行数字签名, 这是因为SSH的签名消息相比于PGP签名后的消息更小, 更易于在QSL卡片上展示. 对于具体的算法选择, 我们使用Ed25519椭圆曲线密码, 这是因为Ed25519的公钥大小和签名大小都足够小, 可以更方便地嵌入在QSL卡片中. 签名内容不包含被签名的信息. 6.2 数字签名有效载荷ADIF 数字签名的有效载荷为一ADIF文件, 其可以从QSL卡片上所展示的信息唯一构造. 6.2.1 构造ADIF 被数字签名的信息使用ADIF格式, 它人类可读的特性使得它可以被简单地构造, 同时由于数字签名不包含被签名的信息, 被签名信息的长度对签名的长度没有影响. 以下信息会**依次**包含在ADIF数据当中： > - QSO_DATE > - TIME_ON > - BAND > - CALL > - MODE > - STATION_CALLSIGN > - OPERATOR 其中, `QSO_DATE`为8位数字（年、月、日）表示的协调时（UTC）日期, `TIME_ON`为6位数字（时、分、秒）表示的协调时（UTC）时间, 无论QSL卡片上是否印刷出了通联的秒数, 时间都应*截断*至整分钟（即将秒数简单置0）. 上述各项均**应**用大写字母.如果QSL卡片上没有指明操作员, 则`OPERATOR`为不含任何修饰的`STATION_CALLSIGN`. 如, 以下的QSL卡片： ``` TO BB0BBB DE B4/BG6TOE Date Time (BJT) / Freq / Mode / RST 2023-01-01 02:00:59 14.245 MHz USB 59 59 [x]PSE [ ]TNX QSL VY TU! 73 ``` 其ADIF转写为: ``` 2022123118000020MBB0BBBUSBB4/BG6TOEBG6TOE ``` 该文件的`xxd`转储为: ``` 00000000: 3c51 534f 5f44 4154 453a 383e 3230 3232 2022 00000010: 3132 3331 3c54 494d 455f 4f4e 3a36 3e31 12311 00000020: 3830 3030 303c 4241 4e44 3a33 3e32 304d 8000020M 00000030: 3c43 414c 4c3a 363e 4242 3042 4242 3c4d BB0BBBUSBB4/ 00000060: 4247 3654 4f45 3c4f 5045 5241 544f 523a BG6TOEBG6TOE ``` 需要注意：文末**不应**有任何多余字符（含换行、空格、制表符等）, 即``后不含有任何字符. 6.2.2 构造含有多个QSO的ADIF信息若一张QSL卡片上含有多个QSO, 则对应的ADIF文件**应**按照通联的时间顺序, 直接拼接各个QSO的ADIF数据，文末**不应**有任何多余字符（含换行、空格、制表符等）, 即, 以最后一个QSO的``后不含有任何字符. 6.3 签名数据 6.3.1 展示方式签名数据**可以**在经由Base64编码后直接显示在QSL卡片上. 以文本形式表示的签名数据**宜**使用等宽字体排版. 使用的字体**应**足以分辨`i`、`l`、`1`, `O`、`o`、`0`， `5`、`S`等Base64使用的编码字符. 签名数据**可以**在经由Base32编码后直接显示在QSL卡片上. 以文本形式表示的签名数据**宜**使用等宽字体排版. 签名数据**宜**在经由Base45编码后包含于QR Code中. 此时签名数据**应**为独立的二维码. 该二维码**可**使用除黑、白之外的颜色, 但**应**用浅色区域作为二维码背景、深色作为二维码前景色. 为保证生成二维码识别成功率, 使用QR Code为载体的签名数据**不宜**使用Base45以外的编码. 6.3.2 二进制签名数据格式二进制签名为SSH签名结构体, 其格式为： ``` byte[6] MAGIC_PREAMBLE uint32 SIG_VERSION ssh-string publickey ssh-string namespace ssh-string reserved ssh-string hash_algorithm ssh-string signature ``` 其中：`MAGIC_PREAMBLE`为`SSHSIG`, `SIG_VERSION`为1. `publickey`为序列化后的签名密钥的公钥. `namespace`**应**为`adif-qslv1`. `reserved`**应**为空. `hash_algorithm`**应**为`sha512`(即, 总是使用SHA512对数据进行签名). `signature`为SSH正文的签名, 使用`ssh-ed25519`算法. 6.3.3 签名的精简为了使得签名内容更容易被展示，**可以**对签名内容进行精简。精简之后的签名仅包含头部及ED25519签名数据。其中，头部固定为`DQSLV1`，后紧跟64字节的ED25519签名`X||Y`。当接收方获得开头为`DQSLV1`的签名数据时，**应**将其展开为标准签名格式进行校验。 6.3.4 被签名内容实际被签名的内容为： ``` byte[6] MAGIC_PREAMBLE ssh-string namespace ssh-string reserved ssh-string hash_algorithm ssh-string H(message) ``` 其中：`MAGIC_PREAMBLE`为`SSHSIG`, `SIG_VERSION`为1. `publickey`**应**为序列化后的签名密钥的公钥.`namespace`**应**为`adif-qslv1`. `reserved`**应**为空. `hash_algorithm`**应**为`sha512`(即, 总是使用SHA512对数据进行签名). `message`4.2 节所描述的ADIF文件, `H(message)`为其SHA-512算法下的指纹. 将此内容经由SSH Message格式编码后, 使用Ed25519私钥和`ssh-ed25519`进行签名，即得到4.3.1节中的`signature`字段. 7. 附加原始QSO数据签名前可附加原始QSO数据，以方便机器直接识别、校验。原始QSO数据为精简表示的极小QSO元数据，包含以下字段：通联时间、通联波段、通联模式、收方呼号、发方呼号、OP。其格式为： ``` byte[6] MAGIC_PREAMBLE varint call varint station_callsign varint operator ssh-string data ``` 其中，call、station_callsign、operator为呼号的37进制数表示（见下表）： ``` +---------++----+----++----+----+ |Char|Num ||Char|Num ||Char|Num | +---------++----+----++----+----+ | 0 | 0 || C | 12 || O | 24 | | 1 | 1 || D | 13 || P | 25 | | 2 | 2 || E | 14 || Q | 26 | | 3 | 3 || F | 15 || R | 27 | | 4 | 4 || G | 16 || S | 28 | | 5 | 5 || H | 17 || T | 29 | | 6 | 6 || I | 18 || U | 30 | | 7 | 7 || J | 19 || V | 31 | | 8 | 8 || K | 20 || W | 32 | | 9 | 9 || L | 21 || X | 33 | | A | 10 || M | 22 || Y | 34 | | B | 11 || N | 23 || Z | 35 | | / | 36 |+----+----++----+----+ +----+----+ ``` 如`B1CRA`表示为`11 * 37^4 + 1 * 37^3 + 12 * 37^2 + 27 * 37 + 10 = 20683861` 其中，data为多个最小QSO拼接而成的字符串，其格式为 ``` varint QSO Timestamp varint Band byte[8] Mode ``` 其中QSO Timestamp为协调时1970年元旦以来的秒数（但精确到分钟）。Band为波段对应频率的低端（千赫兹）数，如20米波段表示为14000。Mode为表示模式的字符串，不足8字节用`\0`补全。 8. 示例假设 `ST4TION` 使用电台 `C3SHI` 与 `TE5T` 在北京时2023年1月1日10:05:30，在20米段上使用MFSK调制方式完成了一次通联完成了一次通联. 现`ST4TION`欲以其自己名义签名如下QSL卡片: ``` TO TE5T DE C3SHI OP ST4TION Date Time (BJT) / Freq / Mode / RST 2023-01-01 10:00 14.074 MHz MFSK 59 59 [x]PSE [ ]TNX QSL VY TU! 73 ``` `ST4TION`的私钥为: ``` -----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW QyNTUxOQAAACADTnJZ6blw4CsqVoxzv9iWVVl0ycM8Neqb9QvTyvKqCAAAAJiuWf0orln9 KAAAAAtzc2gtZWQyNTUxOQAAACADTnJZ6blw4CsqVoxzv9iWVVl0ycM8Neqb9QvTyvKqCA AAAEDgyhqzLTK6rmVqjfvHpvHPYJzdeVuDhRo93XO98jDl1QNOclnpuXDgKypWjHO/2JZV WXTJwzw16pv1C9PK8qoIAAAAFW1hdHN1QEJHNlRPRS1Ob3RlYm9vaw== -----END OPENSSH PRIVATE KEY----- ``` 其公钥为: ``` ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIANOclnpuXDgKypWjHO/2JZVWXTJwzw16pv1C9PK8qoI ``` 则其构造如下的ADIF数据(签名有效载荷): ``` 2023010102050020MTE5TMFSKC3SHIST4TION ``` 需要注意: - 卡面上的北京时间应转换为协调世界时 - 生成的ADIF文件中的秒被无条件截断至0 - 波段从14.074得出, 为20M - RST不包含在ADIF当中该ADIF的`SHA512`指纹为: ``` 5d10 5c01 843a 14ad 9852 5f40 f9e9 36d5 0e00 56b0 d98b a04f 6d1d d337 efb8 11bb f397 52d3 6233 6b64 ab8f 430f cf6b e95d bfb4 39b9 26c8 fb39 9cbf 414a b386 a1b4 ``` 构造如下被签名数据: ``` 00000000: 5353 4853 4947 0000 000a 6164 6966 2d71 SSHSIG....adif-q 00000010: 736c 7631 0000 0000 0000 0006 7368 6135 slv1........sha5 00000020: 3132 0000 0040 5d10 5c01 843a 14ad 9852 12...@].\..:...R 00000030: 5f40 f9e9 36d5 0e00 56b0 d98b a04f 6d1d _@..6...V....Om. 00000040: d337 efb8 11bb f397 52d3 6233 6b64 ab8f .7......R.b3kd.. 00000050: 430f cf6b e95d bfb4 39b9 26c8 fb39 9cbf C..k.]..9.&..9.. 00000060: 414a b386 a1b4 AJ.... ``` 应用前述私钥及`ssh-ed25519`签名方式进行签名: ``` 00000000: 0000 0053 0000 000b 7373 682d 6564 3235 ...S....ssh-ed25 00000010: 3531 3900 0000 4082 84f9 edcb 8ef8 6cdf 519...@.......l. 00000020: 5bee c347 6762 84ea ce4b 4644 6429 6900 [..Ggb...KFDd)i. 00000030: 4139 6e79 9bbd f74c 2b94 0e53 541e 4dfa A9ny...L+..ST.M. 00000040: 94db 704a 9b77 aad1 4dcd 2e5d 6b3f 30c6 ..pJ.w..M..]k?0. 00000050: 44c6 7e84 ca4d 07 D.~..M. ``` 构造签名: ``` 00000000: 5353 4853 4947 0000 0001 0000 0033 0000 SSHSIG.......3.. 00000010: 000b 7373 682d 6564 3235 3531 3900 0000 ..ssh-ed25519... 00000020: 2003 4e72 59e9 b970 e02b 2a56 8c73 bfd8 .NrY..p.+*V.s.. 00000030: 9655 5974 c9c3 3c35 ea9b f50b d3ca f2aa .UYt..

技术有点深奥看不懂（我想问一下，数字签名是和电子qsl卡一起发送一张卡片文件和一份签名文件还是直接发送卡片文件，其中包含数字签名怎么感觉有点像电子发票的发票章hhh

@"YofoaStudio"#p2914 不是对QSL卡签名，而是对卡上的信息签名所以可以嵌入也可以分开其实就是类似于发票上那个东西

@"BG8LGP"#p2928 在写因为是标准的ssh签名所以也可以构造好adif文件之后用ssh来签 `ssh-keygen -Y sign -f ~/.ssh/id_ed25519 -n adif-qslv1 qsos.adif`

之前想过 GPG，但是产物太大了不好弄到卡片上，蹲楼主一套程序

@"BG2ELG"#p2932 我之前也考虑过用GPG，事实上我有用过GPG签QSL，也是因为签名太大了放弃我最终的想法是能够用针式打印机打在卡片上，激光或者喷墨打印机印这个二维码肯定绰绰有余，热转印可能跟针式打印机效果差不多？用Base45也是为了能有更小的二维码尺寸（10个Bit对应二维码上11个像素）效率高达91% 我也在考虑用Datamatrix或者PDF417（等我搞一个针式打印机测试一下）这个RFC主要目的还是定义数字签名的内容和方法，因为我觉得肯定要避免QSL正文编码进二维码，但这样就要求能确定性地根据卡面信息手搓被签名的内容

@"erjiaqing"#p2931 我在研究基于区块链的通联日志记录与eQSL交换的实现方法，你这个项目正好对应了我的签名与验证模块。或许可以一起研究研究？

@"BG8LGP"#p2937 可以啊我正好也在思考DigitalQSL与公钥的交换方式

[RFC] QSLカードのデジタル署

erjiaqing

QSLカードのデジタル署

まえがき

近年、多くの電波局が紙のQSLカードの使用を減らし、電子版QSLカードやオンラインログサービスを使用するようになった。しかし、オンラインログサービスは特定のウェブサイトに依存し、電波局の個性を十分に表現できないため、完全に紙のQSLカードを代替することはできないと認識した。

同時に、署名付きの電子版QSLカードは容易に偽造されるため、単独で通信の真正性を証明することができません。本稿では、電子QSLカードの機能や個別のQSLカードとしての機能を損なうことなく、QSLカード上の情報をデジタル署名するための実現可能な方法を提案します。

範囲

本論文では、デジタルQSLカードへのデジタル署名を行う方法を定義しています。ただし、本論文は公開鍵の配布、信頼性、および無効化プロセスの要件について規定していません。

要件

本文で提案されているデジタル署名は、以下の要件を満たします。

i. デジタル署は、容易に識別・検証でき、中央集権的なサードパーティサービスへの依存を必要としません。
ii. デジタル署は、QSLカードのデザインや美観に顕著な影響を与える。
iii. 受信者が受信したQSLカードのフォーマット変換などの操作が、署名の有効性に影響を与えないこと。
iv. 受信者は、数字による署名を含むQSLカードを印刷し、印刷されたカードは独立して検証可能。

基準となる引用文書

GB/T 1.1-2020 規格化作業指針第1部：規格文書の構造と作成規則

本文中の太字で「（禁止）”、“（推奨されない）”、“可能です、不要”、“（できない）”、“（不可能）「の使用は、「GB/T 1.1-2020 規格における標準化作業指針第1部：標準化文書の構造と作成規則」の付録Cで定義されているものに準拠しています。

定義

5.1 基本定義

バイト 8ビットのバイナリで構成された記号
署名付きのデータ 実際に署名されたデータの中で、意味のある部分
署名されたデータ デジタル署名アルゴリズムの入力
署名ファイルヘッダー、署名アルゴリズムの説明、およびデジタル署名などの要素で構成されるファイル。

5.2 SSHメッセージ

本稿では、SSHメッセージ構造体が複数回にわたって記述されており、ここで使用されているデータ型は以下の通りです。

ssh-string 4バイト、ビッグエンディアン形式で表現された文字列の長さと、その長さで指定されたバイト列。このバイト列には、Unicode NULL文字を含むことができるが、複数のUnicode NULL文字は含まれない。
uint32 4バイト、ビッグエンディアン形式で表現される32ビットの符号なし整数。
バイト\[N] Nバイト、その他の情報なし
varint 可変長の数値。上位ビットは、その数値が最後の桁であるかどうかを示す（1は「否」、0は「はい」）。例えば、150 は以下のように表現されます。10010110 00000001、16進数を表記96 01注：このタイプはSSHメッセージの定義ではありません。
具体的な実装

6.1. デジタル署名アルゴリズムの選択

本設計では、SSHの鍵を使用してQSLカードに記載された情報をデジタル署名します。これは、SSHの署名メッセージがPGPで署名されたメッセージよりも小さいため、QSLカードに表示しやすいためです。

具体的なアルゴリズムの選択については、Ed25519という楕円曲線暗号を使用しました。これは、Ed25519の公開鍵と署名のサイズが小さいため、QSLカードに組み込みやすいからです。

署名欄には、署名対象となる情報が含まれていません。

6.2 デジタル署のADIFデータ

デジタル署のペイロードは、QSLカードに表示される情報のみから構成される1つのADIFファイルです。

6.2.1 ADIFの構築

この情報には、デジタル署名を使用し、ADIF形式で表現されています。これにより、人間が読みやすく、簡単に構造化することができます。また、デジタル署名は、署名された情報そのものではなく、そのため、署名の長さは、署名された情報の長さに影響しません。

以下の情報は順番にADIFデータに含まれるもの：

QSO_DATE

TIME_ON

BAND

CALL

MODE

STATION_CALLSIGN

OPERATOR

その中で、 QSO_DATE8桁の数字（年、月、日）で表される協定世界時（UTC）の日付 TIME_ON6桁の数字（時、分、秒）で表される協定世界時刻（UTC）、QSLカードに通信の秒数が印刷されていなくても、時間は切断整分（つまり、秒数を0にする）。

上記すべての項目について対応大文字で表記してください。もしQSLカードにオペレーターの名前が記載されていなければ、OPERATOR修正なしのSTATION_CALLSIGN.

例えば、以下のQSLカード：

BB0BBB 宛
DE B4/BG6TOE

日時 (BJT) / 周波数 / モード / RST
2023-01-01 02:00:59   14.245 MHz   USB    59 59

[ ]PSE [ ]TNX QSL

VY TU! 73

そのADIF形式のデータを以下のように変換します：

<QSOの日付：8>20221231<時間：6>180000<バンド：3>20M<コール：6>BB0BBB<モード：3>USB<ステーションのコールサイン：9>B4/BG6TOE<オペレーター：6>BG6TOE<EOR>

このドキュメントxxd出力形式：

3c51 534f 5f44 4154 453a 383e 3230 3232 → "Wi-Fi"  <QSOの日付：8>2022
00000010: 3132 3331 3c54 494d 455f 4f4e 3a36 3e31  "http://example.com/file.pdf"<時間：6>00000020: 3830 3030 303c 4241 4e44 3a33 3e32 304d  "http://www.example.com/file.pdf" 80000<バンド：3>20M
00000030: 3c43 414c 4c3a 363e 4242 3042 4242 3c4d  <コール：6>BB0BBB<M
00000040: 4f44 453a 333e 5553 423c 5354 4154 494f  ODE:3>USB<STATIO
00000050: 4e5f 4341 4c4c 5349 474e 3a39 3e42 342f  コールサイン:9>B4/
00000060: 4247 3654 4f45 3c4f 5045 5241 544f 523a  BG6TOE<オペレーター：
00000070: 363e 4247 3654 4f45 3c45 4f52 3e 6>BG6TOE<EOR>

注意点：本文末避けるべき不要余った文字（改行、スペース、タブなどを含む）<EOR>この文字列には、何も含まれていません。

6.2.2 複数のQSOを含むADIF形式の情報を構築する

もし1枚のQSLカードに複数のQSOが含まれている場合、対応するADIFファイルは…対応通聯のタイムスタンプに従い、各QSOのADIFデータを直接連結します。避けるべき不要含まれる文字（改行、スペース、タブなど）<EOR>この文字列には、何も含まれていません。

6.3 署名データ

6.3.1 プレゼンテーション方法

署名データ可能ですベース64エンコードされた後、直接QSLカードに表示される署名データ。いいですね等幅フォントによるレイアウトを使用。使用するフォント対応区別できるi、l、1, O、o、0， 5、SBase64で使用されるエンコード文字。

署名データ可能ですBase32エンコード後に直接QSLカードに表示される署名データ。いいですね等幅フォントを用いたレイアウトを使用してください。

署名データいいですねBase45でエンコードされ、QRコードに格納された署名データ。対応個別のQRコード用。このQRコード可能です黒や白以外の色を使用するが、対応明るい領域をQRコードの背景として、暗い領域をQRコードの色として使用する。

生成時のQRコード認識の成功率を確保するために、QRコードをデータ格納媒体として使用する。推奨されませんBase45以外のエンコーディングを使用する。

6.3.2 バイナリ署名データ形式

二進位署名には、SSH署名の構造体が使用され、その形式は以下の通りです。

`byte[6]`    MAGIC\_PREAMBLE
uint32   SIG\_VERSION
ssh-string  publickey
ssh-string  namespace
ssh-string  reserved
ssh-string  hash\_algorithm
ssh-string  signature

その中には：MAGIC_PREAMBLE～のためにSSHSIG, SIG_VERSION1.

publickeyシリアライズされた署名キーの公開鍵。

namespace対応～のためにadif-qslv1.

reserved対応空です。

hash_algorithm対応～のためにsha512（つまり、常にデータをSHA512で署名すること）。

signatureSSHメッセージの署名に使用ssh-ed25519アルゴリズム。

6.3.3 署名の簡略化

署名の内容をより分かりやすく表示できるように、可能です署名の内容を簡潔化する。簡略化した署名は、ヘッダーとED25519署名データのみを含む。その際、ヘッダーは固定されている。DQSLV1、それに続いて64バイトのED25519署名X ｜ Y。受信側が「」で始まるメッセージを受信した場合DQSLV1署名データを取り扱う際に、対応これを標準の署名形式に展開し、検証します。

6.3.4 署名されたコンテンツ

実際に署名された内容は以下の通りです：

`byte[6]` MAGIC\_PREAMBLE
`ssh-string` namespace
`ssh-string` reserved
`ssh-string` hash\_algorithm
`ssh-string` H(message)

その中には：MAGIC_PREAMBLE～のためにSSHSIG, SIG_VERSION1.

publickey対応シリアライズされた署名キーの公開鍵。namespace対応～のためにadif-qslv1.

reserved対応空です。

hash_algorithm対応～のためにsha512（つまり、常にデータをSHA512で署名すること）。

message4.2で説明されているADIFファイル、 H（メッセージ）そのSHA-512アルゴリズムに基づくフィンガープリント。

この内容をSSHメッセージ形式でエンコードし、Ed25519の秘密鍵を使用してssh-ed25519署名を行うことで、4.3.1節の内容を取得できます。signatureフィールド。

元の QSOデータを追加

署名には、機械による直接認識・検証を容易にするため、元のQSOデータを付加することができます。元のQSOデータは、以下のフィールドを含む、簡潔な最小限のQSOメタデータです：通信時間、通信帯域、通信モード、受信側コールサイン、送信側コールサイン、OP。

その形式は以下の通りです：

`MAGIC_PREAMBLE` (6 バイト)
`call` (varint)
`station_callsign` (varint)
`operator` (varint)
`data` (ssh 文字列)

これらのうち、「call」、「station\_callsign」、「operator」は、それぞれ呼号を37進数で表現しています（下記参照）。

+---------++----+----++----+----+
|文字|番号||文字|番号||文字|番号 |
+---------++----+----++----+----+
| 0  | 0  || C  | 12 || O  | 24 |
| 1  | 1  || D  | 13 || P  | 25 |
| 2  | 2  || E  | 14 || Q  | 26 |
| 3  | 3  || F  | 15 || R  | 27 |
| 4  | 4  || G  | 16 || S  | 28 |
| 5  | 5  || H  | 17 || T  | 29 |
| 6  | 6  || I  | 18 || U  | 30 |
| 7  | 7  || J  | 19 || V  | 31 |
| 8  | 8  || K  | 20 || W  | 32 |
| 9  | 9  || L  | 21 || X  | 33 |
| A  | 10 || M  | 22 || Y  | 34 |
| B  | 11 || N  | 23 || Z  | 35 |
| /  | 36 |+----+----++----+----+

例えばB1CRA以下のように表示します。11 * 37^4 + 1 * 37^3 + 12 * 37^2 + 27 * 37 + 10 = 20683861

その中で、「data」は複数の最小のQSOを繋ぎ合わせた文字列であり、その形式は以下の通りです。

varint 通信時間
varint 帯域
バイト[8] モード

その中で、QSOのタイムスタンプは協定世界時(BJT)1970年1月1日から経過した秒数（ただし、分単位で正確な値）。バンドは、対応する周波数の下限（キロヘルツ）を示す数値であり、例えば20メートルのバンドの場合、14000と表記されます。モードは、通信方式を示す文字列です。8バイト未満の場合は\0補完

仮定 ST4TION ラジオを使用する C3SHI ～と TE5T 2023年1月1日午前10時05分30秒（北京時間）、20メートルの帯域でMFSK方式を用いて通信を確立しました。現在ST4TION以下のQSLカードに、自身の署名を記入してください。

TE5T宛　DE C3SHI 局からの情報

日付 時間 (SSH) / 周波数 / モード / RST
2023-01-01 10:00 14.074 MHz MFSK 59 59

[ ]PSE [X]TNX QSL

VY TU！73

ST4TION私の秘密鍵は：

-----BEGIN OpenSSH プライベートキー-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW
QyNTUxOQAAACADTnJZ6blw4CsqVoxzv9iWVVl0ycM8Neqb9QvTyvKqCAAAAJiuWf0orln9
KAAAAAtzc2gtZWQyNTUxOQAAACADTnJZ6blw4CsqVoxzv9iWVVl0ycM8Neqb9QvTyvKqCA
AAAEDgyhqzLTK6rmVqjfvHpvHPYJzdeVuDhRo93XO98jDl1QNOclnpuXDgKypWjHO/2JZV
WXTJwzw16pv1C9PK8qoIAAAAFW1hdHN1QEJHNlRPRS1Ob3RlYm9vaw==
-----END OpenSSH プライベートキー-----

その公開鍵は：

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIANOclnpuXDgKypWjHO/2JZVWXTJwzw16pv1C9PK8qoI

その場合、以下の形式のADIFデータ（有効な署名付きペイロード）となります。

<QSOの日付：8>20230101<時間：6>020500<バンド：3>20M<コール：4>TE5T<モード：4>MFSK<ステーションのコールサイン：5>C3SHI<オペレーター：7>ST4TION<EOR>

注意点：

カード表面に記載されている北京時間（現地時間）は、協定世界時(ADIF)に変換する必要があります。
生成されたADIFファイル内の秒数が、無条件に0に切り捨てられる。
波長は14.074から算出され、20MHzとなります。
RSTはADIFに含まれていません。

このADIFデータSHA512指紋は：

5d10 5c01 843a 14ad 9852 5f40 f9e9 36d5
0e00 56b0 d98b a04f 6d1d d337 efb8 11bb
f397 52d3 6233 6b64 ab8f 430f cf6b e95d
bfb4 39b9 26c8 fb39 9cbf 414a b386 a1b4

以下の形式で署名されたデータを作成します：

00000000: 5353 4853 4947 0000 000a 6164 6966 2d71 SSHSIG....adif-q
00000010: 736c 7631 0000 0000 0000 0006 7368 6135 slv1........sha5
00000020: 3132 0000 0040 5d10 5c01 843a 14ad 9852 @...].\..:...R
00000030: 5f40 f9e9 36d5 0e00 56b0 d98b a04f 6d1d _@..6...V....Om.
00000040: d337 efb8 11bb f397 52d3 6233 6b64 ab8f .7......R.b3kd..
00000050: 430f cf6b e95d bfb4 39b9 26c8 fb39 9cbf C..k.]..9.&..9..
00000060: 414a b386 a1b4 AJ....

上記で示した秘密鍵を使用してください。ssh-ed25519署名の方法：

00000000: 0000 0053 0000 000b 7373 682d 6564 3235  ...S....ssh-ed25
00000010: 3531 3900 0000 4082 84f9 edcb 8ef8 6cdf  519...@.......l.
00000020: 5bee c347 6762 84ea ce4b 4644 6429 6900  [..Ggb...KFDd)i.
00000030: 4139 6e79 9bbd f74c 2b94 0e53 541e 4dfa  A9ny...L+..ST.M.
00000040: 94db 704a 9b77 aad1 4dcd

署名形式：

00000000: 53 53 48 53 49 47 00 00 01 00 00 33 00 00 SSHSIG.......3..
00000010: 0b 73 73 68 2d 65 64 32 35 35 31 39 00 00 ssh-ed25519...
00000020: 20 03 4e 72 59 e9 b9 70 e0 2b 2a 56 8c 73 bfd8 .NrY..p.+*V.s..
00000030: 96 55 59 74 c9 c3 3c 35 ea 9b f5 0b d3 ca f2 aa .<5........
00000040: 0800 0000 0a61 6469 662d 7173 6c76 3100  .....adif-qslv1.
00000050: 0000 0000 0000 0673 6861 3531 3200 0000  .......sha512...
00000060: 5300 0000 0b73 7368 2d65 6432 3535 3139  S....ssh-ed25519
00000070: 0000 0040 8284 f9ed cb8e f86c df5b eec3  ...@.......l.[..
00000080: 4767 6284 eace 4b46 4464 2969 0041 396e  Ggb...KFDd)i.A9n
00000090: 799b bdf7 4c2b 940e 5354 1e4d fa94 db70  y...L+..ST.M...p
000000a0: 4a9b 77aa d14d cd2e 5d6b 3f30 c644 c67e  J.w..M..]k?0.D.~
000000b0: 84ca 4d07 ..M

簡潔な署名：

00000000: 4451 534c 5631 8284 f9ed cb8e f86c df5b DQSLV1.......l.[
00000010: eec3 4767 6284 eace 4b46 4464 2969 0041 ..Ggb...KFDd)i.A
00000020: 396e 799b bdf7 4c2b 940e 5354 1e4d fa94 9ny...L+..ST.M..
00000030: db70 4a9b 77aa d14d cd2e 5d6b 3f30 c644 .pJ.w..M..]k?0.D
00000040: c67e 84ca 4d07 ~..M.

署名のBase64エンコード：

U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgA05yWem5cOArKlaMc7/YllVZdMnDPDXq
m/UL08ryqggAAAAKYWRpZi1xc2x2MQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQyNTUxOQAA
AECChPnty474bN9b7sNHZ2KE6s5LRkRkKWkAQTlueZu990wrlA5TVB5N+pTbcEqbd6rRTc0uXWs/
MMZExn6Eyk0H

簡略化された署名の Base64 エンコード：

RFFTTFYxgoT57cuO+GzfW+7DR2dihOrOS0ZEZClpAEE5bnmbvfdMK5QOU1QeTfqU23BKm3eq0U3N
Ll1rPzDGRMZ+hMpNBw==

署名されたBase45エンコード:

1OAK69*B9000100000610000B00ZQET7D CSF6RW6C97000524C-9MGB.JNCFS%F50YHHBOA0J+DB MPNR7TTT1:U%YQMUUN010002E1AVCC-CIFE1WDY86000000000V 0 8DRW6KE60008MA0006K1OQEBX50UCVW61A6000J10MMG QV0XPBIVTASD8U919KKCZUTAN93T8QA5K10WB7 GFV0OES9CWI2OAH$3NUVGXRJJ9Y5FVKQB.PK BL:7-2P94PJZG9X9

簡潔な署名用のBase45エンコード：

TS8*NAF+AMMG QV0XPBIVTASD8U919KKCZUTAN93T8QA5K10WB7 GFV0OES9CWI2OAH$3NUVGXRJJ9Y5FVKQB.PK BL:7-2P94PJZG9X9

情報提供のための参照ファイル

RFC4634 米国標準のハッシュアルゴリズム（SHAおよびHMAC-SHA）

RFC4648 Base16、Base32、および Base64 のデータエンコーディング

RFC8709 Ed25519 および Ed448 の公開鍵アルゴリズム、セキュアシェル（SSH）プロトコル用

RFC9285 Base45 データエンコーディング

ADIF アマチュア向けデータ交換形式（ADIF）仕様

bh2vrn

erjiaqing TOE大佬开发新QSL啦，以下内容可能和本帖不太相关，请原谅。之前试过区块链QSL，考虑到推广使用方面，可能还有很长一段路要走~~（关键是现在好少有人用web3.0啊）~~，不过这个技术方案真是太酷啦。其实有瞎想过量子密钥分发哈哈哈哈，不过那就是几年之后的事情了，加油，73

YofoaStudio

技術的な内容が難解で理解できない。
「デジタル署は、電子QSLカードと一緒に、一枚のファイルと署名ファイルを送信するのか？」
直接、カードファイル（デジタル署名を含む）を送信する。

電子請求書の領収印と似ているような気がします。

erjiaqing

YofoaStudio

QSLカードに署名するのではなく、カード上の情報に署名すること

したがって、組み込むことも可能ですし、別々にすることも可能です。

実質的には、領収書に記載されているものです。

Jason

電子署名とブロックチェーン

YofoaStudio

erjiaqing
了解しました

BG8LGP

実現可能なプログラムはありますか？

erjiaqing

BG8LGP

書く

標準のSSH署名であるため、ADIFファイルを生成した後、SSHを使用して署名することも可能です。

ssh-keygen -Y sign -f ~/.ssh/id\_ed25519 -n adif-qslv1 qsos.adif

BG8LGP

erjiaqing 私は、ブロックチェーンを活用した共通ログ記録とeQSL交換の実装方法について研究しており、このプロジェクトが私の署名と検証モジュールに合致しているようです。一緒に研究を進めることは可能でしょうか？

BG2ELG

以前はGPGを検討していたが、生成されるファイルサイズが大きいため、カードに収まるようにするのが難しかった。そこで、楼主の提供するプログラムを探している。

erjiaqing

BG2ELG

以前、私はGPGの使用も検討しましたが、実際にGPGを使ってQSLに署名したことがありましたが、その際、署名のサイズが大きすぎるために諦めてしまいました。

最終的に、針式のプリンターでカードに印刷する方法を検討していました。レーザープリンターやインクジェットプリンターでQRコードを印刷するのは十分な性能を持ちます。熱転写も、針式のプリンターとほぼ同じような効果が得られるのでしょうか？

Base45を使用することも、より小さなQRコードサイズ（10ビットが1つのQRコードの11ピクセルに対応）を実現し、効率を91％まで高めるためです。

私も、DatamatrixやPDF417（針状プリンターをテストしてから）の使用も検討しています。

このRFCの主な目的は、デジタル署名の内容と方法を定義することです。QRコードにQSLメッセージのエンコードが含まれないようにする必要があると考えていますが、そのためには、カードの情報を基に手作業で署名を作成できる必要があります。

erjiaqing

BG8LGP

はい、可能です。

私は、デジタルQSLと公開鍵の交換方法について考えていた。

BG9JDI

BG8LGP 好家伙，你居然还研究这个哈哈哈

BI1QJQ

ドラフトを確認した結果、問題が見つかりました。

「通聯」の真正性を証明する場合、署名による証明が必要となる。偽物ではありません。

実際には、この問題はmitmと非常に類似しており、もし中間者がアリスとボブの通信を傍受し、アリスになりすましてQSLカードを作成してボブに送信した場合、ボブは単に署名の検証のみで、それが実際にアリスによって作成されたものであることを証明することはできません。

実際にこの検証を実行できるのは、信頼チェーンのシステムです。

例えば、X509署名は、発行元の認証局（CA）によって保証されるものであり、その信頼性は集中型形態で確認されます。
例えば、PGPの署名の場合、「私がお前を信頼し、お前が彼を信頼する」という信頼関係によってその真正性が保証されます（分散型形態）。

現在、投稿者が使用しているSSH署名は、この信頼チェーンの仕組みを備えていないため、厳密には通信の真正性を保証することはできません。

BG2ELG

BI1QJQ

承知いたしました。投稿主は「公開鍵の配布」について触れていますが、これは重要な要素です。

私が思い浮かべるのは：

通信時に自分の公開鍵を伝えることは現実的ではありません。
通信時に、自分の公開鍵のURLを伝えます。例えば、qrz.com のプロフィールに記載する形式で伝えます。
オフラインでの実物の鍵の交換

BI1QJQ

ドラフトを確認した結果、いくつか疑問点があります。

アリスとボブは、通信において事前に互いの公開鍵を交換することで、信頼関係を確立する必要があります。

ただし、ed25519 の公開鍵は十分に長いですが、両者が短いURLを共有することで、無線通信で公開鍵の交換が容易になります。

公開鍵を交換しない場合、QSLカードの署名検証は完了しません。

BG5UWQ

BI1QJQ BG2ELG

実際、本文にはその前提がすでに述べられています。

2. 対象範囲
本論文では、デジタルQSLカードへのデジタル署名方法を定義しています。ただし、本論文は公開鍵の配布、信頼性、および無効化プロセスの要件について規定していません。

したがって、署名のレベルだけを議論するのであれば、楼主が実現した署名プロセスは十分であると考えています。議論を進める場合、テーマを分割する必要があるかもしれません。

いくつか質問があります。

第一条本文に記載されている：

注意点：文章の末尾には不要な文字（改行、スペース、タブなど）は含まないでください。<EOR>この文字列には、何も含まれていません。

もし1枚のQSLカードに複数のQSOが含まれている場合、対応するADIFファイルは、通話の時間順序に従って、各QSOのADIFデータを直接結合する必要があります。ファイルの末尾には、改行、スペース、タブなどの不要な文字（含）は含まれてはいけません。つまり、最後のQSO <EOR> この文字列には、何も含まれていません。

この「最後のQSO <EOR> この文字列には、どのような文字も含まれていません。「しかし、実際の状況によっては、この方法では対応できない場合があります。多くの場合、改行コードが含まれているため、その場合は追加のプログラムによる処理が必要になります。」

第2点、文章中の署名については、 1本 その方法で、ADIFファイル内の1つのQSOに署名します。例えば、読み取りを行います。 <EOR> 識別ではなく、 <EOH> 識別情報の場合、例えば500件のQSO情報を記録したADIFファイルであれば、対応する署名情報をどこに保存すればよいでしょうか。

第3点、本文中の 6.2.1 ADIF の構築、欠けている FREQ フィールドは、意図的にそう設定したのでしょうか。

第4項そこで、ADIF形式のメッセージの要約から署名情報を抽出する仕組みについて議論したいのですが。これは一方向性で、とのことです。また、投稿者様がコメント欄で言及されている内容も参考にしたいと思います。 QRコード カードに表示される情報に基づいて、もし現在、スキャンすることで対応する送信局とのQSL情報を直接表示できるのであれば、実現の可能性や必要性はありますか？

最後に、レイアウトについては、引き続き「掘金」の翻訳計画が提供しているものを推奨します。翻訳におけるレイアウトのルール - 中国語の文章やレイアウトに関する共通ルールを統一し、コミュニケーションコストを削減するとともに、翻訳された文章の規範性と質を高め、より読みやすくする。

erjiaqing

BG2ELG

公開鍵の配布については、個別のRFCを作成する価値があると思いますが、最終的にはPKI（公開鍵インフラ）の一形態に収束すると考えています。

公開鍵の交換には、考慮すべき点がいくつかあります。

もし免許が取り消された場合、理論的には取り消し前のQSLは有効だが、その後のQSLは無効となる。この場合、それに対応するものを取り消すための仕組みが必要となる。
オフラインでの実物による交換は、現実的ではない（結局、特定の人物との直接的なオフラインでの交換が難しいから）。しかし、「信頼できる」ある人物を介して、他の人に証明書を発行することが可能である。ただし、その人物は本人確認や免許の有効性を確認する責任も負う必要がある。
通信時に自身の公開鍵のURLを伝える（例：qrz.com の個人情報に記載する）ことは、現在の公開鍵サーバーの考え方に近いですが、信頼性の問題や、コールサインが期限切れになった場合に再割り当てされることに対しても解決できないという欠点があります。

erjiaqing

BG5UWQ

まず、本文に記載されている：

注意点：文章の末尾には不要な文字（改行、スペース、タブなど）は含まないでください。<EOR>この文字列には、何も含まれていません。

もし1枚のQSLカードに複数のQSOが含まれている場合、対応するADIFファイルは、通話の時間順序に従って、各QSOのADIFデータを直接結合し、ファイルの末尾には余分な文字（改行、スペース、タブなど）を含めないようにする必要があります。つまり、最後のQSO <EOR> この文字列には、何も含まれていません。

この「最後のQSO」 <EOR> 「後には何も文字が含まれていない」という状態は、必ずしも実現できない場合があり、実際には改行コード（\r）などが含まれていることが多く、その場合は追加のプログラム処理が必要になる可能性があります。

実際には、改行コード（CRLFなど）を含む場合でも、さまざまな行末記法の考慮から、多くの場合、追加のプログラム処理が必要になります。対照的に、文字を含まない場合は、わずかに簡単になることがあります。例えば、シェル環境内では。

`xxxxx` を出力する

これで、改行のない文字列を生成できます。

2つ目の点として、本文に記載されている署名は、ADIFファイル内の1つのQSOに対して個別に署名しているように見えます。例えば、「読み取り」 <EOR> 識別ではなく、 <EOH> 識別情報の場合、例えば500件のQSO情報のADIFファイルであれば、対応する署名情報をどこに保存すればよいでしょうか。

文章には、すべてのQSOを時間順に繋ぎ合わせる方法が記載されています。

ここでは、少数のQSOや、直接通信によるサインの状況を想定しています。QSLカードの実用性を考慮すると、一般的に公開されるQSOの詳細がすべて含まれていないため、一度に数百件のQSOに対してサインを行うような状況は、必ずしも適しているとは言えません（なぜなら、個々のQSOについて検証することが非常に困難だからです）。

本文で言及されている方法では、受信者が簡単に元のADIFファイルを生成して検証できるようにすることを重視しています。一度に500件の署名を行う場合、相手側が検証する手間はほとんどなくなります。その代わりに、直接大きなADIFファイルに署名を付与することが可能です。

（上記1と合わせて）設計にあたり、内部のADIF形式について具体的に検討し、ある程度の検討を行った結果、「機械による自動化を基本としつつ、人手での確認も可能にする」という設計目標を設定しました。主な利用シーンは、人工によるQSO情報の入力後、機械が署名を読み取り、機械による署名検証です。

3つ目の点ですが、本文の6.2.1でADIFを構築する際に、FREQフィールドが欠けているのは、意図的なものですか？

はい、まず、周波数（FREQ）と帯域（BAND）には、本来からある程度の冗長性があり、どちらか一方を選択する必要があるということです。

次に、現在、QSL（競技を含む）において、通常は周波数帯全体に対して検証が行われ、特定の周波数を比較するわけではない。そのため、文中では「バンド」を使用し、「周波数」とは区別した。

現時点では、この問題についてはオープンな立場を取りつつも、個人的には BAND の利用を推奨します。

実際に運用する際、QSLの内容に関して特別な要件があるケースも経験しました。（最も一般的なのは、グリッド座標を含めること）。他のフィールドの選択についても議論する価値があるかもしれません。

第四点ですが、署名情報の抽出がADIFのメッセージサマリーであること、それが不可逆であるという前提で、掲示板の楼主がコメント欄で「QRコードをカードに表示する」と述べているのに対し、もし現在、QRコードをスキャンすることで直接、対応するQSOの荷物情報を表示できるのであれば、そのような実現可能性や必要性があるのでしょうか。

実現の可能性はありますが、その必要性は感じていません。

本文中で、「7. 原始QSOデータの追加」について述べましたが、これは、QRコードのサイズを考慮して、元のQSOデータをどのように埋め込むかの簡単な説明です。この章では、詳細な設計は行っていませんが、現在私は、このテーマに特化した別のRFC（要求仕様）を作成することを希望しています。

最後に、レイアウトについては、依然として「掘金翻訳計画」が提供する「統一された中国語の文章とレイアウトに関するルールガイド - コミュニケーションコストを削減し、翻訳の規範性と雰囲気を高め、より読みやすくする」という翻訳のレイアウトに関する指針をお勧めします。

ありがとうございます。私はレイアウトの調整はほとんど行わず、入力システムの記号オプションは「」以外のものについてはあまり気にしていません。記事を簡単に読んだのですが、私はレイアウトエンジンに大きく依存しているため、次のような傾向があります。

中国語と英語の区別は、スペースを挿入せずに行われます。スペースの挿入は、レイアウトエンジンによって処理されます。
技術文書の慣例に従い、半角記号を使用し（引用符を除く）、必要に応じてレイアウトエンジンに変換を依頼することも可能ですが、文末にはピリオドを使用してください。
漢字は、太字ではなく楷書体を使用し、この処理もレイアウトエンジンによって行われます。

これは、異なる場所で公開する際に、単一バージョンのソースファイルを共有できるようにするためです。

（その後、私はGitHubで本文を公開し、そこで詳細な編集を行うことができます。ここでは、細かなレイアウトは行わず、必要に応じて両方のコンテンツを同期します。）
（ただし、このRFCは基本的にそれに従っていません。）

BG8LGP

ブロックチェーンは、信頼メカニズムや公開鍵の交換など、さまざまな問題を解決できる。eQSLカードにおける自動署名の問題についても、スマートコントラクトを用いて、通信ログの確認を行うことが可能である。私はこの点について検討・研究しており、もし実現可能であれば、皆で協力して、最適な方法を開発したいと考えている。~~GitHubで私のコールサインを検索してください。~~

erjiaqing

ある24針式のインクジェットプリンターで、QRコードを印刷したところ。現在の状況は以下のとおりです。

簡略な署名：1.8mm x 1.8mm以上のサイズであれば認識可能
完全対応サイズ：2.3mm x 2.3mm以上のサイズ

このサイズは、私が想定していたよりも少し大きいです（1.3x1.3のコンパクトなサイン、または2.0x2.0のフルサイズのサインを考えていました）。より鮮明なQRコードを得るための、他の設定があるかどうか知りたいです。もし、誰かが同様のQRコードを作成した経験があれば、ぜひアドバイスをお願いします。

もしさらに大きくなるとレイアウトが難しくなる可能性があるため、QRコードに直接QSLを埋め込むことは非常に困難であると考えられる。特に、QSLを埋め込んだ場合、コンテンツの長さが増加し、QRコードのサイズが定数ではなくなり、最小サイズも大幅に増加するため、レイアウトがさらに難しくなる。

そこで、QSOのハッシュ（つまり署名されたADIFのハッシュ）を内部に格納できるかどうかを検討しました。そのアイデアは、どのような署名を使用しても、サードパーティのサービスへの依存を避けることです。QSOは、ハッシュを使用してインデックスを作成し、その後、何らかの交換メカニズムを定義することで、共通のインターフェースを再定義できます。

生成されたQRコードのサイズは、妥当な範囲内であるべきです。

AD2AG

erjiaqing
もし使いやすさをある程度犠牲にしても、デジタル隠蔽技術を試してみるのも良いかもしれません。QSLカード全体を画像として扱い、周波数領域にQRコードを埋め込むことを検討できます。ただし、この方法ではカメラで直接QRコードを読み取って検証することが難しくなります。

AD2AG

erjiaqing
试了一下GPG，一个detached签名需要119字节，介于完整签名的168字节和精简签名的54字节。并且GPG签名保留了签名时间戳和签名密钥信息。感觉可以放进2.0x2.0 cm的区域。

另外，有没有考虑过别的形式的二维码，比如PDF417这种宽度换高度的二维码，就可以把他挤在角落里了。或者像护照信息页最下方的可机读区域一样，用一些方便OCR的字体来直接打印base45/64的内容。

例：一个GPG detached signature

gpg --list-packets .\test.sig
# off=0 ctb=88 tag=2 hlen=2 plen=117
:signature packet: algo 22, keyid XXXXXXXXXXXXXXXX
        version 4, created 1688418964, md5len 0, sigclass 0x00
        digest algo 10, begin of digest 45 3a
        hashed subpkt 33 len 21 (issuer fpr v4 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX)
        hashed subpkt 2 len 4 (sig created 2023-07-03)
        subpkt 16 len 8 (issuer key ID XXXXXXXXXXXXXXXX)
        data: [253 bits]
        data: [256 bits]

闽ICP备2021006864号-7

闽公网安备35020602002794号互联网举报中心

用户协议隐私政策社区规范积分规则中继规则转载须知
更新日志联系我们常见问题友情链接运营报告赞助

浩奇科技（厦门）有限公司

是无线电，把我们联系在一起