# 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 卡片進行格式轉換等操作，不會影響簽名效力。
四。接收方可以印製包含數字簽名的 QSL 卡，印製後的卡片可獨立驗證。

規範性參考文件

GB/T 1.1-2020 標準化工作規範，第一部分：標準化文件的結構與編寫規則。

本文中的粗體「（不）應該”、“（不）建議”、“可以、不需要”、“（無法）”、“（不可能）「使用」符合《GB/T 1.1-2020 標準化工作規範第一部分：標準化文件的結構與起草規則》附錄 C 的定義。

定義

5.1 基本定義

位由 8 位二進制組成的符號
簽名載荷 在實際簽署過的數據中，有意義的部分。
簽署過的數據 數字簽名演算法的輸入
簽名由文件標頭、簽名演算法描述以及數位簽章等部分組成的檔案。

5.2 SSH 訊息

本文多次描述 SSH 訊息結構體，在本文的語義範圍內，所使用的類型包括：

ssh-string 以四個字、大端序表示的字串長度和先前指定之字串，字串中可包含 Unicode NUL 字元，但字串不得包含過多的 Unicode NUL 字元。
uint32 四個字、大端序表示的 32 位無號整數。
字節 [N] N 個位元組，沒有其他資訊
varint 變長數字，其最高位表示該數字是否為最後一位（1 表示否，0 表示是）。例如，150 表示…10010110 00000001，將十六進位數字轉換為96 01。請注意：此類型並非 SSH 訊息定義。
具體實作

6.1. 數位簽名演算法選擇

在這個設計中，我們將使用 SSH 鍵對 QSL 卡片上的資訊進行數位簽名。這是因為 SSH 的簽名訊息相較於 PGP 簽名的訊息更小，也更容易在 QSL 卡片上顯示。

至於具體的演算法選擇，我們使用了 Ed25519 橢圓曲線密碼。這是因為 Ed25519 的公開鍵大小和簽名大小都足夠小，可以更容易地嵌入在 QSL 卡片中。

簽署內容並未包含被簽署的資訊。

6.2 數位簽名中的 ADIF 載荷

數字簽名的有效載荷為一個 ADIF 文件，其內容可以從 QSL 卡片上呈現的資訊中唯一構成。

6.2.1 建立 ADIF 結構

使用數位簽名所產生的資訊，採用 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 卡：

致 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輸出至：

00000000: 3c51 534f 5f44 4154 453a 383e 3230 3232  <QSO\_日期：8>2022
00000010: 3132 3331 3c54 494d 455f 4f4e 3a36 3e31  1231<持續時間：6>1
00000020: 3830 3030 303c 4241 4e44 3a33 3e32 304d  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  N_CALLSIGN: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 資訊

如果一張 QSL 卡片上包含多個 QSO，則對應的 ADIF 檔案。應依照通聯的時間順序，直接將各個 QSO 的 ADIF 數據串聯，在文章結尾。不該若有任何多餘字元（包含換行、空格、制表符等），即，以最後一個 QSO<EOR>後方沒有任何字元。

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 進行資料的簽名）。

message4.2 節中所述的 ADIF 檔案， H（訊息）針對其 SHA-512 演算法產生的指紋。

將此內容經過 SSH Message 格式編碼後，使用 Ed25519 的私鑰和…ssh-ed25519完成簽名，即獲得第4.3.1節中signature欄位。

額外提供原始 QSO數據

簽名前可附加原始 QSO 資料，以便機器直接辨識和驗證。原始 QSO 資料為簡化的極小 QSO 元資料，包含以下欄位：通訊時間、通訊頻段、通訊模式、接收方呼號、發送方呼號、OP。

其格式如下：

`byte[6]` MAGIC_PREAMBLE
變數：呼叫號碼 (call)
變數：站台呼叫號碼 (station_callsign)
變數：操作員
SSH 格式的資料

其中，「call」、「station\_callsign」和「operator」分別為呼號的三十六位數表示（見下表）：

+---------++----+----++----+----+
|字|號碼||字|號碼||字|號碼 |
+---------++----+----++----+----+
| 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 時間戳為協定時間自 1970 年 1 月 1 日起的秒數（但精確到分鐘）。頻帶為對應頻段的低端（千赫茲）數字，例如 20 米頻段表示為 14000。模式為表示模式的字串，若不足 8 個字。\0補充。

範例

