From nobody Wed Oct 2 05:06:22 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961F2120071 for ; Wed, 2 Oct 2019 05:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 nfpZCpP1I0WI for ; Wed, 2 Oct 2019 05:06:18 -0700 (PDT) Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) (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 8220512000F for ; Wed, 2 Oct 2019 05:06:18 -0700 (PDT) Received: by mail-oi1-f171.google.com with SMTP id k25so17340213oiw.13 for ; Wed, 02 Oct 2019 05:06:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DnbPzADb3jBhGjmN+5nALmeA07s5/4qQLIS/kvXiE/0=; b=cGjxjM4qrDXDVwtt0/P8mqK8iQyv4tP3+nZV0c2t4ELehGiUa6XEAR8WzyT9iaUori o1yZp3i1CnxJNZ4WmDsFkdzTnbx9o0SMSIZFc/ZrNtd5kss+M8QJApOQ0nb0OcDjgNTK u88IFKkjnYQ+aTcs9+02V704QJhnCWu6vDiXA3JpNxpmoGzQ68H2wgL5h/JMaIZrTVpo 2Yh82gga4diKo+XOwDm+a6PLrMI/5nS4emf6xeyJnTnaCpeinG3UG9i4Cl2YHcDdD9P3 3n2fw67HNuEBscFXP0Ug7NnPPkkFk1sSD3R8Zs+tzCCIAuvrtC890mzZnvgcs9XxKOTP rXLw== X-Gm-Message-State: APjAAAVXLBeOlykirk/9P8UgQcS668VmoLW91iJsRKWojPNkySfJw+fA j+gS6jop38RwVJ1sqEyW9DzIveUyvdWghuhjJOo6EQ== X-Google-Smtp-Source: APXvYqwkZmbjrV6EWsGdoXF4JimRHNSatS5CNhJavIr2S3jyl8IqEsiESRofJXQN08ugT91HRBrLq4raAQ5tFX2oTR4= X-Received: by 2002:aca:2118:: with SMTP id 24mr2600596oiz.95.1570017977715; Wed, 02 Oct 2019 05:06:17 -0700 (PDT) MIME-Version: 1.0 References: <30079.1569796658@localhost> In-Reply-To: <30079.1569796658@localhost> From: Phillip Hallam-Baker Date: Wed, 2 Oct 2019 08:06:06 -0400 Message-ID: To: Michael Richardson Cc: mathmesh@ietf.org Content-Type: multipart/alternative; boundary="000000000000da50160593ec4b72" Archived-At: Subject: Re: [Mathmesh] Configure SSH with UDF key... X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2019 12:06:21 -0000 --000000000000da50160593ec4b72 Content-Type: text/plain; charset="UTF-8" On Sun, Sep 29, 2019 at 6:37 PM Michael Richardson wrote: > > Phillip Hallam-Baker wrote: > > The biggest hassle with SSH is how to install your private key on > each of > > the devices that you want to use it from. In theory of course, you > want to > > have an independent key for each device so that you are not > completely > > hosed if you lose one of them or you are passing through an airport > and > > someone demands you login to your laptop. > > > But most people have one private key and they move it from one > machine to > > another in email. Oh and 'most people' probably isn't most of the > people > > here. It only takes one pinhead to bust a hole in your corporate > defenses. > > So you have a fairly reasonable use case. > > I also observe the 90% of people don't use ssh private keys or understand > how > to use ssh-agent, or understand that they can keep their private key in > some > central place and use ssh -A/ssh-keyadd to gain access to it for the > current > session. This turns SSH into a far more KRB5-like ticket system with > limited > lifetimes, and so the private key on the laptop only lets one get to the > "home cloud"(owncloud) machine that holds the master key. > Sounds like an interesting approach. I was not aware of that but that might well be because my main terminal is running Windows which has only just acquired native SSH support and it is different from Linux in any case. > But MMM should let us do other things with SSH keys. Since 1996, I've > wanted > to do signed statements about logins, rather than hacking > ~/.ssh/authorized_keys files. > So each login results in a non-repudiable entry in a log so you know who logged in? Sounds like the way to go but would require someone with a lot more SSH foo than me to make it work. If I understand you correctly, you are trying to find a way to generate the > private key(s) in a deterministic way from a master secret which can be > split? > Yes, that is it. Generating private key sets from a master secret of arbitrary length via a KDF. > This way, the user doesn't use email to distribute their private key, but > rather can just recover it each time they might need it after a dangerous > situation. (Such as going through a border control, etc.) > Or if I want to turn on the disk level encryption on a device, I can do so and be 100% assured that I can recover from a paper backup in the fire safe or off site. > > What I was thinking of for implementation is to define a new type > code, > > probably 200 which gives an initial letter of Z. Then make the > following > > two bytes a 16 bit registry code saying what the key is to be used > for > > (Mesh, SSH, etc.) > > Seems like a useful thing. > OK, will add when I am done with the videos > > As with passwords, we might well need to help people follow their > current > > workflow in a not quite so stupid fashion before we try to change it. > > An illustrative video would help. > I am already working on a series of recruitment videos. First two are already recorded. Should get them to YouTube soon. Its a 24 hour flight to Singapore from the US. So thought I would make some suitable entertainment folk can take with them. --000000000000da50160593ec4b72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Sep 29, 2019 at 6:37 PM Michael Richardson = <mcr+ietf@sandelman.ca>= ; wrote:

Phillip Hallam-Baker <phill@hallambaker.com> wrote:
=C2=A0 =C2=A0 > The biggest hassle with SSH is how to install your priva= te key on each of
=C2=A0 =C2=A0 > the devices that you want to use it from. In theory of c= ourse, you want to
=C2=A0 =C2=A0 > have an independent key for each device so that you are = not completely
=C2=A0 =C2=A0 > hosed if you lose one of them or you are passing through= an airport and
=C2=A0 =C2=A0 > someone demands you login to your laptop.

=C2=A0 =C2=A0 > But most people have one private key and they move it fr= om one machine to
=C2=A0 =C2=A0 > another in email. Oh and 'most people' probably = isn't most of the people
=C2=A0 =C2=A0 > here. It only takes one pinhead to bust a hole in your c= orporate defenses.

So you have a fairly reasonable use case.

I also observe the 90% of people don't use ssh private keys or understa= nd how
to use ssh-agent, or understand that they can keep their private key in som= e
central place and use ssh -A/ssh-keyadd to gain access to it for the curren= t
session.=C2=A0 This turns SSH into a far more KRB5-like ticket system with = limited
lifetimes, and so the private key on the laptop only lets one get to the "home cloud"(owncloud) machine that holds the master key.

Sounds like an interesting approach. I was not aware of that but t= hat might well be because my main terminal is running Windows which has onl= y just acquired native SSH support and it is different from Linux in any ca= se.

=C2=A0
But MMM should let us do other things with SSH keys.=C2=A0 Since 1996, I= 9;ve wanted
to do signed statements about logins, rather than hacking
~/.ssh/authorized_keys files.

So each login results in a no= n-repudiable entry in a log so you know who logged in?

Sounds like the way to go but would require s= omeone with a lot more SSH foo than me to make it work.

If I understand you correctly, you are trying to find a way to generate the=
private key(s) in a deterministic way from a master secret which can be
split?

Yes, that is it. Generating private key sets from a = master secret of arbitrary length via a KDF.
=C2=A0
This way, the user doesn't use email to distribute their private key, b= ut
rather can just recover it each time they might need it after a dangerous situation. (Such as going through a border control, etc.)
<= div>
O= r if I want to turn on the disk level encryption on a device, I can do so a= nd be 100% assured that I can recover from a paper backup in the fire safe = or off site.
=C2=A0
=C2=A0 =C2=A0 > What I was thinking of for implementation is to define a= new type code,
=C2=A0 =C2=A0 > probably 200 which gives an initial letter of Z. Then ma= ke the following
=C2=A0 =C2=A0 > two bytes a 16 bit registry code saying what the key is = to be used for
=C2=A0 =C2=A0 > (Mesh, SSH, etc.)

Seems like a useful thing.

OK, will add when I am done wi= th the videos

=C2=A0
=C2=A0 =C2=A0 > As with passwords, we might well need to help people fol= low their current
=C2=A0 =C2=A0 > workflow in a not quite so stupid fashion before we try = to change it.

An illustrative video would help.

I am already working on a= series of recruitment videos. First two are already recorded. Should get t= hem to YouTube soon. Its a 24 hour flight to Singapore from the US. So thou= ght I would make some suitable entertainment folk can take with them.
=
=C2=A0
--000000000000da50160593ec4b72-- From nobody Wed Oct 2 07:34:33 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F53012012E for ; Wed, 2 Oct 2019 07:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 RBFFaQSZkrz7 for ; Wed, 2 Oct 2019 07:34:30 -0700 (PDT) Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) (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 288001200CE for ; Wed, 2 Oct 2019 07:34:29 -0700 (PDT) Received: by mail-oi1-f179.google.com with SMTP id w144so17816637oia.6 for ; Wed, 02 Oct 2019 07:34:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=D4TD7PfUlGlFggoGUAl2XvL5jHRaEDEnOSD6969wpe0=; b=a1Yh5uxIl3eGSKKGfVmcLlIhYO09mV2ggKHtq0h4SS1T7KhGp1Y/GbEmt9OninrpOM kfnFOVdZ+dBmLAvhSM9/pyIkfmDTiGRV3vtjeLAQOYdALdBcQdfQUfuxhrNSJye4KXTk Ptc+wES4Uu+hthn89cTZoNsP69c+SbFUPjcMLKnCHJsPAt3ihRfYQAskNmtjBJfhi+7w unIf5EPfff9NEvdi74MQBfxqQlSrCPpLtmC46tR7wU/Lfazyr6NaXmYrb9oAI4/8Phfl Ua5euUyKtRm/WKl6n3+w5C16dTHg7WA7DOsAoUxQDxXw6bwk8S7KM1bhQdPKFIe5qh3a GKug== X-Gm-Message-State: APjAAAXUvAMGKO3PBBMLzZ3/SdBEiXpV5ZF4k8wuJZ+iw35lGplm8iB2 H6g7/08pASmrx8F/gWLlYnU1ch4aPMBLV4+JnoHQ2fVi X-Google-Smtp-Source: APXvYqxle09jMxxMyTB2W7ppdqlWXSbP0+tseqjJ0TK6335Q+b5xhzrEhYBLy54Jym+XCnh1SimBHfyprZUg5YZy6L4= X-Received: by 2002:a05:6808:7cd:: with SMTP id f13mr3118734oij.6.1570026868086; Wed, 02 Oct 2019 07:34:28 -0700 (PDT) MIME-Version: 1.0 From: Phillip Hallam-Baker Date: Wed, 2 Oct 2019 10:34:15 -0400 Message-ID: To: mathmesh@ietf.org Content-Type: multipart/alternative; boundary="000000000000c2a4b00593ee5d02" Archived-At: Subject: [Mathmesh] BOF request X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2019 14:34:32 -0000 --000000000000c2a4b00593ee5d02 Content-Type: text/plain; charset="UTF-8" I submitted this to the ADs. Comments? In particular how to manage time. I am currently in the process of making a series of 20 minute video presentations on the Mesh project and component technologies. This should hopefully avoid the need to explain the technologies to a great extent in the room. It is a 24 hour flight after all... ==== MATHMESH (proposal) ==== - Name: MatheMatical Mesh (MATHMESH) - Description: To discuss scope of work to specify Mathemetical Mesh technologies. The Mesh consists of a user-centric PKI and a set of component technologies that are used to build it. The IETF (and/or IRTF) might choose to form a Working Group to pursue some, all or none of these. The component technologies of the Mesh include a naming mechanism (UDF), a cryptographic syntax (DARE) and the use of 'metacryptography' for threshold encryption and key provisioning. Each of these component technologies is closely related to prior IETF work with improved implementation and functionality. UDF provides a generalization of OpenPGP fingerprints using Base32 encoding (instead of hex), modern digest algorithms (SHA2/3) and addressing semantic substitution attacks. The mechanism is also extended to support symmetric keys, nonces, secret sharing and embedding in URIs and QR codes. DARE provides an envelope format that approximates to PKCS#7 in JSON. DARE envelopes are designed to stack in DARE Sequences which afford blockchain like incremental integrity assurance through use of a Merkle Tree and incremental encryption by means of a salted Key Derrivation Function. Metacryptography is marketecture for the use of the 'new' cryptography based on the new CFRG Elliptic Curves. Threshold encryption affords a novel approach to cloud security by splitting the private decryption key. This allows a cloud service to control the ability to decrypt without having the ability to decrypt. The key composition mechanism enables the novel approach to key provisioning employed in the Mesh. The Mesh itself is a user centric PKI that applies the above technologies to make computers easier to use by making them more secure. It also represents the use case that motivated the development of the component technologies and is built on that foundation. While the IETF may choose to work on any or all of the component technologies and not work on the Mesh itself, the reverse is not practical. - Status: WG Forming - Responsible AD: Benjamin Kaduk, Roman Danyliw - BoF proponents: Phillip Hallam-Baker - BoF chairs: Rich Salz - Number of people expected to attend: 100 - Length of session (1, 1.5, 2, or 2.5 hours): 2.5 hours - Conflicts to avoid (whole Areas and/or WGs): WEBPACK, SECURITY - Agenda - Items, drafts, speakers, timing - Or a URL - Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc. - Mailing List: https://www.ietf.org/mailman/listinfo/mathmesh - Draft charter: TBS - Relevant drafts: - Overview of the project - https://datatracker.ietf.org/doc/draft-hallambaker-mesh-architecture/ - Component technologies - Fingerprint https://datatracker.ietf.org/doc/draft-hallambaker-mesh-udf/ - PKCS#7/Blockchain https://datatracker.ietf.org/doc/draft-hallambaker-mesh-dare/ - Metacryptography https://datatracker.ietf.org/doc/draft-hallambaker-mesh-cryptography/ - Mesh specific technology - Schema https://datatracker.ietf.org/doc/draft-hallambaker-mesh-schema/ - Protocol https://datatracker.ietf.org/doc/draft-hallambaker-mesh-protocol/ - Additional - Security Considerations https://datatracker.ietf.org/doc/draft-hallambaker-mesh-security/ --000000000000c2a4b00593ee5d02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I s= ubmitted this to the ADs. Comments?

In particular how to manage time. I am currently in the process = of making a series of 20 minute video presentations on the Mesh project and= component technologies. This should hopefully avoid the need to explain th= e technologies to a great extent in the room. It is a 24 hour flight after = all...

=3D=3D=3D=3D MATHM= ESH (proposal) =3D=3D=3D=3D

- Name: MatheMatical Mesh (MATHMESH)
= - Description:

To discuss scope of work to specify Mathemetical Mesh= technologies. The Mesh consists of a
user-centric PKI and a set of comp= onent technologies that are used to build it. The IETF
(and/or IRTF) mig= ht choose to form a Working Group to pursue some, all or none of these.
=
The component technologies of the Mesh include a naming mechanism (UDF)= , a cryptographic
syntax (DARE) and the use of 'metacryptography'= ; for threshold encryption and key provisioning.
Each of these component= technologies is closely related to prior IETF work with improved
imple= mentation and functionality.

UDF provides a generalization of OpenPG= P fingerprints using Base32 encoding (instead of hex),
modern digest alg= orithms (SHA2/3) and addressing semantic substitution attacks. The mechanis= m
is also extended to support symmetric keys, nonces, secret sharing and= embedding in URIs and
QR codes.

DARE provides an envelope format= that approximates to PKCS#7 in JSON. DARE envelopes
are designed to sta= ck in DARE Sequences which afford blockchain like incremental integrity
= assurance through use of a Merkle Tree and incremental encryption by means = of a salted
Key Derrivation Function.

Metacryptography is markete= cture for the use of the 'new' cryptography based on the new CFRG <= br>Elliptic Curves. Threshold encryption affords a novel approach to cloud = security by splitting
the private decryption key. This allows a cloud s= ervice to control the ability to decrypt without
having the ability to d= ecrypt. The key composition mechanism enables the novel approach to
key= provisioning employed in the Mesh.

The Mesh itself is a user centri= c PKI that applies the above technologies to make computers
easier to us= e by making them more secure. It also represents the use case that motivate= d
the development of the component technologies and is built on that fou= ndation. While the
IETF may choose to work on any or all of the componen= t technologies and not work on the Mesh
itself, the reverse is not pract= ical.


- Status: WG Forming
- Responsible AD: Benjamin Kaduk, = Roman Danyliw
- BoF proponents: Phillip Hallam-Baker <phill@hallambaker.com>
- BoF chairs: Ri= ch Salz
- Number of people expected to attend: 100
- Length of sessio= n (1, 1.5, 2, or 2.5 hours): 2.5 hours
- Conflicts to avoid (whole Areas= and/or WGs): WEBPACK, SECURITY

- Agenda
=C2=A0 =C2=A0- Items, dr= afts, speakers, timing
=C2=A0 =C2=A0- Or a URL
- Links to the mailing= list, draft charter if any, relevant Internet-Drafts, etc.
=C2=A0 =C2= =A0- Mailing List: https://www.ietf.org/mailman/listinfo/mathmesh
=C2=A0 =C2=A0- Dra= ft charter: TBS
=C2=A0 =C2=A0- Relevant drafts:
=C2=A0 =C2=A0 =C2=A0 = - Overview of the project
=C2=A0 =C2=A0- https://datatracker.ie= tf.org/doc/draft-hallambaker-mesh-architecture/
=C2=A0- Component = technologies
=C2=A0 =C2=A0- Fingerprint https://datatracker.ietf.org/doc= /draft-hallambaker-mesh-udf/
- PKCS#7/Blockchain https://datatracke= r.ietf.org/doc/draft-hallambaker-mesh-dare/
- Metacryptography https://datatracker.ietf.org/doc/draft-hallambaker-mesh-cryptography/ =C2=A0
=C2=A0- Mesh specific technology
=C2=A0 =C2=A0- Schema= https://datatracker.ietf.org/doc/draft-hallambaker-mesh-schema/
= - Protocol https://datatracker.ietf.org/doc/draft-hallambaker-mesh-proto= col/
=C2=A0- Additional
=C2=A0 =C2=A0- Security Consideration= s https://datatracker.ietf.org/doc/draft-hallambaker-mesh-security/<= br>=C2=A0 =C2=A0
--000000000000c2a4b00593ee5d02-- From nobody Mon Oct 14 12:02:22 2019 Return-Path: X-Original-To: mathmesh@ietf.org Delivered-To: mathmesh@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B1E12083E; Mon, 14 Oct 2019 12:02:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: mathmesh-chairs@ietf.org, avezza@amsl.com, mathmesh@ietf.org, kaduk@mit.edu X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157107974029.24792.12941413248642760829.idtracker@ietfa.amsl.com> Date: Mon, 14 Oct 2019 12:02:20 -0700 Archived-At: Subject: [Mathmesh] mathmesh - New Meeting Session Request for IETF 106 X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 19:02:21 -0000 A new meeting session request has just been submitted by Amy K. Vezza, on behalf of the mathmesh working group. --------------------------------------------------------- Working Group Name: MatheMatical Mesh Area Name: Security Area Session Requester: Amy Vezza Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: Technology Overlap: wpack saag People who must be present: Benjamin Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Oct 17 13:26:11 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1CF120974 for ; Thu, 17 Oct 2019 13:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.474 X-Spam-Level: X-Spam-Status: No, score=-1.474 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 qZzks2mKeatd for ; Thu, 17 Oct 2019 13:26:01 -0700 (PDT) Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com [209.85.210.43]) (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 D7346120241 for ; Thu, 17 Oct 2019 13:26:01 -0700 (PDT) Received: by mail-ot1-f43.google.com with SMTP id m19so3077752otp.1 for ; Thu, 17 Oct 2019 13:26:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=8XmKzD85WFTcSUV2tL4ZfTIL96A/9dczsTkvcrviQD4=; b=G1wpFlyIj9XvhI0GzKSPHDbn8IptKwosJdJOzgXMPPMbmtv0csDODtLlxsexgl1NQE d9bqRKvfJ8eTTAZCGXBv7WTB72Y0t/88O9w2Rrp+hCc+TN7wLFhcxESGq9iN6tukpSZ7 NT5fI+VZ7Sor0Yc6QfJBrHLwWWE6lJKdVnGMlyYiIdsNUCaj9Gn2Ad2v9+qsT7KSALCT elSCZK/eTtApKPBiqv7SjkOoAAxv6RBjEOXfMpHvpC9PQKtB4BmHJrHM7+DzUuElLHNn tzz971HvS+UGolEQGqei4zZOEiRmIGYZZuDYDaUPvOSm3e6o+vej2l/NUWwN3+emxV8d uSmw== X-Gm-Message-State: APjAAAVHtMNNnmzQJ/QnOEiraI4GqFqeGXINItaLVPWDef4V7UgC7ocP RHu5Xp6HTw2SJ7mY2fVkgBk4NXXDyNpiMwitKaILyByY X-Google-Smtp-Source: APXvYqxMbT89A9SgsY9TfdnuzqKx+gZXzO8e8fKuTmWrU3nYFmQJM0iE7H5hyDlKc0lXY/yelfwMH03lKqicosJbhqY= X-Received: by 2002:a9d:3a3:: with SMTP id f32mr4916153otf.231.1571343961172; Thu, 17 Oct 2019 13:26:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Thu, 17 Oct 2019 16:25:56 -0400 Message-ID: To: cfrg@irtf.org, mathmesh@ietf.org Content-Type: multipart/alternative; boundary="000000000000a031d305952106af" Archived-At: Subject: [Mathmesh] Query: Very best practice for RSA key generation X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 20:26:04 -0000 --000000000000a031d305952106af Content-Type: text/plain; charset="UTF-8" [CC'd to CFRG as this is a crypto question, MATHMESH as the target group, OpenPGP as a group that recently asked for the same capability. Also to the cryptography list for additional eyes. Looking to add this to the UDF draft tomorrow] A question has come up for generating key pairs from a specified random seed. I am just looking to add this to UDF and would like advice as to what the very best practices are for RSA keygen. The use case here is that the user wants to be able to be very very sure the key was correctly generated and that they can recover it. So lets say I want to configure OpenPGP with the same keypair on three different machines without the full Mesh PKI. The basic idea is that a user has a key which expressed in Base32 looks like this: ZAAA-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ The first three bytes are C8 Type code for key generation with 16 bit key type] 00,00 RSA 2048 bit key pair The remaining characters are to provide randomness for the key generation function. A minimum of 112 bits (work factor of RSA 2048) are required. So 112+24 = 136 bits To generate keys, HMAC-KDF is used p0 = KDF ("ZAAA-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ".FromBase32(), "P") q0 = KDF ("ZAAA-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ".FromBase32(), "Q") p = next_prime (p0) q = next_prime (q0) So that is the RSA part. I don't plan to do DH. For ECDH, I suggest the NIST and CFRG curves only. OK so some interesting variations. Lets say I don't trust the random number generator on any one machine. So lets use Shamir Secret sharing on three different machines for a 140 bit output: f(1) = SAYE-UHOY-TVZO-LPGT-ZAGE-7JUW-6MTJ-I f(2) = SAYX-4HWP-3753-L4P3-N4S6-C2G4-QVPA-A f(3) = SAZD-HQNJ-KSDK-HAY7-BIFO-34Y2-NH7O-C We can now combine the shares on the target machine to (re)generate the keypair. We can also give ourselves a couple of additional shares as well: f(4) = SAZW-WBTE-7MJ2-44B6-TC5X-KRKQ-UEEW-U f(5) = SA2C-H3IC-2ORN-NOK2-DM3X-OX37-FJ6W-Q --000000000000a031d305952106af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[CC= 'd to CFRG as this is a crypto question, MATHMESH as the target group, = OpenPGP as a group that recently asked for the same capability. Also to the= cryptography list for additional eyes. Looking to add this to the UDF draf= t tomorrow]

A question has come up for generating=C2=A0key pairs f= rom a specified random seed. I am just looking to add this to UDF and would= like advice as to what the very best practices are for RSA keygen.

The u= se case here is that the user wants to be able to be very very sure the key= was correctly generated and that they can recover it. So lets say I want t= o configure OpenPGP with the same keypair on three different=C2=A0machines = without the=C2=A0full Mesh PKI.=C2=A0
<= br>

The basic idea is that a user has a key which expressed in Base32 loo= ks like this:

ZAAA-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ

The first three by= tes are
C8=C2=A0 =C2=A0 =C2=A0Type code= for key generation with 16 bit key type]
00,00 RSA 2048 bit key pair

