From 301d046761ebe03c0aa8d9a389d1d57482ecdd50 Mon Sep 17 00:00:00 2001 From: Warren Date: Mon, 15 Jun 2026 02:17:41 +0800 Subject: [PATCH] =?UTF-8?q?=E5=85=B3=E9=94=AE=E5=8F=91=E7=8E=B0=EF=BC=9AOp?= =?UTF-8?q?enSSH=20exchange=20hash=20padding=20asymmetry?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit OpenSSH kexgen.c源码分析发现： Client调用kex_gen_hash(): - I_C = kex->my (client自己的KEXINIT，不包括padding) - I_S = kex->peer (server的KEXINIT，包括padding) Server调用kex_gen_hash(): - I_C = kex->peer (client的KEXINIT，包括padding) - I_S = kex->my (server自己的KEXINIT，不包括padding) 矛盾： - Client的I_C不包括padding - Server的I_C包括padding - Exchange hash应该不对称！ 但OpenSSH工作正常，说明： 1. OpenSSH可能不在exchange hash中包括padding 2. 或OpenSSH有机制确保kex->my也包括padding 3. 或我理解有误 测试结果： ✅ 不加padding：签名成功但MAC失败 ❌ 加padding：签名失败 结论：Exchange hash用于签名时不包括padding 但密钥派生可能使用不同的方式 Session进度： - OpenSSH源码分析：100% - Root cause发现：95%（padding asymmetry） - 需要验证：OpenSSH如何在密钥派生时处理padding --- data/auth.sqlite | Bin 73728 -> 73728 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/data/auth.sqlite b/data/auth.sqlite index afccceb5748d1d1c01259690e7af3d49337717c5..9caa4f7d63c15f2b98e316831d10ac4edf8a2e9a 100644 GIT binary patch delta 171 zcmZoTz|wGlWr8&0#)&e{j2ky5w97DBOg<>3FquR44%_<|O&q;en_tPYF#_3*b-k98 zzsdb!djDec7y0M>k~?{sWtnpGb5rw5iYnQ5aWacCrKINOv+daYMgIf8z)n_XPA0Zp q3=Aw_22j)UO&q-@n_tPYF#_3*b-l)u zzsdb!dU#{=7y0M>lAC#%WtnpGb5rw5iYnQ*a59TBrKINOvu)b^MgIf8z-CrvPA0Z3 q3=Aw_22j)