假設 ST4TION 使用無線電 C3SHI 與 TE5T 在北京時間 2023 年 1 月 1 日 10:05:30，在 20 米頻段上使用 MFSK modulation 成功進行了一次通訊。目前…ST4TION想要以自己的姓名簽署以下 QSL 卡：

致 TE5T，DE C3SHI 站

日期 時間 (BJT) /頻率 /模式 / RST
2023-01-01 10:00 14.074 MHz MFSK 59 59

[ ]PSE [X]TNX QSL

祝您順利！ 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 檔案中的「秒」資訊，會被無條件地截斷至 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 @...].\..:...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: 53 53 48 53 49 47 00 00 01 00 00 03 33 00 00  SSHSIG.......3..
00000010: 0b 73 73 68 2d 65 64 32 35 35 31 39 00 00 00   ..ssh-ed25519...
00000020: 20 03 4e 72 59 e9 b9 70 e0 2b 2a 56 8c 73  .NrY..p.+*V.s..
00000030: 96 55 59 74 c9 c3 3c 35 ea 9b f5 0b d3 ca  .UYt..<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 用於安全外殼 (SSH) 協定的 Ed25519 和 Ed448 公鑰演算法

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。但因為簽名太大而放棄了。

我的最終想法是，能夠使用針式列印機將二維碼印在卡片上。無論是雷射或噴墨列印機，都能輕鬆地印出這個二維碼。而熱轉印是否與針式列印機的效果相近呢？

使用 Base45 的目的是為了能夠產生更小的二維碼尺寸（每個 10 位元對應二維碼上的 11 個像素），效率高達 91%。

我也在考慮使用 Datamatrix 或 PDF417 (等我取得一個針式印表機來測試)。

這個 RFC 主要目的是定義數位簽名的內容和方法，因為我認為一定需要避免將 QSL 正文編碼進 QR Code 中，但這樣就要求能夠確定地根據卡片上的資訊手動生成簽名。

erjiaqing

BG8LGP

沒問題

我也正在考慮 DigitalQSL 與公開鍵交換的方式。

BG9JDI

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

BI1QJQ

在查看草稿後，發現一個問題。

若要證明「通聯」的真實性，且依賴簽名，則必須證明該簽名。並非是偽造的。

事實上，這個問題與 MITM (中間人攻擊) 非常類似。如果有人一直監聽 Alice 和 Bob 的通訊，並偽裝成 Alice 發送 SSH 簽名，然後發送一個假的 QSL 卡給 Bob，那麼 Bob 僅從驗證簽名的角度來說，是無法證明收到的簽名是由 Alice 真正發出的。

真正能夠執行這個驗證的是一套信任鏈體系。

例如，X509 簽名，其真實性由簽發憑證的 CA (中心化形式) 保證。
例如，PGP 簽名，其真實性透過「我信任你，你也信任他」這種信任鏈來確保（分散式形式）。

版主目前使用的 SSH 簽名並不具備這種信任鏈機制，因此嚴格來說，無法保證通聯的真實性。

BG2ELG

BI1QJQ

同意，雖然版主略過了「公開金鑰發放」，但這也是一個非常重要的環節。

我能想到的是：

透過聯通，對方可以得知我的公開金鑰（這是不實際的）。
通聯時會告知自己的公開金鑰的網址，例如在 qrz.com 的個人資訊中填寫。
離線真實人交換公開金鑰

BI1QJQ

在查看草稿後，發現一個問題。

艾莉絲和鮑勃需要在通聯平台上事先交換彼此的公開金鑰，才能建立信任。

然而，即使是 ed25519 的公開鍵也已經足夠長，因此雙方必須事先約定一個簡短的網址，以便在無線電通訊中交換公開鍵。

如果沒有交換公開鍵，就無法完成 QSL 卡簽名驗證。

BG5UWQ

BI1QJQ BG2ELG

實際上，文章已經提到過前提。

2. 範圍
本文定義一種用於對數位 QSL 卡片進行數位簽名的方法。但本文並未對公開鍵的發放、信任以及撤銷流程提出要求。

因此，僅就簽名這一層次的討論而言，我覺得楼主實現的簽名流程已經足夠了。至於若有其他需要討論的主題，或許可以將其拆分成獨立主題。

我有一些疑問。

第一點文中提及的：

請注意：文章結尾不得包含任何額外的字元（包括換行、空格、制表符等）。<EOR>後方沒有任何字元。

