Re: [jose] #8: Direct mode for key agreement needs security analysis

"jose issue tracker" <> Mon, 15 April 2013 18:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B6E6621F95DE for <>; Mon, 15 Apr 2013 11:53:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mHRHtiKzf8ni for <>; Mon, 15 Apr 2013 11:53:36 -0700 (PDT)
Received: from ( [IPv6:2a01:3f0:1:2::30]) by (Postfix) with ESMTP id 4084521F958A for <>; Mon, 15 Apr 2013 11:53:31 -0700 (PDT)
Received: from localhost ([]:54950 ident=www-data) by with esmtp (Exim 4.80) (envelope-from <>) id 1URoWh-00057Q-Bt; Mon, 15 Apr 2013 20:53:15 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "jose issue tracker" <>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
X-Trac-Project: jose
Date: Mon, 15 Apr 2013 18:53:15 -0000
Message-ID: <>
References: <>
X-Trac-Ticket-ID: 8
In-Reply-To: <>
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Resent-Message-Id: <>
Resent-Date: Mon, 15 Apr 2013 11:53:31 -0700 (PDT)
Subject: Re: [jose] #8: Direct mode for key agreement needs security analysis
X-Mailman-Version: 2.1.12
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Apr 2013 18:53:39 -0000

#8: Direct mode for key agreement needs security analysis

Comment (by

 Personal Opinion -
 I have no problems with using the key that is the output of a key
 agreement directly as the content encryption key.  The rules here are
 going to be the standard ones such as you must make sure that the same key
 is not going to be generated each time and thus there is a requirement for
 a random value to be included from the senders side.  However there is not
 going to be a significant difference between the case of using this output
 to wrap a key vs using this output to wrap a body.

 I have no issues with this mode of encryption from a cryptography

 I think that a more significant question deals with the processing.
 Allowing this generates a new path for dealing with processing of messages
 which potentially complicates the analysis of the code.  The requirement
 exists for doing the key wrap state in the event of multiple recipients
 and potentially should be a requirement for even the single recipient

 Reporter:               |       Owner:  draft-ietf-jose-json-web-        |
     Type:  defect       |      Status:  new
 Priority:  major        |   Milestone:
Component:  json-web-    |     Version:
  encryption             |  Resolution:
 Severity:  Active WG    |
  Document               |
 Keywords:               |

Ticket URL: <>
jose <>