# 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] Digital signature for QSL cards

erjiaqing

Digital signature on QSL card

Introduction

In recent years, more and more stations have stopped sending paper QSL cards and instead use electronic or online log services. We realized that online log services are overly dependent on certain centralized websites and cannot fully showcase the individual characteristics of a station, making them unable to completely replace paper QSL cards.

Furthermore, a digitally signed QSL card without a physical signature is very easy to forge and cannot effectively prove the authenticity of communication. This article proposes a feasible digital signing scheme that allows for the digital signing of information on QSL cards while maintaining the functionality and personalization of electronic QSL cards.

Scope

This paper defines a method for digitally signing digital QSL cards. However, this paper does not specify requirements for the distribution, trust, and revocation processes of public keys.

Requirements

The digital signature proposed in this article meets the following requirements:

i. Digital signatures can be easily identified and verified, and do not rely on centralized third-party services.
ii. The digital signature has a significant impact on the design and aesthetics of the QSL card.
iii. The receiving party's operations to convert the received QSL card, such as formatting changes, do not affect its validity.
iv. The receiving party can print QSL cards containing a digital signature, and these printed cards can be independently verified.

Reference documents for compliance

GB/T 1.1-2020, Guidelines for Standardization Work – Part 1: Structure and Drafting Rules for Standardization Documents.

In this article, the word "..." in bold is:(Do not)”、“(Do not)”、“Available、No need to”、“(Not) able to”、“(Not) PossibleThe use of "符合" is consistent with the definition in Appendix C of GB/T 1.1-2020, "Guidance on Standardization Work, Part 1: Structure and Drafting Rules for Standardization Documents."

Definition

5.1 Basic Definitions

Bytes A symbol consisting of 8 binary digits
Signature payload The meaningful parts within the signed data.
Signed data Input for digital signature algorithm
Signature A file consisting of sections such as the header, signature algorithm description, and digital signature.

5.2 SSH Messages

This document repeatedly describes the SSH message structure. The types used in this context are:

ssh-string The length of a string represented in four bytes with big-endian byte order, and the corresponding byte sequence specified by that length, may contain Unicode NULL characters. The string does not contain any extraneous Unicode NULL characters.
uint32 A 32-bit unsigned integer represented in big-endian format, using four bytes.
byte[N] N bytes, no other information
varint Variable-length numbers, where the most significant bit indicates whether the number ends with that digit (1 means no, 0 means yes). For example, 150 would be represented as:10010110 00000001, convert to hexadecimal96 01Note: This type is not an SSH message definition.
Specific implementation

6.1. Selection of Digital Signature Algorithms

In this design, we will use SSH key pairs to digitally sign the information on the QSL card. This is because the signed messages using SSH are smaller and easier to display on the QSL card compared to PGP-signed messages.

Regarding the specific algorithm selection, we used the Ed25519 elliptic curve cryptography, because the public key and signature size of Ed25519 are both small enough to be easily embedded in QSL cards.

The signature does not include the information being signed.

6.2 Digital Signature Payload ADIF

The digital signature's payload consists of a single ADIF file, which can be uniquely constructed from the information displayed on the QSL card.

6.2.1 Constructing an ADIF file

The information encoded with a digital signature is formatted in ADIF, which has human-readable characteristics that allow it to be easily constructed. Furthermore, since the digital signature does not contain the information being signed, the length of the signed information does not affect the length of the signature.

The following information willIn sequenceIncluded in the ADIF data:

QSO_DATE

TIME_ON

BAND

CALL

MODE

STATION_CALLSIGN

OPERATOR

Among them, QSO_DATEFor dates expressed in 8 digits (year, month, day) in Coordinated Universal Time （UTC）. TIME_ONFor times expressed in 6 digits (hours, minutes, seconds) as Coordinated Universal Time （UTC）, the time should be indicated, regardless of whether the corresponding second is printed on the QSL card.Cut offTo the end of the minute (effectively resetting the seconds to zero).

All of the above.ShouldUse uppercase letters. If the QSL card does not specify the operator, thenOPERATORWithout any modificationsSTATION_CALLSIGN.