如果一張 QSL 卡片上包含多個 QSO，則應依照 QSO 發生時間的順序，直接將各 QSO 的 ADIF 資料拼接在一起，文末不應有任何額外的字元（包括換行、空格、制表符等），即以最後一個 QSO 的… <EOR> 後方沒有任何字元。

這裡的「」最後一次的 QSO <EOR> 後方沒有任何字元「實際情況可能無法滿足，大多數會帶有回車符，這時候是否需要額外的程式處理。」

第二點，文中簽名，似乎是 單一 的方式，對 ADIF 檔案中的一筆 QSO進行簽名，例如讀取了 <EOR> 標示，而非 <EOH> 標識，那麼如果是一份包含 500 個 QSO 資訊的 ADIF 檔案，我該將對應的簽名資訊儲存在哪裡呢？

第三點，文中 6.2.1 建立 ADIF 結構，缺了 FREQ 這些欄位，是故意設定的嗎？

第四點我想討論一個情境，簽名資訊的提取來自 ADIF 格式的報文摘要，且是不可逆的。我注意到版主在評論區提到… 二維碼 如果在卡片上顯示相關資訊，那麼如果能夠透過掃描來直接呈現對應來源的 QSO 載荷資訊，這是否可行或有必要？

最後，關於排版，我仍然推薦來自「掘金」翻譯計畫提供的。翻譯排版規範指南 - 統一中文文案和排版的相關用法，降低溝通成本，提升譯文的規範性和質感，使其更易閱讀。

erjiaqing

BG2ELG

公開金鑰的分發，確實適合撰寫一篇獨立的 RFC，但我認為最終會演變成一種 PKI 系統。

交換公開金鑰涉及許多需要考慮的問題：

如果執照被吊銷，理論上被吊銷之前的 QSL 仍然有效，但之後的 QSL 則無效。因此，當此時需要有一個機制來吊銷相應的…
實體之間的交換方式顯然不夠實際（畢竟很難與某些特定的人進行實體交換），但我們可以「信任」某些人，讓他們為他人簽發憑證（同時，他們也需要負責驗證身分並檢查執照狀態）。
通聯時會公布自己的公開金鑰網址，例如在 qrz.com 的個人資訊中填寫，這實際上是目前公開金鑰伺服器的作法，但並不能真正解決信任問題，此外，如果呼號過期後被重新指配的問題也無法解決。

erjiaqing

BG5UWQ

第一點，文中提及的：

請注意：文章結尾不得包含任何額外的字元（包括換行、空格、制表符等）。<EOR>後方沒有任何字元。

若一張 QSL 卡片上含有多個 QSO，則應依照通訊的時間順序，直接將各 QSO 的 ADIF 資料拼接在一起，文末不應有任何額外的字元（包含換行、空格、制表符等），即以最後一個 QSO 的… <EOR> 後方沒有任何字元。

這裡的「最後一次 QSO」 <EOR> 後方不包含任何字元，「實際情況」可能無法滿足，大多數會包含回車符，這時候是否需要額外的程式處理？

實際上，即使包含回車符，考量到 CRLF 等不同的行結尾格式，通常還是需要額外的程式處理。與此相對，沒有任何字元的版本可能會稍微簡單一些，例如在 Shell 裡面。

輸出「xxxxx」 (不換行)

這足以產生不包含行尾符號的字串。

第二點，文中提及的簽名，似乎是針對 ADIF 檔案中的單一 QSO進行簽名，例如讀取了。 <EOR> 標示，而非 <EOH> 如果是包含 500 個 QSO 資訊的 ADIF 檔案，那麼我應該將對應的簽名資訊儲存在哪裡呢？

文中提到，只需將所有 QSO依照時間順序進行拼接即可。

這裡考慮的情境是少量的 QSO、點對點簽名的情況。考量到 QSL 的實際使用，一般不會包含全部公開的 QSO 細節，因此一次簽署數百條 QSO 的情境可能不太適合這種情況（因為幾乎不可能針對其中單一條進行驗證）。

本文所提及的方法，更側重的是接收方能夠方便地構建原始 ADIF 文件以進行驗證。如果每次簽名 500 條 QSO，幾乎不需要對方來驗證，此時可以直接對整個 ADIF 文件進行簽名。

（與第一點一同）在設計時，我確實考慮過 ADIF 的具體格式。經過一番思考，最終將設計目標定為「機器自動化，兼顧人工」，主要應用場景是人工輸入後，QSO 資訊 – 機器讀取簽名 – 機器驗證。