The remaining characters are to provide ra= ndomness for the key generation=C2=A0function. A minimum of 112 bits (work = factor of RSA 2048) are required. So 112+24 =3D 136 bits

To generate keys= , HMAC-KDF is used

p0 =3D KDF ("ZAAA-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ&q= uot;.FromBase32(), "P")=C2=A0=C2=A0
q0 =3D KDF ("ZAAA-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ".FromBase3= 2(), "Q")=C2=A0

p =3D next_prime (p0)
q =3D next_prime (q0)=C2=A0=C2=A0

So that is the RSA part.=

I don't plan to do DH. For ECDH, I suggest the NIST and CFRG curves = only.


OK so some interesting var= iations. Lets say I don't trust the random=C2=A0number generator on any= one machine. So lets use Shamir Secret sharing on three different machines= for a 140 bit output:

f(1) =3D SAYE-UHOY-TVZO-LPGT-ZAGE-7JUW-6MTJ-I
f= (2) =3D SAYX-4HWP-3753-L4P3-N4S6-C2G4-QVPA-A
f(3) =3D SAZD-HQNJ-KSDK-HAY= 7-BIFO-34Y2-NH7O-C

We can now combine the shares on the target machin= e to (re)generate the keypair. We can also give ourselves a couple of addit= ional shares as well:

f(4) =3D SAZW-WBTE-7MJ2-44B6-TC5X-KRKQ-UEEW-U
f(= 5) =3D SA2C-H3IC-2ORN-NOK2-DM3X-OX37-FJ6W-Q


--000000000000a031d305952106af-- From nobody Mon Oct 21 08:25:29 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3565112011A for ; Mon, 21 Oct 2019 08:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Lra4bClK; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=eF27Wesu 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 OijR2F3OPYxd for ; Mon, 21 Oct 2019 08:25:26 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFAAE1200EC for ; Mon, 21 Oct 2019 08:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15556; q=dns/txt; s=iport; t=1571671525; x=1572881125; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=/K20L2UvPwgX6gtTuS18e/1O3hzagvUjAeSpnA313ys=; b=Lra4bClKfp916kSF0oERzibtP5kbnhpPWHYbx/EGJ1DGrg7yKg0smebi fYQlsUL5AmeoqP25RLro+uE+CBYIwtdiEYcFozQ4K9jeMUFIZ7Y7lh4DZ /NKWMeN6XY3lg/P9b7en4j9RvlJv7xdkg+BhRopC1xOZfeXSU9Yr8hWJB g=; IronPort-PHdr: =?us-ascii?q?9a23=3A1cZl9hbR+sO34HP/QBuOnWf/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavxYSgnHN5PTndu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BGAAC3zK1d/5pdJa1lGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBZwYBAQELAYEbL1AFbFcgBAsqCoQcYoJlA4RYhX1Ngg9?= =?us-ascii?q?+kiOEYYEugSQDVAkBAQEMAQEtAgEBhEACF4MEJDQJDgIDCQEBBAEBAQIBBQR?= =?us-ascii?q?thQsGJgyFSwEBAQEDEhEKEwEBOA8CAQgRBAEBKwICAjAdCAIEARIIGoMBgXl?= =?us-ascii?q?NAy4BAqRTAoE4iGF1gTKCfgEBBYUKGIIXCYE2AYpLgUMYgUA/gRABRoFOSQc?= =?us-ascii?q?uPoRHJIJqMoIsj3aFOokyjnkKgiSVQZlMjjWZRgIEAgQFAg4BAQWBUjmBWHA?= =?us-ascii?q?VO4JsUBAUgRyBagkag1CKU3SBKY02AYEiAQE?= X-IronPort-AV: E=Sophos;i="5.67,324,1566864000"; d="scan'208,217";a="650586708" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Oct 2019 15:25:24 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x9LFPOqB031144 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Oct 2019 15:25:24 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 21 Oct 2019 10:25:23 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 21 Oct 2019 10:24:54 -0500 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 21 Oct 2019 10:24:54 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OlHOthVQ+Tl2quX9TV/utgPNx4twxM8coNrsgVS9rLbMvKlN4L8jktiKu/YSRUvpmKrbYHWt1BqkgZxaBiOK2ZwPx7mzYHJH74I6MfNTKw29hiCznI+SG2t09nvsZOfXk5YPVLw5s2/N6wkeRVBdoADEbMDLmAXAug5p40slUm/vV/feUE5pcRstDLO+Ra5u47XvmZO2uasjFSDGwTCOEfVwxrx71YnsEXYe5NaR9PurDaoMryfsCYITcV5eEkrYozfMKKnpKisJzMzDILGBZxzn3/z9B7NBoRhXyua4x4QseMCe2WZdaqoc3N5hsb4XeoGm54HzECFxDCMz4TyFkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/K20L2UvPwgX6gtTuS18e/1O3hzagvUjAeSpnA313ys=; b=X4cr47JplycnaWN1TwCm2qG6N+AFEa6Ag13JTHJhOEiB4p9pOsGUXMCq+GcDMSydM//bQxn6dHlgb4J7lyt4Y9XPqodSCucMi3j/LqOw3DKA/T4RANAEAqFiaF2NDMNltdPMo5wljK4uSClugTxnZ9xpXzAaOepNN+qgT/YYKz8/pL1Raeo3FWQ/E97847ABOxrD3V0Y8qN9NDvjI2cNnPNb9MGbPzZIzYRqwoGe2HSU/9YqO/xDyrJyZiLnG/JJ6uyXIN3lEKK2K/3mCQRdTe/qgb8CbUrOv8/KlvCnmZdDgiZC/skFj8n6ptLUVRA0QlCB39IhW+zp7gqxcAhSEg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/K20L2UvPwgX6gtTuS18e/1O3hzagvUjAeSpnA313ys=; b=eF27Wesu26awm7AgOg3yLM4V7Vei7QE27pYHVH5YKiLnH2dfIGVlhRm+fAKvUdlbffjuYEkewmGwj0h1Bfsrkyg09XH4NE0+tzlpqzoKsZB5uB0h2SjARucyE18iB9Pemu1nENpBb6NRZUkrNb686mugWnMdePjkgB6g3VGvE2k= Received: from BN8PR11MB3666.namprd11.prod.outlook.com (20.178.221.19) by BN8PR11MB3779.namprd11.prod.outlook.com (20.178.220.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Mon, 21 Oct 2019 15:24:54 +0000 Received: from BN8PR11MB3666.namprd11.prod.outlook.com ([fe80::38cc:fcf7:a049:1c5b]) by BN8PR11MB3666.namprd11.prod.outlook.com ([fe80::38cc:fcf7:a049:1c5b%7]) with mapi id 15.20.2347.029; Mon, 21 Oct 2019 15:24:54 +0000 From: "Scott Fluhrer (sfluhrer)" To: Phillip Hallam-Baker , "cfrg@irtf.org" , "mathmesh@ietf.org" Thread-Topic: [Cfrg] Query: Very best practice for RSA key generation Thread-Index: AQHVhSkxQ0fWjYGDU0efycYeaXyXKqdlPC1g Date: Mon, 21 Oct 2019 15:24:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sfluhrer@cisco.com; x-originating-ip: [173.38.117.90] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0efd05b2-6a13-48ad-42ba-08d7563ad2e3 x-ms-traffictypediagnostic: BN8PR11MB3779: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0197AFBD92 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(136003)(376002)(346002)(396003)(199004)(189003)(5660300002)(86362001)(7696005)(76176011)(6116002)(476003)(6436002)(53546011)(6506007)(26005)(99286004)(8936002)(110136005)(25786009)(229853002)(2501003)(33656002)(486006)(54896002)(9686003)(6306002)(2906002)(2201001)(102836004)(55016002)(3846002)(790700001)(66946007)(76116006)(64756008)(71190400001)(66556008)(66476007)(66066001)(66446008)(74316002)(8676002)(71200400001)(14454004)(7736002)(256004)(316002)(11346002)(6246003)(446003)(186003)(52536014)(478600001)(81156014)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3779; H:BN8PR11MB3666.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tcFAR2RW6uI7FebocFldRzP/AWqx6126bVRtn81GbQntVckDB5+aGgg+nMrM7wzG7JrQq7w836fRQV3oJ5+MSD6sjmijh6NoAkiZcCUKEsS7JIKKj0K6k6WMmfVLEleOpSE5H7sF/mQ2yGDEcY7TLsI4b20i1mAKjUaL/pd9OeY4vDLPSgqQDYbs14sRMayc/JwfQHY9Cp25dCClOfnywAXNzmu8hTuNbifXp67eySLQGyCXBm8r2ecgP3fOzgbc78tkRcOYUHjuE9YBVn8RhjA9dTTO002Uu11keVr3T7IvJt9Zax5+1YWFoQq5ptnWWlWXcDkc6O++BnV0u8ujnU6THK8YzBIrDPOqIKggTy0QYQquKqkfUMgoP1PMjpkDNBJduRTsTUWDOIGeXUl5jggXUPgNpxSfVXwN5BZhAYU= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN8PR11MB3666C8581C62EECE4F8A6E91C1690BN8PR11MB3666namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0efd05b2-6a13-48ad-42ba-08d7563ad2e3 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2019 15:24:54.2005 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GI5ZzSVV8pfpW5QfkBMwvgAOd/7kThGHRRD6PrpZQIRq0mXPfiPpTgaX+zq7wK9abdhU7YlqrCL3ehaSTq7PyA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3779 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [Mathmesh] [Cfrg] Query: Very best practice for RSA key generation X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 15:25:28 -0000 --_000_BN8PR11MB3666C8581C62EECE4F8A6E91C1690BN8PR11MB3666namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWN0dWFsbHksIE5JU1QgU1AgODAwLTU2QiBhbHJlYWR5IGRlZmluZXMgYSBudW1iZXIgb2Ygd2F5 cyB0byBtYXAgYSBzZWVkIGludG8gYW4gUlNBIGtleS4gIFdoaWxlIHRoZXnigJlyZSBub3QgcGVy ZmVjdCAodGhleSBhcmUgb3Zlcmx5IGNvbXBsZXgsIGFuZCBvZiBjb3Vyc2UsIHRoZXJlIGFyZSBh IG51bWJlciBvZiBtZXRob2RzIGFuZCBwYXJhbWV0ZXJzIGluIHRob3NlIG1ldGhvZHMgdGhhdCB3 ZeKAmWQgbmVlZCB0byBhZ3JlZSB1cG9uKSwgaG93ZXZlciAoSU1ITykgaXTigJlkIG1ha2UgbW9y ZSBzZW5zZSB0byBzdGFydCBmcm9tIHRoZXJlIHJhdGhlciB0aGFuIGludmVudGluZyBhIG5ldyBt ZXRob2TigKYNCg0KRnJvbTogQ2ZyZyA8Y2ZyZy1ib3VuY2VzQGlydGYub3JnPiBPbiBCZWhhbGYg T2YgUGhpbGxpcCBIYWxsYW0tQmFrZXINClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE3LCAyMDE5 IDQ6MjYgUE0NClRvOiBjZnJnQGlydGYub3JnOyBtYXRobWVzaEBpZXRmLm9yZw0KU3ViamVjdDog W0NmcmddIFF1ZXJ5OiBWZXJ5IGJlc3QgcHJhY3RpY2UgZm9yIFJTQSBrZXkgZ2VuZXJhdGlvbg0K DQpbQ0MnZCB0byBDRlJHIGFzIHRoaXMgaXMgYSBjcnlwdG8gcXVlc3Rpb24sIE1BVEhNRVNIIGFz IHRoZSB0YXJnZXQgZ3JvdXAsIE9wZW5QR1AgYXMgYSBncm91cCB0aGF0IHJlY2VudGx5IGFza2Vk IGZvciB0aGUgc2FtZSBjYXBhYmlsaXR5LiBBbHNvIHRvIHRoZSBjcnlwdG9ncmFwaHkgbGlzdCBm b3IgYWRkaXRpb25hbCBleWVzLiBMb29raW5nIHRvIGFkZCB0aGlzIHRvIHRoZSBVREYgZHJhZnQg dG9tb3Jyb3ddDQoNCkEgcXVlc3Rpb24gaGFzIGNvbWUgdXAgZm9yIGdlbmVyYXRpbmcga2V5IHBh aXJzIGZyb20gYSBzcGVjaWZpZWQgcmFuZG9tIHNlZWQuIEkgYW0ganVzdCBsb29raW5nIHRvIGFk ZCB0aGlzIHRvIFVERiBhbmQgd291bGQgbGlrZSBhZHZpY2UgYXMgdG8gd2hhdCB0aGUgdmVyeSBi ZXN0IHByYWN0aWNlcyBhcmUgZm9yIFJTQSBrZXlnZW4uDQoNClRoZSB1c2UgY2FzZSBoZXJlIGlz IHRoYXQgdGhlIHVzZXIgd2FudHMgdG8gYmUgYWJsZSB0byBiZSB2ZXJ5IHZlcnkgc3VyZSB0aGUg a2V5IHdhcyBjb3JyZWN0bHkgZ2VuZXJhdGVkIGFuZCB0aGF0IHRoZXkgY2FuIHJlY292ZXIgaXQu IFNvIGxldHMgc2F5IEkgd2FudCB0byBjb25maWd1cmUgT3BlblBHUCB3aXRoIHRoZSBzYW1lIGtl eXBhaXIgb24gdGhyZWUgZGlmZmVyZW50IG1hY2hpbmVzIHdpdGhvdXQgdGhlIGZ1bGwgTWVzaCBQ S0kuDQoNCg0KVGhlIGJhc2ljIGlkZWEgaXMgdGhhdCBhIHVzZXIgaGFzIGEga2V5IHdoaWNoIGV4 cHJlc3NlZCBpbiBCYXNlMzIgbG9va3MgbGlrZSB0aGlzOg0KDQpaQUFBLVVKVVktSDdURi1TRkxL LUNXQVctVEtDNC1PNUhRDQoNClRoZSBmaXJzdCB0aHJlZSBieXRlcyBhcmUNCkM4ICAgICBUeXBl IGNvZGUgZm9yIGtleSBnZW5lcmF0aW9uIHdpdGggMTYgYml0IGtleSB0eXBlXQ0KMDAsMDAgUlNB IDIwNDggYml0IGtleSBwYWlyDQoNClRoZSByZW1haW5pbmcgY2hhcmFjdGVycyBhcmUgdG8gcHJv dmlkZSByYW5kb21uZXNzIGZvciB0aGUga2V5IGdlbmVyYXRpb24gZnVuY3Rpb24uIEEgbWluaW11 bSBvZiAxMTIgYml0cyAod29yayBmYWN0b3Igb2YgUlNBIDIwNDgpIGFyZSByZXF1aXJlZC4gU28g MTEyKzI0ID0gMTM2IGJpdHMNCg0KVG8gZ2VuZXJhdGUga2V5cywgSE1BQy1LREYgaXMgdXNlZA0K DQpwMCA9IEtERiAoIlpBQUEtVUpVWS1IN1RGLVNGTEstQ1dBVy1US0M0LU81SFEiLkZyb21CYXNl MzIoKSwgIlAiKQ0KcTAgPSBLREYgKCJaQUFBLVVKVVktSDdURi1TRkxLLUNXQVctVEtDNC1PNUhR Ii5Gcm9tQmFzZTMyKCksICJRIikNCg0KcCA9IG5leHRfcHJpbWUgKHAwKQ0KcSA9IG5leHRfcHJp bWUgKHEwKQ0KDQpTbyB0aGF0IGlzIHRoZSBSU0EgcGFydC4NCg0KSSBkb24ndCBwbGFuIHRvIGRv IERILiBGb3IgRUNESCwgSSBzdWdnZXN0IHRoZSBOSVNUIGFuZCBDRlJHIGN1cnZlcyBvbmx5Lg0K DQoNCk9LIHNvIHNvbWUgaW50ZXJlc3RpbmcgdmFyaWF0aW9ucy4gTGV0cyBzYXkgSSBkb24ndCB0 cnVzdCB0aGUgcmFuZG9tIG51bWJlciBnZW5lcmF0b3Igb24gYW55IG9uZSBtYWNoaW5lLiBTbyBs ZXRzIHVzZSBTaGFtaXIgU2VjcmV0IHNoYXJpbmcgb24gdGhyZWUgZGlmZmVyZW50IG1hY2hpbmVz IGZvciBhIDE0MCBiaXQgb3V0cHV0Og0KDQpmKDEpID0gU0FZRS1VSE9ZLVRWWk8tTFBHVC1aQUdF LTdKVVctNk1USi1JDQpmKDIpID0gU0FZWC00SFdQLTM3NTMtTDRQMy1ONFM2LUMyRzQtUVZQQS1B DQpmKDMpID0gU0FaRC1IUU5KLUtTREstSEFZNy1CSUZPLTM0WTItTkg3Ty1DDQoNCldlIGNhbiBu b3cgY29tYmluZSB0aGUgc2hhcmVzIG9uIHRoZSB0YXJnZXQgbWFjaGluZSB0byAocmUpZ2VuZXJh dGUgdGhlIGtleXBhaXIuIFdlIGNhbiBhbHNvIGdpdmUgb3Vyc2VsdmVzIGEgY291cGxlIG9mIGFk ZGl0aW9uYWwgc2hhcmVzIGFzIHdlbGw6DQoNCmYoNCkgPSBTQVpXLVdCVEUtN01KMi00NEI2LVRD NVgtS1JLUS1VRUVXLVUNCmYoNSkgPSBTQTJDLUgzSUMtMk9STi1OT0syLURNM1gtT1gzNy1GSjZX LVENCg0KDQo= --_000_BN8PR11MB3666C8581C62EECE4F8A6E91C1690BN8PR11MB3666namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B Y3R1YWxseSwgTklTVCBTUCA4MDAtNTZCIGFscmVhZHkgZGVmaW5lcyBhIG51bWJlciBvZiB3YXlz IHRvIG1hcCBhIHNlZWQgaW50byBhbiBSU0Ega2V5LiZuYnNwOyBXaGlsZSB0aGV54oCZcmUgbm90 IHBlcmZlY3QgKHRoZXkgYXJlIG92ZXJseSBjb21wbGV4LCBhbmQgb2YgY291cnNlLCB0aGVyZSBh cmUgYSBudW1iZXIgb2YgbWV0aG9kcyBhbmQgcGFyYW1ldGVycyBpbiB0aG9zZSBtZXRob2RzIHRo YXQgd2XigJlkIG5lZWQgdG8NCiBhZ3JlZSB1cG9uKSwgaG93ZXZlciAoSU1ITykgaXTigJlkIG1h a2UgbW9yZSBzZW5zZSB0byBzdGFydCBmcm9tIHRoZXJlIHJhdGhlciB0aGFuIGludmVudGluZyBh IG5ldyBtZXRob2TigKY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gQ2Zy ZyAmbHQ7Y2ZyZy1ib3VuY2VzQGlydGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KUGhp bGxpcCBIYWxsYW0tQmFrZXI8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE9jdG9iZXIgMTcs IDIwMTkgNDoyNiBQTTxicj4NCjxiPlRvOjwvYj4gY2ZyZ0BpcnRmLm9yZzsgbWF0aG1lc2hAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0NmcmddIFF1ZXJ5OiBWZXJ5IGJlc3QgcHJhY3Rp Y2UgZm9yIFJTQSBrZXkgZ2VuZXJhdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+W0ND J2QgdG8gQ0ZSRyBhcyB0aGlzIGlzIGEgY3J5cHRvIHF1ZXN0aW9uLCBNQVRITUVTSCBhcyB0aGUg dGFyZ2V0IGdyb3VwLCBPcGVuUEdQIGFzIGEgZ3JvdXAgdGhhdCByZWNlbnRseSBhc2tlZCBmb3Ig dGhlIHNhbWUgY2FwYWJpbGl0eS4gQWxzbyB0byB0aGUgY3J5cHRvZ3JhcGh5IGxpc3QgZm9yIGFk ZGl0aW9uYWwgZXllcy4gTG9va2luZyB0byBhZGQgdGhpcw0KIHRvIHRoZSBVREYgZHJhZnQgdG9t b3Jyb3ddPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BIHF1ZXN0aW9uIGhhcyBj b21lIHVwIGZvciBnZW5lcmF0aW5nJm5ic3A7a2V5IHBhaXJzIGZyb20gYSBzcGVjaWZpZWQgcmFu ZG9tIHNlZWQuIEkgYW0ganVzdCBsb29raW5nIHRvIGFkZCB0aGlzIHRvIFVERiBhbmQgd291bGQg bGlrZSBhZHZpY2UgYXMgdG8gd2hhdCB0aGUgdmVyeSBiZXN0IHByYWN0aWNlcyBhcmUgZm9yIFJT QSBrZXlnZW4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5UaGUgdXNlIGNhc2UgaGVyZSBpcyB0aGF0IHRoZSB1 c2VyIHdhbnRzIHRvIGJlIGFibGUgdG8gYmUgdmVyeSB2ZXJ5IHN1cmUgdGhlIGtleSB3YXMgY29y cmVjdGx5IGdlbmVyYXRlZCBhbmQgdGhhdCB0aGV5IGNhbiByZWNvdmVyIGl0LiBTbyBsZXRzIHNh eSBJIHdhbnQgdG8gY29uZmlndXJlIE9wZW5QR1Agd2l0aCB0aGUgc2FtZSBrZXlwYWlyIG9uIHRo cmVlDQogZGlmZmVyZW50Jm5ic3A7bWFjaGluZXMgd2l0aG91dCB0aGUmbmJzcDtmdWxsIE1lc2gg UEtJLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPlRoZSBiYXNpYyBpZGVhIGlzIHRoYXQgYSB1c2VyIGhhcyBhIGtleSB3aGljaCBl eHByZXNzZWQgaW4gQmFzZTMyIGxvb2tzIGxpa2UgdGhpczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlpBQUEt VUpVWS1IN1RGLVNGTEstQ1dBVy1US0M0LU81SFE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlRoZSBmaXJzdCB0 aHJlZSBieXRlcyBhcmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QzgmbmJzcDsg Jm5ic3A7ICZuYnNwO1R5cGUgY29kZSBmb3Iga2V5IGdlbmVyYXRpb24gd2l0aCAxNiBiaXQga2V5 IHR5cGVdPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjAwLDAwIFJTQSAyMDQ4IGJp dCBrZXkgcGFpcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+VGhlIHJlbWFpbmluZyBjaGFyYWN0ZXJzIGFyZSB0 byBwcm92aWRlIHJhbmRvbW5lc3MgZm9yIHRoZSBrZXkgZ2VuZXJhdGlvbiZuYnNwO2Z1bmN0aW9u LiBBIG1pbmltdW0gb2YgMTEyIGJpdHMgKHdvcmsgZmFjdG9yIG9mIFJTQSAyMDQ4KSBhcmUgcmVx dWlyZWQuIFNvIDExMiYjNDM7MjQgPSAxMzYgYml0czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+VG8gZ2VuZXJh dGUga2V5cywgSE1BQy1LREYgaXMgdXNlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+cDAgPSBLREYgKCZxdW90 O1pBQUEtVUpVWS1IN1RGLVNGTEstQ1dBVy1US0M0LU81SFEmcXVvdDsuRnJvbUJhc2UzMigpLCAm cXVvdDtQJnF1b3Q7KSZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij5xMCA9IEtERiAoJnF1b3Q7WkFBQS1VSlVZLUg3VEYtU0ZMSy1DV0FXLVRLQzQtTzVIUSZxdW90 Oy5Gcm9tQmFzZTMyKCksICZxdW90O1EmcXVvdDspJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5wID0g bmV4dF9wcmltZSAocDApPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPnEgPSBuZXh0 X3ByaW1lIChxMCkmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlNvIHRoYXQgaXMgdGhlIFJT QSBwYXJ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SSBkb24ndCBwbGFuIHRvIGRvIERILiBGb3IgRUNESCwg SSBzdWdnZXN0IHRoZSBOSVNUIGFuZCBDRlJHIGN1cnZlcyBvbmx5LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPk9LIHNvIHNvbWUgaW50ZXJl c3RpbmcgdmFyaWF0aW9ucy4gTGV0cyBzYXkgSSBkb24ndCB0cnVzdCB0aGUgcmFuZG9tJm5ic3A7 bnVtYmVyIGdlbmVyYXRvciBvbiBhbnkgb25lIG1hY2hpbmUuIFNvIGxldHMgdXNlIFNoYW1pciBT ZWNyZXQgc2hhcmluZyBvbiB0aHJlZSBkaWZmZXJlbnQgbWFjaGluZXMgZm9yIGEgMTQwIGJpdCBv dXRwdXQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij5mKDEpID0gU0FZRS1VSE9ZLVRWWk8tTFBHVC1aQUdFLTdK VVctNk1USi1JPGJyPg0KZigyKSA9IFNBWVgtNEhXUC0zNzUzLUw0UDMtTjRTNi1DMkc0LVFWUEEt QTxicj4NCmYoMykgPSBTQVpELUhRTkotS1NESy1IQVk3LUJJRk8tMzRZMi1OSDdPLUM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPldlIGNhbiBub3cgY29tYmluZSB0aGUgc2hhcmVzIG9uIHRoZSB0YXJnZXQgbWFj aGluZSB0byAocmUpZ2VuZXJhdGUgdGhlIGtleXBhaXIuIFdlIGNhbiBhbHNvIGdpdmUgb3Vyc2Vs dmVzIGEgY291cGxlIG9mIGFkZGl0aW9uYWwgc2hhcmVzIGFzIHdlbGw6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij5mKDQpID0gU0FaVy1XQlRFLTdNSjItNDRCNi1UQzVYLUtSS1EtVUVFVy1VPGJyPg0KZig1KSA9 IFNBMkMtSDNJQy0yT1JOLU5PSzItRE0zWC1PWDM3LUZKNlctUTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN8PR11MB3666C8581C62EECE4F8A6E91C1690BN8PR11MB3666namp_-- From nobody Mon Oct 21 11:32:41 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 224081201E4 for ; Mon, 21 Oct 2019 11:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 ujSLvFbOvZY9 for ; Mon, 21 Oct 2019 11:32:31 -0700 (PDT) Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com [209.85.210.54]) (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 DCE95120025 for ; Mon, 21 Oct 2019 11:32:27 -0700 (PDT) Received: by mail-ot1-f54.google.com with SMTP id d8so688099otc.7 for ; Mon, 21 Oct 2019 11:32:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=az4TZSZ+Oo+QUpBoJVGfEIOd+4hVjG9FCxRzs033WO4=; b=ge5AF+8T3iGz+dlzazH79wKOUqJqCz1OKAQwNnAbsrN6G5CmFABPhd4RNpzXLZV9iY nYDFZLrHm7b6aAlTFoRCBDg4EYYxCm980ca5hpqecsGgvXEJ+rNwKo+Vxlbj4/NxNK3Z VMMco5dkq67kn0d11MrJjEMQ+NnMx36ttgO2p123qY1prNT5psyWP8uTEMPQJ6ZesI53 H8qqAUysPp1Hw/2zsTe8EOtrz//97jdfVemW7OfQ9Oaj97ZAS0yaBV5Mcd7NxthP4C/L ndyVgIl/XF4N+un/4VhsJHl4HlXcM2NGPBsXPtXWZJ9XS94RG+YyVisLo5pJkUN/R4dZ 9YDQ== X-Gm-Message-State: APjAAAWlXiSPMOWvGO5azU117wvIRpD4rIml8F8HqcFsWUvLAwt90wmX Qpr+0uGHD92vwRuZsyKRS2rTkKHGw1DvLPLdJvU= X-Google-Smtp-Source: APXvYqw5xR2ITTIEj+4VNFswhWN0K1Z+5Bg2jOnF6Jo7vfboj5ivnVh9agGTVw4tY3vyUUqktcYKWdWa/MPNRbYisnU= X-Received: by 2002:a05:6830:1d8a:: with SMTP id y10mr1631669oti.48.1571682747016; Mon, 21 Oct 2019 11:32:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Mon, 21 Oct 2019 14:32:25 -0400 Message-ID: To: "Scott Fluhrer (sfluhrer)" Cc: "cfrg@irtf.org" , "mathmesh@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d5e9db05956fe733" Archived-At: Subject: Re: [Mathmesh] [Cfrg] Query: Very best practice for RSA key generation X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 18:32:33 -0000 --000000000000d5e9db05956fe733 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the info. I will take a look on the next iteration. This is what I sent out on Friday: http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html One comment on this approach is that rather than using the traditional nextprime(x) function, it would be more satisfactory to take the next output from the KDF. This is easy to do: try KDF (PRK, "p0", l) try KDF (PRK, "p1", l) try KDF (PRK, "p2", l) etc. Where try is a function that extracts the necessary number of bits, sets the first and last to 1 and tests for primality. This ensures that there is an exactly equal probability of choosing every prime in the space rather than a bias towards primes that are preceded by an empty gap of non primes. Not that we know of a reason such a gap might be an issue, but it seems proper to avoid it since we can. I also plan to add DSA to the draft since it has been requested. The mechanism for generating the first prime will be the same. The mechanism for the second prime will be as constrained by the specification. On Mon, Oct 21, 2019 at 11:25 AM Scott Fluhrer (sfluhrer) < sfluhrer@cisco.com> wrote: > Actually, NIST SP 800-56B already defines a number of ways to map a seed > into an RSA key. While they=E2=80=99re not perfect (they are overly comp= lex, and > of course, there are a number of methods and parameters in those methods > that we=E2=80=99d need to agree upon), however (IMHO) it=E2=80=99d make m= ore sense to start > from there rather than inventing a new method=E2=80=A6 > > > > *From:* Cfrg *On Behalf Of * Phillip Hallam-Baker > *Sent:* Thursday, October 17, 2019 4:26 PM > *To:* cfrg@irtf.org; mathmesh@ietf.org > *Subject:* [Cfrg] Query: Very best practice for RSA key generation > > > > [CC'd to CFRG as this is a crypto question, MATHMESH as the target group, > OpenPGP as a group that recently asked for the same capability. Also to t= he > cryptography list for additional eyes. Looking to add this to the UDF dra= ft > tomorrow] > > > > A question has come up for generating key pairs from a specified random > seed. I am just looking to add this to UDF and would like advice as to wh= at > the very best practices are for RSA keygen. > > > > The use case here is that the user wants to be able to be very very sure > the key was correctly generated and that they can recover it. So lets say= I > want to configure OpenPGP with the same keypair on three different machin= es > without the full Mesh PKI. > > > > > > The basic idea is that a user has a key which expressed in Base32 looks > like this: > > > > ZAAA-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ > > > > The first three bytes are > > C8 Type code for key generation with 16 bit key type] > > 00,00 RSA 2048 bit key pair > > > > The remaining characters are to provide randomness for the key > generation function. A minimum of 112 bits (work factor of RSA 2048) are > required. So 112+24 =3D 136 bits > > > > To generate keys, HMAC-KDF is used > > > > p0 =3D KDF ("ZAAA-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ".FromBase32(), "P") > > q0 =3D KDF ("ZAAA-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ".FromBase32(), "Q") > > > > p =3D next_prime (p0) > > q =3D next_prime (q0) > > > > So that is the RSA part. > > > > I don't plan to do DH. For ECDH, I suggest the NIST and CFRG curves only. > > > > > > OK so some interesting variations. Lets say I don't trust the > random number generator on any one machine. So lets use Shamir Secret > sharing on three different machines for a 140 bit output: > > > > f(1) =3D SAYE-UHOY-TVZO-LPGT-ZAGE-7JUW-6MTJ-I > f(2) =3D SAYX-4HWP-3753-L4P3-N4S6-C2G4-QVPA-A > f(3) =3D SAZD-HQNJ-KSDK-HAY7-BIFO-34Y2-NH7O-C > > > > We can now combine the shares on the target machine to (re)generate the > keypair. We can also give ourselves a couple of additional shares as well= : > > > > f(4) =3D SAZW-WBTE-7MJ2-44B6-TC5X-KRKQ-UEEW-U > f(5) =3D SA2C-H3IC-2ORN-NOK2-DM3X-OX37-FJ6W-Q > > > > > --000000000000d5e9db05956fe733 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tha= nks for the info. I will take a look on the next iteration. This is what I = sent out on Friday:

http:/= /mathmesh.com/Documents/draft-hallambaker-mesh-udf.html=C2=A0

One comment on this approach is th= at rather than using the traditional nextprime(x) function, it would be mor= e satisfactory to take the next output from the KDF. This is easy to do:

try KDF (PRK, "p0"= ;, l)
try KDF (= PRK, "p1", l)=C2=A0=C2=A0
try KDF (PRK, "p2", l)=C2=A0=C2=A0
etc.

Where try is a function that extract= s the necessary number of bits, sets the first and last to 1 and tests for = primality. This ensures that there is an exactly equal probability of choos= ing every prime in the space rather than a bias towards primes that are pre= ceded by an empty gap of non primes.

Not that we know of a reason such a gap might be an issue, but = it seems proper to avoid it since we can.

I also plan to add DSA to the draft since it has been requ= ested. The mechanism for generating the first prime will be the same. The m= echanism for the second prime will be as constrained by the specification.<= /div>


On Mo= n, Oct 21, 2019 at 11:25 AM Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com> wrote:

Actually, NIST SP 800-56B already defines a number o= f ways to map a seed into an RSA key.=C2=A0 While they=E2=80=99re not perfe= ct (they are overly complex, and of course, there are a number of methods a= nd parameters in those methods that we=E2=80=99d need to agree upon), however (IMHO) it=E2=80=99d make more sense to start from the= re rather than inventing a new method=E2=80=A6

=C2=A0

From: Cfrg <cfrg-bounces@irtf.org> On Behalf Of = Phillip Hallam-Baker
Sent: Thursday, October 17, 2019 4:26 PM
To: cfrg@irtf.org= ; mathmesh@ietf.= org
Subject: [Cfrg] Query: Very best practice for RSA key generation<= /u>

=C2=A0

[CC'd to CFRG as = this is a crypto question, MATHMESH as the target group, OpenPGP as a group= that recently asked for the same capability. Also to the cryptography list= for additional eyes. Looking to add this to the UDF draft tomorrow]

=C2=A0

A question has come u= p for generating=C2=A0key pairs from a specified random seed. I am just loo= king to add this to UDF and would like advice as to what the very best prac= tices are for RSA keygen.

=C2=A0<= /span>

The use case here is = that the user wants to be able to be very very sure the key was correctly g= enerated and that they can recover it. So lets say I want to configure Open= PGP with the same keypair on three different=C2=A0machines without the=C2=A0full Mesh PKI.=C2=A0

=C2=A0<= /span>

=C2=A0<= /span>

The basic idea is tha= t a user has a key which expressed in Base32 looks like this:=

=C2=A0<= /span>

ZAAA-UJUY-H7TF-SFLK-C= WAW-TKC4-O5HQ

=C2=A0<= /span>

The first three bytes= are

C8=C2=A0 =C2=A0 =C2= =A0Type code for key generation with 16 bit key type]<= /p>

00,00 RSA 2048 bit ke= y pair

=C2=A0<= /span>

The remaining charact= ers are to provide randomness for the key generation=C2=A0function. A minim= um of 112 bits (work factor of RSA 2048) are required. So 112+24 =3D 136 bi= ts

=C2=A0<= /span>

To generate keys, HMA= C-KDF is used

=C2=A0<= /span>

p0 =3D KDF ("ZAA= A-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ".FromBase32(), "P")=C2=A0=C2= =A0

q0 =3D KDF ("ZAA= A-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ".FromBase32(), "Q")=C2=A0=

=C2=A0<= /span>

p =3D next_prime (p0)=

q =3D next_prime (q0)= =C2=A0=C2=A0

=C2=A0<= /span>

So that is the RSA pa= rt.

=C2=A0<= /span>

I don't plan to d= o DH. For ECDH, I suggest the NIST and CFRG curves only.

=C2=A0<= /span>

=C2=A0<= /span>

OK so some interestin= g variations. Lets say I don't trust the random=C2=A0number generator o= n any one machine. So lets use Shamir Secret sharing on three different mac= hines for a 140 bit output:

=C2=A0<= /span>

f(1) =3D SAYE-UHOY-TV= ZO-LPGT-ZAGE-7JUW-6MTJ-I
f(2) =3D SAYX-4HWP-3753-L4P3-N4S6-C2G4-QVPA-A
f(3) =3D SAZD-HQNJ-KSDK-HAY7-BIFO-34Y2-NH7O-C

=C2=A0<= /span>

We can now combine th= e shares on the target machine to (re)generate the keypair. We can also giv= e ourselves a couple of additional shares as well:

=C2=A0<= /span>

f(4) =3D SAZW-WBTE-7M= J2-44B6-TC5X-KRKQ-UEEW-U
f(5) =3D SA2C-H3IC-2ORN-NOK2-DM3X-OX37-FJ6W-Q

=C2=A0<= /span>

=C2=A0<= /span>

--000000000000d5e9db05956fe733-- From nobody Fri Oct 25 14:17:03 2019 Return-Path: X-Original-To: mathmesh@ietf.org Delivered-To: mathmesh@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80882120A4A; Fri, 25 Oct 2019 14:12:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: mathmesh@ietf.org, kaduk@mit.edu X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157203793151.2724.12656238117771547262.idtracker@ietfa.amsl.com> Date: Fri, 25 Oct 2019 14:12:11 -0700 Archived-At: Subject: [Mathmesh] mathmesh - Requested session has been scheduled for IETF 106 X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 21:12:23 -0000 Dear Amy Vezza, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. mathmesh Session 1 (2:00 requested) Monday, 18 November 2019, Morning Session I 1000-1200 Room Name: Collyer size: 250 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/106/sessions/mathmesh.ics Request Information: --------------------------------------------------------- Working Group Name: MatheMatical Mesh Area Name: Security Area Session Requester: Amy Vezza Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: Technology Overlap: wpack saag People who must be present: Benjamin Kaduk Resources Requested: Special Requests: ---------------------------------------------------------