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 四个字节、大端序表示的字符串长度和由前述长度指定的字节串, 串中可以有Unicode NUL字符, 串位不含有多余的Unicode NUL字符. uint32 四个字节、大端序表示的32位无符号整数. byte[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 数字签名的有效载荷为一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 if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } 其ADIF转写为: <QSO_DATE:8>20221231<TIME_ON:6>180000<BAND:3>20M<CALL:6>BB0BBB<MODE:3>USB<STATION_CALLSIGN:9>B4/BG6TOE<OPERATOR:6>BG6TOE<EOR> if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } 该文件的 xxd 转储为: 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> if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } 需要注意：文末不应有任何多余字符（含换行、空格、制表符等）, 即 <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 if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } 其中： 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) if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } 其中： 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 字段. 附加原始QSO数据签名前可附加原始QSO数据，以方便机器直接识别、校验。原始QSO数据为精简表示的极小QSO元数据，包含以下字段：通联时间、通联波段、通联模式、收方呼号、发方呼号、OP。其格式为： byte[6] MAGIC_PREAMBLE varint call varint station_callsign varint operator ssh-string data if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } 其中，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 |+----+----++----+----+ +----+----+ if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } 如 B1CRA 表示为 11 * 37^4 + 1 * 37^3 + 12 * 37^2 + 27 * 37 + 10 = 20683861 其中，data为多个最小QSO拼接而成的字符串，其格式为 varint QSO Timestamp varint Band byte[8] Mode if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } 其中QSO Timestamp为协调时1970年元旦以来的秒数（但精确到分钟）。Band为波段对应频率的低端（千赫兹）数，如20米波段表示为14000。Mode为表示模式的字符串，不足8字节用 \0 补全。示例假设 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 if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } ST4TION 的私钥为: -----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW QyNTUxOQAAACADTnJZ6blw4CsqVoxzv9iWVVl0ycM8Neqb9QvTyvKqCAAAAJiuWf0orln9 KAAAAAtzc2gtZWQyNTUxOQAAACADTnJZ6blw4CsqVoxzv9iWVVl0ycM8Neqb9QvTyvKqCA AAAEDgyhqzLTK6rmVqjfvHpvHPYJzdeVuDhRo93XO98jDl1QNOclnpuXDgKypWjHO/2JZV WXTJwzw16pv1C9PK8qoIAAAAFW1hdHN1QEJHNlRPRS1Ob3RlYm9vaw== -----END OPENSSH PRIVATE KEY----- if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } 其公钥为: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIANOclnpuXDgKypWjHO/2JZVWXTJwzw16pv1C9PK8qoI if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } 则其构造如下的ADIF数据(签名有效载荷): <QSO_DATE:8>20230101<TIME_ON:6>020500<BAND:3>20M<CALL:4>TE5T<MODE:4>MFSK<STATION_CALLSIGN:5>C3SHI<OPERATOR:7>ST4TION<EOR> if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } 需要注意: 卡面上的北京时间应转换为协调世界时生成的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 if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } 构造如下被签名数据: 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.... if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } 应用前述私钥及 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. if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } 构造签名: 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. if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } 精简签名： 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. if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } 签名的Base64编码: U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgA05yWem5cOArKlaMc7/YllVZdMnDPDXq m/UL08ryqggAAAAKYWRpZi1xc2x2MQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQyNTUxOQAA AECChPnty474bN9b7sNHZ2KE6s5LRkRkKWkAQTlueZu990wrlA5TVB5N+pTbcEqbd6rRTc0uXWs/ MMZExn6Eyk0H if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } 精简签名的Base64编码： RFFTTFYxgoT57cuO+GzfW+7DR2dihOrOS0ZEZClpAEE5bnmbvfdMK5QOU1QeTfqU23BKm3eq0U3N Ll1rPzDGRMZ+hMpNBw== if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } 签名的Base45编码: 1OAK69*B9000100000610000B00ZQET7D CSF6RW6C97000524C-9MGB.JNCFS%F50YHHBOA0J+DB MPNR7TTT1:U%YQMUUN010002E1AVCC-CIFE1WDY86000000000V 0 8DRW6KE60008MA0006K1OQEBX50UCVW61A6000J10MMG QV0XPBIVTASD8U919KKCZUTAN93T8QA5K10WB7 GFV0OES9CWI2OAH$3NUVGXRJJ9Y5FVKQB.PK BL:7-2P94PJZG9X9 if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } 精简签名的Base45编码： TS8*NAF+AMMG QV0XPBIVTASD8U919KKCZUTAN93T8QA5K10WB7 GFV0OES9CWI2OAH$3NUVGXRJJ9Y5FVKQB.PK BL:7-2P94PJZG9X9 if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } 信息性引用文件 RFC4634 US Secure Hash Algorithms (SHA and HMAC-SHA) RFC4648 The Base16, Base32, and Base64 Data Encodings RFC8709 Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol RFC9285 The Base45 Data Encoding) ADIF Amateur Data Interchange Format (ADIF) Specification

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