第三點，文中 6.2.1 關於「建立 ADIF」的部分，缺少了「FREQ」欄位，是故意的嗎？

是的，首先，「頻率」和「頻寬」之間確實存在一定的冗餘關係，因此只能選擇其中一個。

此外，考量到目前對 QSL (包括比賽中) 的驗證主要針對頻段，而不會針對特定頻點進行比較。因此，文中選擇了「BAND」而非「FREQ」。

目前，我對這個問題持開放態度，但個人更傾向於使用 BAND。

在實際的 QSO 中，我也有遇到需要特定 QSL 內容的情況（例如，必須包含網格座標）。關於其他欄位的選擇，或許也值得討論。

第四點，我想討論一個情境：簽名資訊提取的是 ADIF 的報文摘要，不可逆。我注意到版主在評論區提到了二維碼顯示在卡片上，如果當時能夠透過掃描直接呈現對應來源的 QSO 載荷資訊，這樣是否有實現的可能性或必要性呢？

或許有可能，但我覺得這並非必須。

在文中，我提到「7. 附加原始 QSO資料」，即說明如何在其中嵌入原始 QSO載荷。為了符合二維碼的體積限制，因此做了不少妥協。同時，在這份文件中我並沒有進行過多的深入設計，目前我希望能夠有其他的 RFC 來專注於這個主題。

最後，關於排版，我仍然推薦來自「掘金」翻譯計畫提供的「統一中文文案、排版的相關用法」，這份指南能提供一致的排版規則，降低溝通成本，並提升譯文的可讀性與專業感。

謝謝，我並沒有進行過多的排版調整，輸入法的標點符號選項除了「」之外，也沒有特別注意。我簡單地閱讀了這篇文章，因為我非常依賴排版引擎，所以我傾向於……

中文字和英文之間，均不額外加入空格，而空格的添加是由排版引擎來處理。
考量科技文獻慣例，使用半形符號（不含引號），若有需要，也可交由排版引擎進行必要的轉換（但句末必須使用句點）。
使用楷體代替斜體的漢字，這個操作仍然由排版引擎來處理。

這主要是為了確保在不同地點發布時，都能使用相同的原始檔案版本。

（或許之後我可以在 GitHub 上發布正文進行審閱，這裡仍然不會進行細緻的排版，並適時同步兩邊的内容。）
（但我承認這份 RFC 並沒有完全按照指示執行。）

BG8LGP

區塊鏈能夠解決諸如信任機制和公開鍵交換等一系列問題，對於 eQSL 卡的自動簽名問題，透過聯通的日誌記錄確認也可以使用智慧合約來完成。我正在思考與研究，如果可以，大家一起參與，集大家所長來搞出一個方案。~~在 GitHub 上搜尋我的使用者名稱。~~

erjiaqing

我用一台 24 針的列印機，簡單地印出了幾個 QR code，目前的觀察結果如下：

簡化簽名：1.8mm x 1.8mm 及以上的尺寸即可辨識。
完整簽名：2.3mm x 2.3mm 及以上的尺寸即可辨識。

這個尺寸比我預期的稍微大一點（我原本的想法是使用1.3x1.3的小型簽名，或是2.0x2.0的全尺寸簽名）。我不確定是否有其他設定能讓我獲得更清晰的二維碼。如果有人有經驗，或許可以提供一些建議？

感覺如果再增加內容，可能會造成排版上的困難。因此，直接將 QSL 卡嵌入 QR 碼可能仍然會遇到很多問題，主要原因是嵌入後內容變長，QR 碼的尺寸不再是常數，而且最小尺寸也會顯著變大，這不利於排版。

因此，我正在考慮是否能將 QSO 的哈希值（也就是簽署過的 ADIF 檔案的哈希值）加入其中。我的想法是，無論如何，都不能依賴第三方服務來驗證簽名，QSO 可以重新定義通用介面，並利用哈希值進行索引，然後再實施某种交換機制。

這樣產生的二維碼尺寸應該是可以接受的。

AD2AG

erjiaqing
如果放棄一些易用性，不如試試數位隱寫。可以考慮將 QSL 卡正面整體視為一張圖片，在頻譜中插入 QR Code。不過這樣就無法方便地使用相機直接拍攝 QR Code 來驗證。

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号互联网举报中心

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

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

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