For example, the following QSL card:

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

73!

Its ADIF conversion results in:

<QSO Date: 8>20221231<TIME_ON: 6>180000<Band: 3>20M<CALL: 6>BB0BBB<MODE: 3>USB<STATION CALL SIGN: 9>B4/BG6TOE<OPERATOR: 6>BG6TOE<EOR>

This documentxxdDump to:

00000000: 3c51 534f 5f44 4154 453a 383e 3230 3232  <QSO Date: 8>2022
00000010: 3132 3331 3c54 494d 455f 4f4e 3a36 3e31  "1231"<TIME_ON: 6>1
00000020: 3830 3030 303c 4241 4e44 3a33 3e32 304d  80000<Band: 3>20M
00000030: 3c43 414c 4c3a 363e 4242 3042 4242 3c4d  <CALL: 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<OPERATOR:
00000070: 363e 4247 3654 4f45 3c45 4f52 3e         6>BG6TOE<EOR>

Please note: at the end of the articleShould notAny extraneous characters (including newlines, spaces, tabs, etc.)<EOR>The string does not contain any characters.

6.2.2 Constructing ADIF information containing multiple QSOs

If a QSL card contains multiple QSOs, then the corresponding ADIF file will contain…ShouldFollowing the chronological order specified by Telelink, directly concatenate the ADIF data from each QSO, as indicated at the end of the document.Should notRemove any extraneous characters (including line breaks, spaces, tabs, etc.), i.e., those present after the last QSO.<EOR>It does not contain any characters.

6.3 Signature Data

6.3.1 Presentation Method

Signature dataOkay.Displayed directly on the QSL card after being encoded using Base64. Signature data represented in text format.SuitableUse fixed-width font for layout. The font used is:ShouldCapable of distinguishingi、l、1, O、o、0， 5、SWaiting for the encoding characters used by Base64.

Signature dataOkay.Displayed directly on the QSL card after being encoded using Base32. Signature data represented in text format.SuitableUse fixed-width font for layout.

Signature dataSuitableThe signature data is encoded using Base45 and included within the QR code.ShouldFor standalone QR codes. This QR codeAvailableUse colors other than black and white, butShouldUse a light-colored area as the background for the QR code and a dark color for the foreground of the QR code.

To ensure a high success rate in QR code recognition, use QR codes as the carrier for the signature data.Not recommendedUsing encodings other than Base45.

6.3.2 Binary Signature Data Format

The binary signature consists of an SSH signature structure, with the following format:

byte[6] MAGIC_PREAMBLE
uint32 SIG_VERSION
ssh-string publickey
ssh-string namespace
ssh-string reserved
ssh-string hash_algorithm
ssh-string signature

Among them:MAGIC_PREAMBLEForSSHSIG, SIG_VERSIONFor 1.

publickeyThis is the public key for the serialized signature key.

namespaceShouldForadif-qslv1.

reservedShouldEmpty.

hash_algorithmShouldForsha512(In other words, always use SHA512 to sign the data.)

signatureFor signing the SSH message, use:ssh-ed25519Algorithm.

6.3.3 Simplified signatures

To make the signature content more easily displayed,Okay.Simplify the signature content. The simplified signature only contains the header and ED25519 signature data. The header is fixed as:DQSLV1followed by a 64-byte ED25519 signatureX OR Y。When the receiver receives a message that starts withDQSLV1When retrieving signature data,ShouldValidate it against the standard signature format.

6.3.4 Signed Content

The actual content that was signed was:

byte[6] MAGIC_PREAMBLE
ssh-string namespace
ssh-string reserved
ssh-string hash_algorithm
ssh-string H(message)

Among them:MAGIC_PREAMBLEForSSHSIG, SIG_VERSIONFor 1.

publickeyShouldThis is the public key for the serialized signature key.namespaceShouldForadif-qslv1.

reservedShouldEmpty.

hash_algorithmShouldForsha512(In other words, always use SHA512 to sign the data.)

message4.2 The ADIF file described in Section 4.2, H(message)Its fingerprint under the SHA-512 algorithm.