Yofoa-Film-Studio 不是对QSL卡签名，而是对卡上的信息签名所以可以嵌入也可以分开其实就是类似于发票上那个东西

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

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

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

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

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

[RFC] QSL卡片的数字签名

erjiaqing

BG2ELG

公钥分发值得一篇单独的RFC，但我觉得最终会收敛到某种PKI体系。

交换公钥有很多需要考虑的问题：

如果执照被吊销，理论上被吊销之前的QSL都是有效的，但之后的QSL都是无效的，那么此时需要有一个机制吊销对应的
线下真人交换显然不够现实（毕竟很难和某一些人直接线下交换），但我们可以“信任”某些人，他们可以为其他人签发证书（同时他们也要负责核验身份和核查执照状态）
通联时说出自己公钥的网址，如在 qrz.com 个人信息中写入，这种其实就是目前公钥服务器的思路，但其实不大能解决信任的问题，以及，如果呼号过期被重新指配的问题也不能解决

BG8LGP

区块链能解决诸如信任机制和公钥交换的一系列问题，对eQSL卡的自动签名问题，通联日志记录确认也可以用智能合约去完成，我正在思考与研究，如果可以，大家一起来参与，集大家所长去搞出来一个方案。~~Github搜我呼号~~

erjiaqing

简单拿某24针打印机打了一点二维码，目前观测结果如下：

精简签名：1.8mmx1.8mm及以上可以识别
完整签名：2.3mmx2.3mm及以上可以识别

这个尺寸比我预想的尺寸要略大一点（我设想是1.3x1.3的精简签名，2.0x2.0的完整签名）我不确定是否还有更好的设置可以获得更清晰的二维码，如果有人打过发票或许可以给点经验？

感觉如果再大的话可能不好排版，这么想来直接在二维码里嵌入QSL可能还有很多困难，主要是嵌入QSL之后变成了变长内容，二维码的尺寸不再是常数，而且最小尺寸会显著变大，不便于排版

那么我在思考能不能往里面塞QSO的哈希（就是被签名的ADIF的哈希），想法是无论如何签名都不能依赖第三方服务，QSO可以再定义通用接口，通过哈希来索引，然后再做某种交换机制。

这样生成的二维码尺寸应该是可以接受的

AD2AG

erjiaqing
如果放弃一些易用性的话，不如试试数字隐写。可以考虑将QSL卡面整体认为是一张图片，在频域插入二维码。只不过这样做就不能方便的用相机直接拍摄二维码来进行验证了。

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]

bh2vrn

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

BI1QJQ

最近几天重新研究了一下，提出几点想法

这个 qsl signature 的具体场景是不是更多的对一张 QSL Card 进行签名？
如果是的话，是不是可以强制要求签名有效载荷只包含一条 Record？
理论上来说，一张 QSL Card 基本上不可能写很多信息，如果是不同的通联组合，如 Mode 不同，那么交换双方一般会采用多张 QSL Card 进行

另外这个数字签名办法可能更像一个 Specification，日后随着时间的演进，如果出现性能更好的更 compat 的签名和 hash 算法，可以考虑进行替换，最好采用一个版本系统对它进行追踪，在具体签名的字段设置上也应该设置上对应的版本字段，以方便 client 进行版本兼容（不过这个版本字段应该都设置上了）

最后，本文大量引用了 openssh PROTOCOL.sshsig 文档作为其前置知识，但是最后的参考资料却没有引用，这里附上网址

erjiaqing

BI1QJQ

是的，这个是对一张QSL进行签名
考虑到打印出来的签名不包含载荷（即分离签名），私以为没有必要要求签名有效载荷只包含一条QSO
是的，所以我特地使用了adif-qslv1作为SSH签名的namespace，日后如果继续使用SSHSIG但是换了签名算法、载荷内容可以使用别的namespace，用于打印的精简签名也带上了版本号
考虑到BASE45是用QRCode编码二进制内容的事实标准，且日后签名内容理应当都是二进制数据，我不认为此处应当设置标识，印刷的时候可以另外注明