From nobody Tue Mar 1 11:12:41 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9115D1B3FE6 for ; Tue, 1 Mar 2016 11:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ar7eu0mh7LM2 for ; Tue, 1 Mar 2016 11:12:38 -0800 (PST) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 680C81B3A19 for ; Tue, 1 Mar 2016 11:12:38 -0800 (PST) Received: by mail-lf0-x235.google.com with SMTP id j186so45712943lfg.2 for ; Tue, 01 Mar 2016 11:12:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to; bh=s8N9gMeyF2tYqYbeF7+1CU/k738nlJ3xNaz3YA+kbJc=; b=mBM6n8lpAEe+QoNSXMx4CljgvFOZu8qi2wTR5xmK2tr80MxxXk+RZiySpixX9vCfbw 93AmBuqiv8IETmXQ8toe4WWNhtJvYRytMkZdna1MJQAxwYr19e7+k22EeMR528NbiSbJ mY4H4d1sNaHO+VHlX02fSAP4qrueathbbpqbDZbGUdB6oKrvr5JPutwZvlP5fSaWHY5T 0qkBv26m1QFBuelWbIc+N0rmMheIxOsQs8QE22xe3w9MDWudADEerfEmW/nQCsyiGAnH MuD05ZAMSTQm+4WeFFIsuSAQ+80vDdqTtOjr5OSdnyhdrypjgJmYy/2iJromvYww4bP7 HJ5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to; bh=s8N9gMeyF2tYqYbeF7+1CU/k738nlJ3xNaz3YA+kbJc=; b=EF+fxIOrO6nAVQzCvbSzRNKfHuEs3xFgWmnHk+KltfBv40CfxH4jg77YO3OTUvwFm1 G/JsAU1Uewf0ynHPXJ4LnqPvRhwmY/4GtZV8wRGJPr1i6ZSZS0xDCkketZ2OGwMYucwH diIMsHY1Kaj3SAyzF/q5g9eSBkmDulSJ0sm3nJVTCUWzVkokRDjHnGJIz8SrssGj7CKK 050Unc49NHMwYaJ3JSwq6njBWpkUEHOt4MrK85oh0CTlAduPMneDu0I4LXcY0d9P2wku 4H6Q8QgLrulFQKo5UU2dF6S7zHhQT6qThekC6C3/RrY8Yl91Xs6whg8bo7kaFe18/zRo tjzA== X-Gm-Message-State: AD7BkJJ9JC+zrHCd9Yc0VDqC2wdQwC+DRpHYeSPx7ioxmhDdagbd4wdXOULg45QJBzOOHZQoC446NgpZoeMcPw== MIME-Version: 1.0 X-Received: by 10.25.205.7 with SMTP id d7mr8525585lfg.70.1456859556458; Tue, 01 Mar 2016 11:12:36 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.151.67 with HTTP; Tue, 1 Mar 2016 11:12:36 -0800 (PST) In-Reply-To: <87d1s27wwa.fsf@vigenere.g10code.de> References: <56BB0308.8020504@iang.org> <20160210160641.GA3090@singpolyma-liberty> <9A043F3CF02CD34C8E74AC1594475C73F4BED18C@uxcn10-5.UoA.auckland.ac.nz> <87lh6rbp5n.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4BEE527@uxcn10-5.UoA.auckland.ac.nz> <87d1s27wwa.fsf@vigenere.g10code.de> Date: Tue, 1 Mar 2016 14:12:36 -0500 X-Google-Sender-Auth: XC4oNLsR_wEw9iG-OEyrfrBgxxA Message-ID: From: Phillip Hallam-Baker To: Peter Gutmann , Stephen Paul Weber , "openpgp@ietf.org" , ianG Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [openpgp] saltpack on OpenPGP message format problems X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 19:12:39 -0000 Reconsidering this issue in the wake of the Apple/FBI set to... I think one point that has been massively overlooked by traditional crypto applications is the need to store private keys securely. In particular, it should be possible to fix private keys to a device such that the key can be used on that device but it is not possible to remove the key from the device and install it on another device without 'heroic' efforts (e.g. uncapping the CPU and reading it with a scanning electron microscope). In particular, this has tended to be something that it is 'assumed' is merely a platform issue. But having tried to implement such, I am very sure that it is not and that you really need to consider the use of trustworthy security features such as the iOS Secure Enclave or Microsoft's TPM. when designing the protocol. And I have no doubt that the NSA BULLRUN shills have been assiduously stroking anti-DRM ideology as a way of discouraging implementation of strong hardware security measures. Now that we are seeing machine compromise as a vector for poisoning open source projects with malware, we need to change our approach. What would help perhaps is some better info as to what features are out there and widely supported. The NSA has been very successful in discouraging people from pushing for these features. But they are very much needed. From nobody Tue Mar 1 23:29:51 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6731A6FD8 for ; Tue, 1 Mar 2016 23:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZ8ql8TgDqBC for ; Tue, 1 Mar 2016 23:29:48 -0800 (PST) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5327B1A6FD6 for ; Tue, 1 Mar 2016 23:29:48 -0800 (PST) Received: from airhead.local ([83.161.146.46]) by smtp-cloud6.xs4all.net with ESMTP id QvVh1s00k10HQrX01vVibN; Wed, 02 Mar 2016 08:29:46 +0100 Message-ID: <56D69664.4040802@openfortress.nl> Date: Wed, 02 Mar 2016 08:29:40 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Phillip Hallam-Baker References: <56BB0308.8020504@iang.org> <20160210160641.GA3090@singpolyma-liberty> <9A043F3CF02CD34C8E74AC1594475C73F4BED18C@uxcn10-5.UoA.auckland.ac.nz> <87lh6rbp5n.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4BEE527@uxcn10-5.UoA.auckland.ac.nz> <87d1s27wwa.fsf@vigenere.g10code.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Stephen Paul Weber , "openpgp@ietf.org" , ianG , Peter Gutmann Subject: Re: [openpgp] saltpack on OpenPGP message format problems X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 07:29:51 -0000 Hello, Phillip wrote: > I think one point that has been massively overlooked by traditional > crypto applications is the need to store private keys securely. In > particular, it should be possible to fix private keys to a device such > that the key can be used on that device but it is not possible to > remove the key from the device and install it on another device > without 'heroic' efforts (e.g. uncapping the CPU and reading it with a > scanning electron microscope). You seem to be talking of PKCS #11. It's possible to use that under OpenPGP but I've found the GnuPG implementation made it difficult. Unlike the PGP card, which is more specific to the OpenPGP purpose, this is a general standard for which many implementations exist in USB sticks, ranging up to HSMs and even software low-end solutions. FWIW, I had no problem implementing PKCS #11 for OpenPGP, https://github.com/arpa2/tlspool/blob/master/tool/pgp11_genkey.c This is only key generation (including self-signing) which is what I needed for this project (which moves TLS to a daemon that uses PKCS #11) but other things can also easily be moved to OpenPGP implementations. Cheers, -Rick From nobody Tue Mar 8 04:56:48 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9B212D69C for ; Tue, 8 Mar 2016 04:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3kw3PPfOhbi for ; Tue, 8 Mar 2016 04:56:45 -0800 (PST) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7E612D5EF for ; Tue, 8 Mar 2016 04:56:44 -0800 (PST) Received: from p508130ba.dip0.t-ipconnect.de ([80.129.48.186] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1adHBo-0002FB-5o for openpgp@ietf.org; Tue, 08 Mar 2016 12:56:40 +0000 Received: from grit.huenfield.org ([192.168.20.253]) by mail.huenfield.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1adHBl-0006P3-9O for openpgp@ietf.org; Tue, 08 Mar 2016 13:56:39 +0100 Received: from ip6-localhost.huenfield.org ([::1] helo=grit.huenfield.org.walfield.org) by grit.huenfield.org with esmtp (Exim 4.84) (envelope-from ) id 1adHBk-0004Qf-2e for openpgp@ietf.org; Tue, 08 Mar 2016 13:56:36 +0100 Date: Tue, 08 Mar 2016 13:56:36 +0100 Message-ID: <87oaap86wr.wl-neal@walfield.org> From: "Neal H. Walfield" To: openpgp@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 192.168.20.253 X-SA-Exim-Mail-From: neal@walfield.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 17:06:47 +0000) X-SA-Exim-Scanned: Yes (on mail.huenfield.org) Archived-At: Subject: [openpgp] encrypted packets' quick integrity check X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 12:56:47 -0000 Hi, I recently took a look at the Mister and Zuccherato attack on the quick integrity check in encrypted packets (i.e., that the last two bytes of the IV are correctly repeated)and I have two suggestions for RFC4880bis. The attack relies on finding the correct values for the quick integrity check using an exhaustive search. This can be defeated by making an exhaustive search unfeasible. Concretely, instead of just copying the last two bytes of the random IV, we replicate the whole IV. This should be easy to do for SEIPD packets, since we have a version field. Alternatively, we could store the hash of the session key, as Mister and Zuccherato suggest in Section 5.2 of their paper. Also, the following text regarding this issue is in RFC 4880: In winter 2005, Serge Mister and Robert Zuccherato from Entrust released a paper describing a way that the "quick check" in OpenPGP CFB mode can be used with a random oracle to decrypt two octets of every cipher block [MZ05]. They recommend as prevention not using the quick check at all. Many implementers have taken this advice to heart for any data that is symmetrically encrypted and for which the session key is public-key encrypted. In this case, the quick check is not needed as the public-key encryption of the session key should guarantee that it is the right session key. In other cases, the implementation should use the quick check with care. As far as I can tell, the attack applies equally well whether a PK-ESK or SK-ESK packet is used to store the session key. This is because the attack just exploits the session key; it doesn't matter how it is stored. Does anyone know why this attack should not apply to SK-ESK packets (FWIW, GnuPG uses the check when the session key is stored in an SK-ESK packet, but not when it is stored in a PK-ESK packet)? If not, I think this text should be updated to remove "and for which the session key is public-key encrypted". Thanks! :) Neal From nobody Wed Mar 9 20:31:38 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381D312DD8D for ; Wed, 9 Mar 2016 20:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJk0iZCse6z6 for ; Wed, 9 Mar 2016 20:31:35 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B00312DD8C for ; Wed, 9 Mar 2016 20:31:35 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id g127so58456942ywf.2 for ; Wed, 09 Mar 2016 20:31:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vFDY3Nn91okykC6ySfiyvYGHkyILWYf3rube/NjGk+c=; b=JvaOhqvjjwaUbcBvErmDrlbMy29FHmYhrJu0q2Yv3vhQzhDHSpbBCqaxs2FP8f4VF4 BaTPxhBLwvsq6CmKGKN8VCCa/gAJXSX4XFl/jfclAo8HZYhpouWeDJhe941klEP299R6 fWMsokWfmz/t6/ltFeDXLBPSEXtSXBGWpv7nM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vFDY3Nn91okykC6ySfiyvYGHkyILWYf3rube/NjGk+c=; b=V/I5wKS8UJ7Gr+DPrK3+/x8Gj690mqzsE0boSya6yA6WsWo6B2ikgcRYut7cb0TUN/ mmmjhxRSYBKk2PLwFg+nfYAb2suG++I3RaSaLg0tnesq1+5bZslBlh9Z+zkxsO11weS9 DPYkpHzvyiXIreppFQz9wlppFMPy/o4kgMWzJQ7WjfTIUL/79vF2fLp6Ov3KFq2pyYnX Vt3MsDa8xPXIZWQo636H8ntNNrW20WaiDcRNUd7/Z8HO51vb/Ubk33WdIO1z5TVXCEHn gm6PilBDyJRmN+NzKBmuKuginOAn7pyvIcbNh00HIcOuEQFqW7DNmkXFFLu1tjY3BJk9 bL1Q== X-Gm-Message-State: AD7BkJKRt8UwXWA799YnsvQ9WHdkU6HlqAuTfJq1tzdZbn6O4BUWHLJJKOIy5US1S2HEGay4tWCLSJfRp25FX90r X-Received: by 10.129.88.69 with SMTP id m66mr711664ywb.332.1457584294599; Wed, 09 Mar 2016 20:31:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.126.197 with HTTP; Wed, 9 Mar 2016 20:31:15 -0800 (PST) In-Reply-To: <87oaap86wr.wl-neal@walfield.org> References: <87oaap86wr.wl-neal@walfield.org> From: Tom Ritter Date: Wed, 9 Mar 2016 22:31:15 -0600 Message-ID: To: "Neal H. Walfield" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] encrypted packets' quick integrity check X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 04:31:37 -0000 On 8 March 2016 at 06:56, Neal H. Walfield wrote: > Hi, > > I recently took a look at the Mister and Zuccherato attack on the > quick integrity check in encrypted packets (i.e., that the last two > bytes of the IV are correctly repeated)and I have two suggestions for > RFC4880bis. > > > The attack relies on finding the correct values for the quick > integrity check using an exhaustive search. This can be defeated by > making an exhaustive search unfeasible. Concretely, instead of just > copying the last two bytes of the random IV, we replicate the whole > IV. If we use a chunked AEAD mode that is safe for streaming (which I think we should) - can we just do away with the quick check entirely? -tom From nobody Mon Mar 14 07:37:34 2016 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35FE112DB37 for ; Mon, 14 Mar 2016 07:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIN7PG6DTg0y for ; Mon, 14 Mar 2016 07:37:27 -0700 (PDT) Received: from smtp1-2.ilait.se (smtp1-2.ilait.se [82.99.18.59]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E6B412DB29 for ; Mon, 14 Mar 2016 07:34:40 -0700 (PDT) Received: from ex-hub1-2.cloud.local (ex-hub1-2.ilait.se [62.109.34.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1-2.ilait.se (Postfix) with ESMTPS id EF8AF2405A8; Mon, 14 Mar 2016 14:34:37 +0000 (UTC) Received: from EX-MBX1-15.cloud.local ([fe80::e5af:a0a6:6a57:74b2]) by ex-hub1-2.cloud.local ([fe80::1d72:4618:a665:d303%13]) with mapi id 14.03.0174.001; Mon, 14 Mar 2016 15:34:37 +0100 From: Jonas Magazinius To: "Neal H. Walfield" , "openpgp@ietf.org" Thread-Topic: [openpgp] encrypted packets' quick integrity check Thread-Index: AQHReTn/sHbXA21ol0S1eOx6Ad/VuJ9Y++Nf Date: Mon, 14 Mar 2016 14:34:37 +0000 Message-ID: <4839758C632DAB46B985EF1ACCAE6A6CF4849F@ex-mbx1-15.cloud.local> References: <87oaap86wr.wl-neal@walfield.org> In-Reply-To: <87oaap86wr.wl-neal@walfield.org> Accept-Language: en-GB, sv-SE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.17.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] encrypted packets' quick integrity check X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 14:37:33 -0000 Hi,=0A= =0A= =0A= > The attack relies on finding the correct values for the quick=0A= > integrity check using an exhaustive search. This can be defeated by=0A= > making an exhaustive search unfeasible. Concretely, instead of just=0A= > copying the last two bytes of the random IV, we replicate the whole=0A= > IV. This should be easy to do for SEIPD packets, since we have a=0A= > version field. Alternatively, we could store the hash of the session=0A= > key, as Mister and Zuccherato suggest in Section 5.2 of their paper.=0A= =0A= If you reuse the entire IV the check itself will be very easy to bypass, ju= st prepend the ciphertext with two blocks of zeroes. =0A= =0A= Then in order for the rest of the ciphertext to make sense, you need to fin= d a block that, when decrypted, resembles a dummy packet of appropriate siz= e to line up with the rest of the packets. You can do that by adding anothe= r block between the zeroes and the original cipher text and bruteforce the = first few bytes of it. =0A= =0A= If you want to go in that direction, you can use the second half of the IV,= or the IV in reverse. That should fix the issue.=0A= =0A= =0A= Regards,=0A= Jonas=