After encoding this content using the SSH Message format, use the Ed25519 private key andssh-ed25519Obtain the signature as described in section 4.3.1.signatureFields.

Add original QSO data

Previously recorded QSOs can be supplemented with original QSO data to facilitate direct recognition and validation by machines. The original QSO data consists of a concise representation of minimal QSO metadata, including the following fields: communication time, communication band, communication mode, receiving station call sign, transmitting station call sign, and OP.

The format is:

byte[6] MAGIC_PREAMBLE
varint call
varint station_callsign
varint operator
ssh-string data

Among these, call, station\_callsign, and operator are represented as 37-base numbers (see table below):

+---------++----+----++----+----+
|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 |+----+----++----+----+

Such asB1CRAIndicates that it is11 * 37^4 + 1 * 37^3 + 12 * 37^2 + 27 * 37 + 10 = 20683861

In this case, "data" is a string formed by concatenating multiple minimal QSOs, and its format is:

varint QSO Timestamp
varint Band
byte[8] Mode

Among these, the QSO Timestamp represents the number of seconds since January 1, 1970, in Coordinated Universal Time (BJT), with precision down to the minute. The Band represents the lower end of the frequency range for a given band, expressed in kilohertz, such as 20 meters being represented as 14000. The Mode is a string representing the mode, using no more than 8 bytes.\0Complete.

Example

Assume ST4TION Using a radio C3SHI With TE5T On January 1, 2023, at 10:05:30 Beijing time, a successful communication was established using MFSK modulation on the 20-meter band. The current status is:ST4TIONPlease sign the following QSL card with your own name:

TO TE5T
DE C3SHI OP STATION

Date Time (SSH) / Freq / Mode / RST
2023-01-01 10:00 / 14.074 MHz / MFSK / 59 59

[x]PSE [ ]TNX QSL

VY TU! 73

ST4TIONThe private key is:

Its public key is:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIANOclnpuXDgKypWjHO/2JZVWXTJwzw16pv1C9PK8qoI

In this case, the ADIF data (with a valid signature) would look like this:

<QSO Date: 8>20230101<TIME_ON: 6>020500<Band: 3>20M<Call: 4>TE5T<MODE: 4>MFSK<STATION CALL SIGN: 5>C3SHI<OPERATOR: 7>ST4TION<EOR>

Please note:

The Beijing time on the card should be converted to Coordinated Universal Time (ADIF).
The seconds generated in the resulting ADIF file are unconditionally truncated to 0.
The bandwidth is derived from 14.074, resulting in a value of 20M.
RST is not included in ADIF.

This ADIF fileSHA512Fingerprint:

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

The constructed signed data looks like this:

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....

Use the private keys mentioned above andssh-ed25519Signatures can be submitted in the following ways:

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.

Signature:

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..<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.

Simplified signature:

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 encoded signature:

U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgA05yWem5cOArKlaMc7/YllVZdMnDPDXqm/UL08ryqggAAAAKYWRpZi1xc2x2MQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQyNTUxOQAA
AECChPnty474bN9b7sNHZ2KE6s5LRkRkKWkAQTlueZu990wrlA5TVB5N+pTbcEqbd6rRTc0uXWs/
MMZExn6Eyk0H

Concise Base64 encoded signature:

RFFTTFYxgoT57cuO+GzfW+7DR2dihOrOS0ZEZClpAEE5bnmbvfdMK5QOU1QeTfqU23BKm3eq0U3N
Ll1rPzDGRMZ+hMpNBw==

The Base45 encoded signature:

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

Simplified Base45 encoding for signatures:

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

Informational reference document

RFC4634 U.S. Secure Hash Algorithms (SHA and HMAC-SHA)

RFC4648 Base16, Base32, and Base64 data encodings

RFC8709 Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol

RFC9285 Base45 Data Encoding

ADIF Amateur Data Interchange Format (ADIF) Specification

bh2vrn

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

YofoaStudio

The technology is a bit too technical for me to understand.
I would like to ask if a digital signature is sent along with an electronic QSL card, consisting of both a card file and a signature file.
Alternatively, send the card file directly, which includes a digital signature.

It feels a bit like the official stamp used for electronic invoices.

erjiaqing

YofoaStudio

This refers to signing on a QSL card, not signing on the information on the card itself.

Therefore, it can be embedded or separated.

It's essentially like that thing on the invoice.

Jason

Electronic signature + blockchain

YofoaStudio

erjiaqing
Understood.

BG8LGP

Are there any programs that have been successfully implemented?

erjiaqing

BG8LGP

In writing

Because it uses standard SSH signatures, you can also create an ADIF file and then sign it using SSH.

ssh-keygen -Y sign -f ~/.ssh/id_ed25519 -n adif-qslv1 qsos.adif

BG8LGP

erjiaqing I am researching the implementation methods of blockchain-based universal log recording and eQSL exchange. Your project perfectly matches my signature and verification modules. Perhaps we could collaborate on this?

BG2ELG

I had considered using GPG, but the resulting size was too large to fit on a card, so I'm waiting for the main poster to provide a program.

erjiaqing

BG2ELG

I had also considered using GPG, and in fact I have used GPG to sign QSLs. However, I gave up because the signatures were too large.

My final idea is to be able to print the QR code on the card using a needle-type printer. Laser or inkjet printers would definitely have enough capacity for this. Would thermal transfer printing be similar in effect to a needle-type printer?

Using Base45 also allows for smaller QR code sizes (10 bits corresponding to 11 pixels on the QR code), achieving an efficiency of up to 91%.

I am also considering using Datamatrix or PDF417 (after I get a label printer to test them out).

The main purpose of this RFC is to define the content and methods for digital signatures, because I believe it's important to avoid encoding the QSL message within a QR code, but this would require being able to reliably generate the signed content based on the card information.

erjiaqing

BG8LGP

Sure, that's possible.

I was also considering the method of exchanging DigitalQSL and public keys.

BG9JDI

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

BI1QJQ

After reviewing the draft, I have a question.

If proving the authenticity of Tonglian relies on signatures, then those signatures must be proven to be genuine.Not fabricated.

In fact, this problem is very similar to MITM. If an attacker continuously listens to the communication between Alice and Bob, and then forges a QSL card signed by Alice using SSH, and sends it to Bob, Bob can only verify the signature from a verification perspective, but cannot prove that the received signature was actually generated by Alice.

The only system that can truly execute this verification is a trust chain framework.

For example, an X.509 signature, where the authenticity is guaranteed by the Certificate Authority (CA) that issued the certificate (in a centralized form).
For example, a PGP signature ensures authenticity through a chain of trust based on "I trust you, and you trust him" (a decentralized form).

The SSH signature currently used by the OP does not have this trust chain mechanism, so it cannot guarantee the authenticity of communication.

BG2ELG

BI1QJQ

I agree. Although the original poster briefly mentioned "public key distribution," this is indeed a crucial aspect.

What I can think of:

Tonglian said his public key (which is unrealistic) at the time.
On Tonglian, you would provide the URL where your public key can be found, such as in your personal information on qrz.com.
Offline key exchange with a real person

BI1QJQ

After reviewing the draft, I have a question.

Alice and Bob need to exchange their respective public keys in advance within the Tonglian system to establish trust.

However, even the public key of ed25519 is long enough, and it's necessary for both parties to agree on a short URL in order to easily exchange keys over radio.

If the public keys are not exchanged, it will be impossible to perform the QSL card signature verification.

BG5UWQ

BI1QJQ BG2ELG

The article already mentions the premise.

2. Scope
This paper defines a method for digitally signing digital QSL cards. However, this paper does not specify requirements for the distribution, trust, and revocation processes of public keys.

Therefore, regarding only the signature level, I believe that the process implemented by the original poster is already sufficient. Discussions may need to be separated into different topics.

I have a few questions.

First pointThe following terms mentioned in the article:

Please note: The end of the document should not contain any extraneous characters (including line breaks, spaces, tabs, etc.), i.e.,<EOR>The string does not contain any characters.

If a QSL card contains multiple QSOs, the corresponding ADIF file should be created by directly concatenating the ADIF data of each QSO in chronological order based on the communication time. The file should not contain any extraneous characters (including newline characters, spaces, and tab characters) at the end, i.e., it should start with the data of the last QSO. <EOR> It does not contain any characters.

The term "The last contact (QSO) <EOR> It does not contain any characters."In practice, this may not always be possible, and most cases will include a carriage return character. At this point, would additional software processing be required?"

Second pointThe signatures in the document appear to be those of Single The method involves signing a single QSO within an ADIF file, for example, by reading it. <EOR> Identification, rather than <EOH> If the data consists of 500 QSOs, and I have a corresponding signature information, where should I store it?

Third point, in the text 6.2.1 Constructing an ADIF file, which was missing. FREQ Are these fields intentionally included?

Fourth pointI would like to discuss a scenario where the signature information extracted from ADIF messages is a summary, and it's irreversible. I saw in the comments that the original poster mentioned this. QR code If the information is displayed on the card, and it's possible to directly display the corresponding QSO payload information by scanning a code at this time, then what are the possibilities or necessities for implementing such a feature?

Finally, regarding layout, I still recommend the translation plan provided by Jue Jin. Guidelines for Translation Formatting - Standardize the use of Chinese text and formatting, reduce communication costs, enhance the consistency and style of translations, making them more readable.

erjiaqing

BG2ELG

The distribution of public keys warrants a separate RFC, but I believe it will ultimately converge towards some form of PKI system.

There are several key considerations when exchanging public keys:

If a license is revoked, QSLs issued before revocation would theoretically still be valid, but those issued after would be invalid. In this case, there needs to be a mechanism to revoke the corresponding ones.
Offline, direct exchanges are clearly impractical (since it's difficult to directly exchange with certain individuals in person), but we can "trust" certain people who can issue certificates on behalf of others (while also being responsible for verifying identities and checking license status).
Tonglian stated the URL of his public key, such as when entered in the personal information section on qrz.com. This is essentially the current approach for public key servers, but it doesn't actually solve the trust problem. Furthermore, it also cannot address the issue of a call sign expiring and being reassigned.

erjiaqing

BG5UWQ

First, the following mentioned in the article:

Please note: The end of the document should not contain any extraneous characters (including line breaks, spaces, tabs, etc.), i.e.,<EOR>The string does not contain any characters.

If a QSL card contains multiple QSOs, the corresponding ADIF file should be created by directly concatenating the ADIF data of each QSO in chronological order based on the communication time. The file should not contain any extraneous characters (including newline characters, spaces, and tab characters) at the end, i.e., using the data of the last QSO. <EOR> It does not contain any characters.

The "last QSO" here refers to <EOR> "The string should not contain any characters," but in reality, this may not always be possible; most strings will actually contain a carriage return character. In such cases, would additional programming be required?

In fact, even when carriage return characters are included, considering different line-ending formats like CRLF, additional program processing is often required. In comparison, not including any characters might be slightly simpler, for example, within a shell environment.

echo "xxxxx"

This generates a string that does not contain trailing carriage returns.

Secondly, the signatures in the text appear to be applied individually to a single QSO within an ADIF file, for example, after reading. <EOR> Identification, rather than <EOH> If the data consists of 500 QSOs, and I have a corresponding signature information, where should I store this information?

The text mentions that all QSOs should be concatenated in chronological order.

The scenarios considered here involve a small number of QSOs and point-to-point signatures. Given the practical use of QSL cards, they typically do not include all QSO details, so a scenario where hundreds of QSOs are signed in one go might not be particularly suitable (because it's unlikely that each individual QSO would be verified).

The methods mentioned in this article primarily focus on allowing the recipient to easily construct the original ADIF file for verification. If a single signature covers 500 QSOs, it's unlikely that the other party involved in the QSO will perform the verification; instead, the large ADIF file can be directly signed.

(Together with point 1) When designing, I considered the specific format of the ADIF file. After some internal thought, I ultimately set the design goal to "machine construction, while also accommodating human input." The main scenario is: after manual entry of QSO information, the machine reads the signature, and then verifies it.

Thirdly, in section 6.2.1, the ADIF construction lacks a "FREQ" field; was this intentional?

Yes, initially, there's a certain redundancy between FREQ and BAND, meaning that one must be chosen over the other.

Secondly, considering that comparisons of QSLs (including those during competitions) typically only check against frequency bands rather than specific frequencies, the text chose BAND instead of FREQ.

Currently, I am open to this issue, but I personally prefer to use BAND.

In my actual communication, I have also encountered situations where there are specific requirements for QSL content (the most common being the inclusion of grid coordinates). It might also be worth discussing the options for other fields.

Fourth, I would like to discuss a scenario: if the signature information extracted is an ADIF message summary that is irreversible, and as the楼主 mentioned in the comments, QR codes are displayed on the card, then could it be possible or necessary to directly display the corresponding QSO payload information by scanning the code?

There's a possibility, but I don't think it's necessary.

In the text, I mentioned "7. Include original QSO data," which refers to a simple description of how to embed the original QSO payload within it. Due to the size constraints for QR codes, several compromises were made. Also, this chapter does not contain overly detailed design specifications. Currently, my goal is that there will be another RFC specifically focused on this topic.

Finally, regarding formatting, I still recommend the "Translation Formatting Guidelines" provided by the "Translation Plan" from JueJin. This resource offers standardized Chinese text and formatting practices to reduce communication costs, enhance the consistency and style of translations, and make them more readable.

Thank you. I haven't made many formatting adjustments, and the input method options provided by the software only offer basic punctuation options besides quotation marks. After a quick read of the article, because I rely heavily on the formatting engine, I tend to—

Both Chinese and Western text are combined without spaces; the spacing is handled by the typesetting engine.
Considering conventions in technical literature, use non-proportional punctuation (except for quotation marks). If necessary, allow the typesetting engine to perform any required conversions (but always end sentences with a period).
The use of traditional Chinese characters in regular font instead of bold font for italics is still handled by the typesetting engine.

This is primarily to ensure that a single version of the source file is available for distribution in different locations.

(Perhaps I can later post the full content on GitHub for review, and continue to synchronize the content between the two platforms.)
(However, I admit that this RFC did not fully implement it.)

BG8LGP

Blockchain can solve a range of problems, such as trust mechanisms and public key exchange, regarding the automatic signing of eQSL cards. The confirmation of log records through Tonglian (presumably a specific platform or system) can also be achieved using smart contracts. I am currently researching this, and if possible, would like to involve everyone in developing a solution based on our collective strengths.~~Search for my GitHub username.~~

erjiaqing

I quickly printed a few QR codes using a 24-needle printer, and here are the initial observations:

Simplified signature: 1.8mm x 1.8mm or larger can be recognized.
Full signature: 2.3mm x 2.3mm or larger can be recognized.

This size is slightly larger than I had anticipated (I was envisioning a more compact signature, around 1.3x1.3 for a basic version and 2.0x2.0 for a full version). I'm not sure if there are any better settings that could produce clearer QR codes. If anyone has experience with printing invoices, perhaps they could offer some advice?

I feel that if it were too large, it might be difficult to format. Therefore, directly embedding the QSL card within a QR code could present many difficulties. The main issue is that after embedding the QSL card, it becomes variable in length, and the size of the QR code no longer remains constant. Furthermore, the minimum size would significantly increase, making formatting more challenging.

So, I was thinking about whether it would be possible to include the hash of QSOs (i.e., the hash of the signed ADIF file) inside. The idea is that regardless of how the signature is handled, we can rely on a third-party service for verification. QSOs could define a common interface and use the hash for indexing, followed by some kind of exchange mechanism.

The size of the QR codes generated in this way should be acceptable.

AD2AG

erjiaqing
If you're willing to sacrifice some ease of use, consider using digital steganography. You could treat the entire QSL card as an image and embed a QR code in the frequency domain. However, this would make it difficult to directly photograph the QR code with a camera for verification.

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

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

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

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