├── revision.tex ├── umbral-doc.pdf ├── figures ├── pre.pdf └── umbral-kem-flow.pdf ├── Makefile ├── .gitignore ├── umbral-doc.bib ├── Makefile.include └── umbral-doc.tex /revision.tex: -------------------------------------------------------------------------------- 1 | \newcommand{\Revision}{b7eecbb} 2 | -------------------------------------------------------------------------------- /umbral-doc.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/umbral-doc/HEAD/umbral-doc.pdf -------------------------------------------------------------------------------- /figures/pre.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/umbral-doc/HEAD/figures/pre.pdf -------------------------------------------------------------------------------- /figures/umbral-kem-flow.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/umbral-doc/HEAD/figures/umbral-kem-flow.pdf -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | TARGET=umbral-doc 2 | PDFVIEWER=open 3 | ### AFTERALL=mypostprocessingstep 4 | include Makefile.include 5 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | *.aux 2 | *.glo 3 | *.idx 4 | *.log 5 | *.toc 6 | *.ist 7 | *.acn 8 | *.acr 9 | *.alg 10 | *.bbl 11 | *.blg 12 | *.dvi 13 | *.glg 14 | *.gls 15 | *.ilg 16 | *.ind 17 | *.lof 18 | *.lot 19 | *.maf 20 | *.mtc 21 | *.mtc1 22 | *.out 23 | *.synctex.gz 24 | 25 | -------------------------------------------------------------------------------- /umbral-doc.bib: -------------------------------------------------------------------------------- 1 | %% This BibTeX bibliography file was created using BibDesk. 2 | %% http://bibdesk.sourceforge.net/ 3 | 4 | %% Created for david at 2018-03-21 16:42:12 +0100 5 | 6 | 7 | %% Saved with string encoding Unicode (UTF-8) 8 | 9 | 10 | 11 | @misc{pyumbral, 12 | Author = {NuCypher}, 13 | Date-Added = {2018-03-21 15:41:22 +0000}, 14 | Date-Modified = {2018-03-21 15:42:11 +0000}, 15 | Howpublished = {\url{https://github.com/nucypher/pyumbral}}, 16 | Publisher = {GitHub}, 17 | Title = {pyUmbral}, 18 | Year = {2018}} 19 | 20 | @article{nunez2017proxy, 21 | Abstract = {This paper analyzes the secure access delegation problem, which occurs naturally in the cloud, and postulate that Proxy Re-Encryption is a feasible cryptographic solution, both from the functional and efficiency perspectives. Proxy re-encryption is a special type of public-key encryption that permits a proxy to transform ciphertexts from one public key to another, without the proxy being able to learn any information about the original message. Thus, it serves as a means for delegating decryption rights, opening up many possible applications that require of delegated access to encrypted data. In particular, sharing information in the cloud is a prime example. In this paper, we review the main proxy re-encryption schemes so far, and provide a detailed analysis of their characteristics. Additionally, we also study the efficiency of selected schemes, both theoretically and empirically, based on our own implementation. Finally, we discuss some applications of proxy re-encryption, with a focus on secure access delegation in the cloud.}, 22 | Author = {David Nu{\~n}ez and Isaac Agudo and Javier Lopez}, 23 | Date-Added = {2017-11-16 16:21:43 +0000}, 24 | Date-Modified = {2017-11-16 16:21:43 +0000}, 25 | Doi = {10.1016/j.jnca.2017.03.005}, 26 | Issn = {1084-8045}, 27 | Journal = {Journal of Network and Computer Applications}, 28 | Pages = {193-209}, 29 | Publisher = {Elsevier}, 30 | Title = {Proxy Re-Encryption: Analysis of Constructions and its Application to Secure Access Delegation}, 31 | Volume = {87}, 32 | Year = {2017}, 33 | Bdsk-Url-1 = {http://dx.doi.org/10.1016/j.jnca.2017.03.005}} 34 | 35 | @inproceedings{canetti2007chosen, 36 | Author = {Canetti, R. and Hohenberger, S.}, 37 | Booktitle = {Proceedings of the 14th ACM conference on Computer and communications security}, 38 | Date-Added = {2017-11-16 11:03:46 +0000}, 39 | Date-Modified = {2017-11-16 11:03:46 +0000}, 40 | Organization = {ACM}, 41 | Pages = {185--194}, 42 | Title = {Chosen-ciphertext secure proxy re-encryption}, 43 | Year = {2007}} 44 | 45 | @misc{tink, 46 | Date-Added = {2017-11-16 11:02:54 +0000}, 47 | Date-Modified = {2017-11-16 11:03:33 +0000}, 48 | Howpublished = {\url{https://github.com/google/tink}}, 49 | Journal = {GitHub repository}, 50 | Publisher = {GitHub}, 51 | Title = {Tink}, 52 | Year = {2017}} 53 | 54 | @article{egorov2017nucypherkms, 55 | Archiveprefix = {arXiv}, 56 | Author = {Michael Egorov and MacLane Wilkison and David Nu{\~n}ez}, 57 | Bibsource = {dblp computer science bibliography, http://dblp.org}, 58 | Biburl = {http://dblp.org/rec/bib/journals/corr/EgorovW17}, 59 | Date-Added = {2017-11-14 15:16:21 +0000}, 60 | Date-Modified = {2017-11-14 15:17:36 +0000}, 61 | Eprint = {1707.06140}, 62 | Journal = {CoRR}, 63 | Timestamp = {Sat, 05 Aug 2017 14:56:03 +0200}, 64 | Title = {NuCypher {KMS:} Decentralized key management system}, 65 | Url = {http://arxiv.org/abs/1707.06140}, 66 | Volume = {abs/1707.06140}, 67 | Year = {2017}, 68 | Bdsk-Url-1 = {http://arxiv.org/abs/1707.06140}} 69 | 70 | @article{shamir1979share, 71 | Author = {Shamir, Adi}, 72 | Date-Added = {2017-11-14 15:12:39 +0000}, 73 | Date-Modified = {2017-11-14 15:12:39 +0000}, 74 | Journal = {Communications of the ACM}, 75 | Number = {11}, 76 | Pages = {612--613}, 77 | Publisher = {ACm}, 78 | Title = {How to share a secret}, 79 | Volume = {22}, 80 | Year = {1979}} 81 | 82 | @article{gayoso2015security, 83 | Author = {Gayoso Mart{\'\i}nez, V and Hern{\'a}ndez Encinas, L and Queiruga Dios, A}, 84 | Date-Added = {2017-11-14 14:53:26 +0000}, 85 | Date-Modified = {2017-11-14 14:53:26 +0000}, 86 | Journal = {Cryptologia}, 87 | Number = {3}, 88 | Pages = {244--269}, 89 | Publisher = {Taylor \& Francis}, 90 | Title = {Security and practical considerations when implementing the Elliptic Curve Integrated Encryption Scheme}, 91 | Volume = {39}, 92 | Year = {2015}} 93 | 94 | @misc{ieee-p1363a, 95 | Date-Added = {2017-10-24 08:20:01 +0000}, 96 | Date-Modified = {2017-10-24 08:20:14 +0000}, 97 | Howpublished = {\url{http://grouper.ieee.org/groups/1363/index.html/}}, 98 | Key = {{IEEE P1363a}}, 99 | Month = jun, 100 | Note = {Draft Version 9}, 101 | Title = {{IEEE P1363a Committee}. {IEEE P1363a / D9} --- Standard Specifications for Public Key Cryptography: Additional Techniques}, 102 | Year = 2001} 103 | 104 | @misc{iso-18033-2, 105 | Author = {Victor Shoup}, 106 | Date-Added = {2017-10-24 08:19:44 +0000}, 107 | Date-Modified = {2017-10-24 08:20:33 +0000}, 108 | Howpublished = {\url{http://shoup.net/iso/std6.pdf}}, 109 | Key = {{ISO 18033-2}}, 110 | Month = dec, 111 | Note = {Final Committee Draft}, 112 | Title = {{ISO 18033-2}: An Emerging Standard for Public-Key Encryption}, 113 | Year = 2004} 114 | 115 | @misc{ansi-x9.63, 116 | Date-Added = {2017-10-24 08:18:35 +0000}, 117 | Date-Modified = {2017-10-24 08:20:44 +0000}, 118 | Key = {ANSI X9.63}, 119 | Month = jul # { 5,}, 120 | Note = {Working draft version 2.0}, 121 | Title = {{American National Standards Institute (ANSI) X9.F1 subcommittee}. {ANSI X9.63 Public key cryptography for the Financial Services Industry: Elliptic curve key agreement and key transport schemes}}, 122 | Year = 1998} 123 | 124 | @article{ateniese2006improved, 125 | Author = {Ateniese, G. and Fu, K. and Green, M. and Hohenberger, S.}, 126 | Date-Added = {2017-10-24 07:41:09 +0000}, 127 | Date-Modified = {2017-10-24 07:41:09 +0000}, 128 | Journal = {ACM Transactions on Information and System Security}, 129 | Number = {1}, 130 | Pages = {1--30}, 131 | Publisher = {ACM}, 132 | Title = {Improved proxy re-encryption schemes with applications to secure distributed storage}, 133 | Volume = {9}, 134 | Year = {2006}} 135 | 136 | @article{blaze1998divertible, 137 | Author = {Blaze, M. and Bleumer, G. and Strauss, M.}, 138 | Date-Added = {2017-10-24 07:41:09 +0000}, 139 | Date-Modified = {2017-10-24 07:41:09 +0000}, 140 | Journal = {Advances in Cryptology---EUROCRYPT'98}, 141 | Pages = {127--144}, 142 | Publisher = {Springer}, 143 | Title = {Divertible protocols and atomic proxy cryptography}, 144 | Year = {1998}} 145 | -------------------------------------------------------------------------------- /Makefile.include: -------------------------------------------------------------------------------- 1 | ### 2 | ### generic GNU make Makefile for .tex -> .pdf. 3 | ### ransford at cs.washington.edu 4 | ### http://github.com/ransford/pdflatex-makefile 5 | ### 6 | ### Recommended usage: 7 | ### 1. echo 'include Makefile.include' > Makefile 8 | ### 2. Optional: Edit the Makefile to override $(TARGET) 9 | ### and anything else (e.g., PDFVIEWER, AFTERALL) 10 | ### 3. $ make snapshot 11 | ### # pass around a draft... 12 | ### 4. $ make distill 13 | ### # submit the camera-ready version with embedded fonts 14 | ### 15 | ### Final result: 16 | ### % cat Makefile 17 | ### TARGET=mypaper 18 | ### PDFVIEWER=open -a 'Adobe Acrobat Professional' 19 | ### AFTERALL=mypostprocessingstep 20 | ### include Makefile.include 21 | ### 22 | ### mypostprocessingstep: 23 | ### # do something... 24 | ### 25 | 26 | PDFLATEX ?= pdflatex -halt-on-error -file-line-error -shell-escape 27 | BIBTEX ?= bibtex 28 | MAKEGLOSSARIES ?= makeglossaries 29 | MAKENOMENCL ?= makeindex 30 | 31 | ## String to find in log to check whether rerun is necessary 32 | RERUN_PATTERN = Rerun to 33 | 34 | ifneq ($(QUIET),) 35 | PDFLATEX += -interaction=batchmode 36 | ERRFILTER := > /dev/null || (egrep ':[[:digit:]]+:' *.log && false) 37 | BIBTEX += -terse 38 | else 39 | PDFLATEX += -interaction=nonstopmode 40 | ERRFILTER= 41 | endif 42 | 43 | ## Action for 'make view' 44 | OS=$(shell uname -s) 45 | ifeq ($(OS),Darwin) 46 | PDFVIEWER ?= open 47 | else 48 | PDFVIEWER ?= xdg-open 49 | endif 50 | 51 | ## Name of the target file, minus .pdf: e.g., TARGET=mypaper causes this 52 | ## Makefile to turn mypaper.tex into mypaper.pdf. 53 | TARGETS += $(TARGET) 54 | TEXTARGETS = $(TARGETS:=.tex) 55 | PDFTARGETS = $(TARGETS:=.pdf) 56 | AUXFILES = $(TARGETS:=.aux) 57 | LOGFILES = $(TARGETS:=.log) 58 | 59 | ## Inkscape SVG file processing: 60 | ifeq ($(shell which inkscape >/dev/null 2>&1 && echo USING_INKSCAPE),USING_INKSCAPE) 61 | FIG_SVG=$(wildcard $(FIGS)/*.svg) 62 | FIG_PDF=$(FIG_SVG:.svg=.pdf) 63 | else 64 | FIG_PDF= 65 | endif 66 | 67 | ## If $(TARGET).tex refers to .bib files like \bibliography{foo,bar}, then 68 | ## $(BIBFILES) will contain foo.bib and bar.bib, and both files will be added as 69 | ## dependencies to $(PDFTARGETS). 70 | ## Effect: updating a .bib file will trigger re-typesetting. 71 | BIBFILES += $(patsubst %,%.bib,\ 72 | $(shell grep '^[^%]*\\bibliography{' $(TEXTARGETS) | \ 73 | grep -o '\\bibliography{[^}]\+}' | \ 74 | sed -e 's/^[^%]*\\bibliography{\([^}]*\)}.*/\1/' \ 75 | -e 's/, */ /g')) 76 | 77 | ## Add \input'ed or \include'd files to $(PDFTARGETS) dependencies; ignore 78 | ## .tex extensions. 79 | INCLUDEDTEX = $(patsubst %,%.tex,\ 80 | $(shell grep '^[^%]*\\\(input\|include\){' $(TEXTARGETS) | \ 81 | grep -o '\\\(input\|include\){[^}]\+}' | \ 82 | sed -e 's/^.*{\([^}]*\)}.*/\1/' \ 83 | -e 's/\.tex$$//')) 84 | 85 | AUXFILES += $(INCLUDEDTEX:.tex=.aux) 86 | 87 | ## grab a version number from the repository (if any) that stores this. 88 | ## * REVISION is the current revision number (short form, for inclusion in text) 89 | ## * VCSTURD is a file that gets touched after a repo update 90 | SPACE = $(empty) $(empty) 91 | ifeq ($(shell git status >/dev/null 2>&1 && echo USING_GIT),USING_GIT) 92 | ifeq ($(shell git svn info >/dev/null 2>&1 && echo USING_GIT_SVN),USING_GIT_SVN) 93 | # git-svn 94 | ifeq ($(REVISION),) 95 | REVISION := $(shell git svn find-rev git-svn) 96 | endif 97 | VCSTURD := $(subst $(SPACE),\ ,$(shell git rev-parse --git-dir)/refs/remotes/git-svn) 98 | else 99 | # plain git 100 | ifeq ($(REVISION),) 101 | REVISION := $(shell git describe --always HEAD) 102 | endif 103 | GIT_BRANCH := $(shell git symbolic-ref HEAD 2>/dev/null) 104 | VCSTURD := $(subst $(SPACE),\ ,$(shell git rev-parse --git-dir)/$(GIT_BRANCH)) 105 | endif 106 | else ifeq ($(shell hg root >/dev/null 2>&1 && echo USING_HG),USING_HG) 107 | # mercurial 108 | ifeq ($(REVISION),) 109 | REVISION := $(shell hg id -i) 110 | endif 111 | VCSTURD := $(subst $(SPACE),\ ,$(shell hg root)/.hg/dirstate) 112 | else ifeq ($(shell svn info >/dev/null && echo USING_SVN),USING_SVN) 113 | # subversion 114 | ifeq ($(REVISION),) 115 | REVISION := $(subst :,-,$(shell svnversion -n)) 116 | endif 117 | VCSTURD := $(addsuffix /.svn/entries, $(shell svn info | grep 'Root Path' | sed -e 's/\(.*\:\)\(.*\) /\2/')) 118 | endif 119 | 120 | # .PHONY names all targets that aren't filenames 121 | .PHONY: all clean pdf view snapshot distill distclean 122 | 123 | all: pdf $(AFTERALL) 124 | 125 | ifeq ($(shell which inkscape >/dev/null 2>&1 && echo USING_INKSCAPE),USING_INKSCAPE) 126 | $(FIGS)/%.pdf: $(FIGS)/%.svg ## Figures for the manuscript 127 | inkscape -C -z --file=$< --export-pdf=$@ 2> /dev/null 128 | endif 129 | 130 | pdf: $(FIG_PDF) $(PDFTARGETS) 131 | 132 | 133 | view: $(PDFTARGETS) 134 | $(PDFVIEWER) $(PDFTARGETS) 135 | 136 | # define a \Revision{} command you can include in your document's preamble. 137 | # especially useful with e.g. draftfooter.sty or fancyhdr. 138 | # usage: \input{revision} 139 | # ... \Revision{} 140 | ifneq ($(REVISION),) 141 | REVDEPS += revision.tex 142 | revision.tex: $(VCSTURD) 143 | /bin/echo '\newcommand{\Revision}'"{$(subst _,\_,$(REVISION))}" > $@ 144 | AUXFILES += revision.aux 145 | endif 146 | 147 | # to generate aux but not pdf from pdflatex, use -draftmode 148 | %.aux: %.tex $(REVDEPS) 149 | $(PDFLATEX) -draftmode $* $(ERRFILTER) 150 | 151 | # specify KEEPAUX=1 if you need to keep auxiliary (.aux) files for some other 152 | # tool (e.g., an autocompleting text editor) 153 | ifneq ($(KEEPAUX),1) 154 | .INTERMEDIATE: $(AUXFILES) 155 | endif 156 | 157 | # introduce BibTeX dependency if we found a \bibliography 158 | ifneq ($(strip $(BIBFILES)),) 159 | BIBDEPS = %.bbl 160 | %.bbl: %.aux $(BIBFILES) 161 | $(BIBTEX) $* 162 | endif 163 | 164 | # introduce makeglossaries dependency if we found \printglossary/ies 165 | HAS_GLOSSARIES = $(shell \ 166 | grep '^[^%]*\\printglossar\(ies\|y\)' $(TEXTARGETS) $(INCLUDEDTEX) && \ 167 | echo HAS_GLOSSARIES) 168 | ifneq ($(HAS_GLOSSARIES),) 169 | GLSDEPS = %.gls 170 | %.gls: %.aux 171 | $(MAKEGLOSSARIES) $(TARGETS) 172 | endif 173 | 174 | # introduce makenomenclature dependency if we found \printnomenclature 175 | HAS_NOMENCL = $(shell \ 176 | grep '^[^%]*\\printnomenclature' $(TEXTARGETS) $(INCLUDEDTEX) && \ 177 | echo HAS_NOMENCL) 178 | ifneq ($(HAS_NOMENCL),) 179 | NLSDEPS = %.nls 180 | %.nls: %.nlo 181 | $(MAKENOMENCL) $(TARGETS).nlo -s nomencl.ist -o $(TARGETS).nls 182 | endif 183 | 184 | $(PDFTARGETS): %.pdf: %.tex %.aux $(GLSDEPS) $(BIBDEPS) $(INCLUDEDTEX) $(REVDEPS) $(NLSDEPS) 185 | $(PDFLATEX) $* $(ERRFILTER) 186 | ifneq ($(strip $(BIBFILES)),) 187 | @if egrep -q "undefined (references|citations)" $*.log; then \ 188 | $(BIBTEX) $* && $(PDFLATEX) $* $(ERRFILTER); fi 189 | endif 190 | @while grep -q "$(RERUN_PATTERN)" $*.log; do \ 191 | $(PDFLATEX) $* $(ERRFILTER); done 192 | 193 | DRAFTS := $(PDFTARGETS:.pdf=-$(REVISION).pdf) 194 | $(DRAFTS): %-$(REVISION).pdf: %.pdf 195 | cp $< $@ 196 | snapshot: $(DRAFTS) 197 | 198 | %.distilled.pdf: %.pdf 199 | gs -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=$@ \ 200 | -dCompatibilityLevel=1.5 -dPDFSETTINGS=/prepress -c .setpdfwrite -f $< 201 | exiftool -overwrite_original -Title="" -Creator="" -CreatorTool="" $@ 202 | 203 | distill: $(PDFTARGETS:.pdf=.distilled.pdf) 204 | 205 | distclean: clean 206 | $(RM) $(PDFTARGETS) $(PDFTARGETS:.pdf=.distilled.pdf) $(EXTRADISTCLEAN) 207 | 208 | clean: 209 | $(RM) $(foreach T,$(TARGETS), \ 210 | $(T).bbl $(T).bcf $(T).bit $(T).blg \ 211 | $(T)-blx.bib $(T).brf $(T).glg $(T).glo \ 212 | $(T).gls $(T).glsdefs $(T).glx \ $(T).gxg \ 213 | $(T).gxs $(T).idx $(T).ilg $(T).ind \ 214 | $(T).ist $(T).loa $(T).lof $(T).lol \ 215 | $(T).lot $(T).maf $(T).mtc $(T).nav \ 216 | $(T).out $(T).pag $(T).run.xml $(T).snm \ 217 | $(T).svn $(T).tdo $(T).tns $(T).toc \ 218 | $(T).vtc $(T).url) \ 219 | $(REVDEPS) $(AUXFILES) $(LOGFILES) \ 220 | $(EXTRACLEAN) $(FIG_PDF) 221 | 222 | -------------------------------------------------------------------------------- /umbral-doc.tex: -------------------------------------------------------------------------------- 1 | \documentclass{amsart} 2 | \usepackage{amsaddr} 3 | \usepackage{amsmath} 4 | \usepackage{amssymb} 5 | \usepackage{geometry} % see geometry.pdf on how to lay out the page. There's lots. 6 | \geometry{a4paper} % or letter or a5paper or ... etc 7 | \usepackage[utf8]{inputenc} 8 | \usepackage{url} 9 | \usepackage{graphicx} 10 | \usepackage{algorithm} 11 | \usepackage{algorithmic} 12 | \renewcommand{\algorithmicrequire}{\textbf{Input:}} 13 | \renewcommand{\algorithmicensure}{\textbf{Output:}} 14 | 15 | \newcommand{\pyumbral}{\textsf{pyUmbral}} 16 | \newcommand{\secp}{\textsf{secp256k1}} 17 | 18 | \newcommand{\rk}[2]{rk_{#1\rightarrow#2}} 19 | \providecommand{\pk}[1]{pk_{#1}} 20 | \providecommand{\sk}[1]{sk_{#1}} 21 | \newcommand{\etal}{\emph{et al.\ }} 22 | 23 | \newcommand{\G}{\mathbb G} 24 | 25 | \title{Umbral: a threshold proxy re-encryption scheme} 26 | \author{David Nuñez} 27 | \address{NuCypher Inc.\\\&\\NICS Lab, University of Malaga, Spain} 28 | \email{david@nucypher.com} 29 | \date{} % delete this line to display the current date 30 | 31 | %%% BEGIN DOCUMENT 32 | 33 | 34 | 35 | \begin{document} 36 | 37 | \maketitle 38 | 39 | \begin{abstract} 40 | This document describes the Umbral proxy re-encryption scheme, as used by NuCypher KMS \cite{egorov2017nucypherkms}. 41 | Umbral is a threshold proxy re-encryption scheme following a Key Encapsulation Mechanism (KEM) approach. It is inspired by ECIES-KEM \cite{ansi-x9.63}, and the BBS98 proxy re-encryption scheme \cite{blaze1998divertible}. 42 | With Umbral, Alice (which in the generic name for data owners in NuCypher KMS) can delegate decryption rights to Bob for any ciphertext intended to her, through a re-encryption process performed by a set of $N$ semi-trusted proxies. When at least $t$ of these proxies (out of $N$) participate by performing re-encryption, Bob is able to combine these independent re-encryptions and decrypt the original message using his private key. 43 | The name ``Umbral'' comes from the Spanish word for ``threshold'', emphasizing this characteristic of the scheme, given its central role in the decentralized architecture of NuCypher KMS. 44 | \end{abstract} 45 | 46 | %\tableofcontents 47 | 48 | 49 | \section{Introduction} 50 | 51 | NuCypher KMS \cite{egorov2017nucypherkms} is a decentralized key management system (KMS), encryption, and access control service. 52 | It uses proxy re-encryption to delegate decryption rights, enabling this way the private sharing of data between arbitrary numbers of participants in public consensus networks, without revealing data keys to intermediary entities. 53 | 54 | Umbral is a threshold proxy re-encryption scheme loosely inspired by ECIES-KEM \cite{ansi-x9.63} (since the Umbral KEM is constructed similarly as in ECIES) and the BBS98 proxy re-encryption scheme \cite{blaze1998divertible}, although with several improvements to make it non-interactive, unidirectional, and most importantly, verifiable with respect to re-encryption. Finally, the threshold functionality of Umbral reuses ideas from Shamir's Secret Sharing \cite{shamir1979share}, although applied to the context of proxy re-encryption. 55 | 56 | We provide a reference implementation in Python called \pyumbral~\cite{pyumbral}, instantiated over elliptic curve \secp. 57 | 58 | %With respect to the former, Umbral ciphertexts have ``almost'' the same form than ECIES ciphertexts: in both cases, they are composed of an encoded EC point used as ephemeral public key, an encrypted payload using a symmetric encryption algorithm and a MAC code. We say ``almost'' because we introduce some differences that are not supported by the various ECIES specifications; in any case, compliance with ECIES specifications is not one of our goals. 59 | % 60 | % 61 | %We also remark that we don't use directly Umbral as is, since it is an interactive scheme (i.e., re-encryption key generation requires the secret keys of both Alice and Bob). 62 | %Instead, we use a generic method to transform any interactive PRE scheme into non-interactive. 63 | 64 | \section{Preliminaries} 65 | 66 | \subsection{Notation} 67 | 68 | Although the additive notation is the norm when dealing with elliptic curve cryptography, in this document we adopt the multiplicative notation to express the operations in the elliptic curve group, which is the usual approach in the proxy re-encryption literature (where schemes are usually defined in generic groups). 69 | 70 | \subsection{A brief introduction to Proxy Re-Encryption} 71 | 72 | Proxy re-encryption is a special type of public-key encryption that permits a proxy to transform ciphertexts from one public key to another, without the proxy being able to learn any information about the original message; to do so, the proxy must be in possession of a \emph{re-encryption key} that enables this process \cite{nunez2017proxy}. Thus, it serves as a means for delegating decryption rights, opening up many possible applications that require of delegated access to encrypted data. In the PRE literature, the parties involved are usually labeled in terms of a relationship of delegation, namely: %. A typical proxy re-encryption environment involves at least three parties: 73 | \begin{description} 74 | \item[Delegator] This actor is the one that \emph{delegates} his decryption rights using proxy re-encryption. In order to do this he creates a re-encryption key, which he sends to the proxy. We usually refer to the delegator as ``Alice''. 75 | \item[Delegatee] The delegatee is granted a delegated right to decrypt ciphertexts that, although were not intended for him in the first place, where re-encrypted for him with permission from the original recipient (i.e., the delegator). This actor usually takes the name ``Bob''. 76 | \item[Proxy] It handles the re-encryption process that transforms ciphertexts under the delegator's public key into ciphertexts that the delegatee can decrypt using his private key. The proxy uses the re-encryption key during this process, and does not learn any additional information. 77 | \end{description} 78 | 79 | \begin{figure}%[h] 80 | \centering 81 | \includegraphics[width=0.75\textwidth]{figures/pre.pdf} 82 | \caption{Main actors and interactions in a PRE environment} 83 | \label{fig:pre-actores} 84 | \end{figure} 85 | 86 | Figure~\ref{fig:pre-actores} depicts the main actors in a PRE environment and their interactions. Since PRE is a special type of PKE, users also have a pair of public and private keys, as shown in the figure. Hence, anyone that knows a public key is capable of producing ciphertexts intended for the corresponding recipient; conversely, these ciphertexts can only be decrypted using the corresponding decryption key. 87 | The distinctive aspect is that ciphertexts can be re-encrypted in order to be decrypted by a different private key than the one originally intended. 88 | 89 | This definition is oblivious to the specific properties of PRE schemes \cite{nunez2015parametric} 90 | 91 | \begin{description} 92 | \item[Directionality] A PRE scheme is \emph{unidirectional} if the re-encryption keys enable the transformation of ciphertexts only in one direction, from delegator to delegatee, and is \emph{bidirectional} otherwise. 93 | \item[Number of hops] We say a PRE scheme is \emph{single-hop} (or \emph{single-use}) if a re-encrypted ciphertext cannot be re-encrypted again, while it is \emph{multi-hop} (or \emph{multu-use}) if ciphertexts are re-encryptable multiple times. 94 | \item[Interactivity] If the secret key of the delegatee is not needed in the re-encryption key generation process, then the scheme is \emph{not interactive} (i.e., since he does not have to participate in the process). Otherwise, we say it is \emph{interactive}. 95 | \end{description} 96 | 97 | See \cite[Section 3.3]{nunez2017proxy} for a more detailed description of these and other PRE properties. 98 | 99 | 100 | %\subsection{ECIES} 101 | % 102 | %The Asymmetric Encryption Scheme defined in standard ANSI X9.63 \cite{ansi-x9.63}, also known as Elliptic Curve Integrated Encryption Scheme (ECIES), is a hybrid encryption algorithm based on elliptic curve cryptography, symmetric encryption and message authentication codes. 103 | %This algorithm is of public knowledge, and variants have been standardized also by ISO/IEC 18033-2 \cite{iso-18033-2} and IEEE P1363A \cite{ieee-p1363a}. A comparison of the different variants of ECIES can be found in \cite{gayoso2015security}. 104 | % 105 | %When producing a ciphertext with ECIES, the sender first creates an ephemeral public key and uses it for a Diffie-Hellman key agreement together with the public key of the intended recipient. The resulting shared secret is used to create the keys for the symmetric encryption and message authentication code algorithms used internally. The final ciphertext consists of the ephemeral public key, as it is necessary for decryption, and the output of the symmetric encryption and message authentication code. 106 | % 107 | %A Sender can be any entity that generates data and wants to send it confidentially to a receiver, in the form of a ciphertext encrypted under the public key of the receiver. 108 | %% 109 | %A Receiver can be any entity that is entitled to read ciphertexts encrypted under his public key. We distinguish two types of receivers. The original receiver, which is the recipient of the data originally intended by the sender, and the delegated receiver, whom the original receiver entrusts to be able to decrypt ciphertexts initially intended to him. Therefore, there is a relation of delegation between the original receiver and the delegated one. 110 | %% 111 | %The Intermediary is an entity that controls the process of switching the public key of ciphertexts, from the public key of the original receiver to the public key of a delegated receiver, without being able to learn anything from the data. The Intermediary needs a key-switching key between the original and delegated receivers in order to be able to perform the key-switching process. 112 | % 113 | %%ECIES can be used in a variety of elliptic curves, but we will restrict the choice of elliptic curves in our cryptosystem to those that generate a group of prime order. %ECIES define procedures for encryption and decryption, as well as defines 114 | % 115 | %\subsubsection{Differences between Umbral and ECIES} 116 | % 117 | %The two most important differences we introduce are the following: 118 | % 119 | %\begin{itemize} 120 | % 121 | %\item Single Hash Mode activated: 122 | %During encryption and decryption, the ephemeral public key is not included in the KDF input. This has some theoretical implications with respect to security, as it can make ECIES encryption malleable. For example, when the KDF only takes the $x$-coordinate of the input EC point, an attacker may replace the ephemeral public key (which is part of the ciphertext) by its inverse; however, this attack is very limited, to the point that Shoup calls this ``benign malleability'' \cite{shoup}. As countermeasure, some ECIES variants allow to include the ephemeral public key as part of the KDF input. In particular, the ISO/IEC 18033-2 standard specification defines an option called Single Hash Mode, which, when activated, removes the ephemeral public key as input to the KDF. Note that this mode is off by default in the ISO/IEC 18033-2 standard (i.e., the ephemeral public key is included). 123 | % 124 | %We must point out that Umbral takes advantage of this malleability during the re-encryption process, in order to transform ciphertexts from one recipient (Alice) to another (Bob). This is done precisely by altering the ephemeral key in the ciphertext. In order to do so, we require that Single Hash Mode is activated so the alteration of the ephemeral key doesn't affect the key derivation process. 125 | % 126 | %As a final comment, we remark that a certain degree of malleability is unavoidable in any proxy re-encryption scheme, given that its goal is to \emph{transform} ciphertexts from one recipient to another. See \cite{canetti2007chosen} for a deeper discussion on the dichotomy between malleability and re-encryption. 127 | % 128 | % 129 | %\item Authenticated Encryption: The original design of ECIES, in all its variants, uses a symmetric encryption algorithm and a message authentication code for protecting data's confidentiality, integrity and authenticity. However, for the sake of simplicity, we will use a single authenticated encryption primitive that combines all these functionalities. This same approach is used by others, such as the ECIES implementation in Google Tink \cite{tink}. 130 | % 131 | %\end{itemize} 132 | % 133 | % 134 | % 135 | 136 | \section{The Umbral PRE cryptosystem} 137 | 138 | In this section we present the Umbral PRE cryptosystem. However, since Umbral is designed following the KEM/DEM approach, our focus will be in the Umbral KEM, since the DEM part is not affected by the ``re-encryption'' process. Note that when referring to ``re-encryption'' we are actually dealing with the transformation of the KEM ciphertexts (or ``capsules''), so technically, it appears it is more appropriate to call this process ``re-encapsulation''. This would lead to the natural sequence of encapsulation/re-encapsulation/decapsulation, as shown in Figure~\ref{fig:umbral-kem}. When possible we will use the term ``re-encapsulation'', although we will continue to use ``re-encryption'' in some contexts such as ``re-encryption keys'', since in the end Umbral KEM will be used as part of a full-fledged proxy re-encryption scheme. 139 | 140 | In this section we will first describe the syntax of the Umbral KEM; next, we present its construction; and finally, its integration with a DEM (i.e., a symmetric encryption algorithm) to produce the Umbral proxy re-encryption scheme. 141 | 142 | \begin{figure}%[h] 143 | \centering 144 | \includegraphics[width=\textwidth]{figures/umbral-kem-flow.pdf} 145 | \caption{Main operation of Umbral KEM. Operations are shown in yellow, cryptographic keys in gray, and data in white} 146 | \label{fig:umbral-kem} 147 | \end{figure} 148 | 149 | \subsection{Syntax of Umbral KEM} 150 | 151 | The following is a description of the basic functions provided by Umbral KEM. For clarity we have categorized these functions in different groups according to their functionality. 152 | 153 | \subsubsection{Key Generation Algorithms} 154 | 155 | \begin{itemize} 156 | 157 | \item $\mathsf{KeyGen}()$: The key generation algorithm $\mathsf{KeyGen}$ outputs a pair of public and secret keys $(\pk{A}, \sk{A})$. 158 | \item $\mathsf{ReKeyGen}(sk_A, pk_B, N, t)$: On input the secret key $sk_{A} = a$, the public key of the intended delegatee $pk_{B} = g^b$, a number of fragments $N$, and a threshold $t$, the re-encryption key generation algorithm $\mathsf{ReKeyGen}$ computes $N$ fragments of the re-encryption key between $A$ and $B$, each of them named $kFrag$. 159 | \end{itemize} 160 | 161 | 162 | \subsubsection{Encapsulation and Decapsulation} 163 | 164 | \begin{itemize} 165 | \item $\mathsf{Encapsulate}(pk_A)$: On input the public key $pk_A$, the encapsulation algorithm $\mathsf{Encapsulate}$ a symmetric key $K$ and a $capsule$ that allows to derive again (i.e., ``decapsulate'') the symmetric key $K$. 166 | 167 | \item $\mathsf{Decapsulate}(sk_A, capsule)$: On input the secret key $sk_A$, and an original $capsule$, the decapsulation algorithm $\mathsf{Decapsulate}$ outputs the symmetric key $K$, or $\perp$ if the capsule is invalid. 168 | 169 | 170 | \end{itemize} 171 | 172 | \subsubsection{Re-Encapsulation and Fragments Decapsulation}%ryption and Verification of Re-Encryption} 173 | 174 | \begin{itemize} 175 | \item $\mathsf{ReEncapsulation}(kFrag, capsule)$: On input a re-encryption key fragment $kFrag$, and a $capsule$, the re-encapsulation algorithm $\mathsf{ReEncapsulation}$ outputs the capsule fragment $cFrag$, or $\perp$ if the the process fails. 176 | 177 | \item $\mathsf{DecapsulateFrags}(sk_B, \{cFrag_i\}_{i=1}^t, capsule)$: On input the secret key $sk_B$, and a set of $t$ capsule fragments or $cFrags$, the fragments decapsulation algorithm outputs the symmetric key $K$, or $\perp$ if the decryption fails. 178 | 179 | \end{itemize} 180 | 181 | \subsection{The Umbral KEM construction} 182 | 183 | \subsubsection{Setup and public parameters}\label{sec:setup_umbral} 184 | 185 | \begin{itemize} 186 | 187 | \item $\mathsf{Setup}(sec)$: The setup algorithm first determines a cyclic group $\mathbb G$ of prime order $q$, according to the security parameter $sec$. Let $g, U\in \mathbb G$ be generators. Let $H_2: \mathbb G^2 \to \mathbb Z_q$, $H_3: \mathbb G^3 \to \mathbb Z_q$, and $H_4: \mathbb G^3 \times Z_q \to \mathbb Z_q$ be hash functions that behave as random oracles. Let $\mathsf{KDF}: \mathbb G \to \{0,1\}^\ell$ be a key derivation function also modeled as a random oracle, where $\ell$ is according to the security parameter $sec$. The global public parameters are represented by the tuple: 188 | $$params = (\mathbb G, g, U, H_2, H_3, H_4, \mathsf{KDF})$$ 189 | 190 | \end{itemize} 191 | 192 | For simplicity, we will omit the public parameters from the rest of the functions. 193 | 194 | \subsubsection{Key Generation Algorithms} 195 | 196 | \begin{itemize} 197 | %\item $\mathsf{Setup}(1^k)\rightarrow params$. On input the security parameter $1^k$, the global setup algorithm $\mathsf{Setup}$ outputs the global parameters $params$. 198 | \item $\mathsf{KeyGen}()$: Sample $a \in \mathbb Z_q$ uniformly at random, compute $g^a$ and output the keypair $(pk, sk) = (g^a, a)$. 199 | 200 | \item $\mathsf{ReKeyGen}(sk_A, pk_B, N, t)$: On input the secret key $sk_{A} = a$, the public key of the intended delegatee $pk_{B} = g^b$, a number of fragments $N$, and a threshold $t$, the re-encryption key generation algorithm $\mathsf{ReKeyGen}$ computes $N$ fragments of the re-encryption key between $A$ and $B$ as follows: 201 | 202 | \begin{enumerate} 203 | \item Sample random $x_A \in \mathbb Z_q$ and compute $X_A = g^{x_A}$ 204 | \item Compute $ d = H_3(X_A, pk_B, (pk_B)^{x_A})$. Note how $d$ is the result of a non-interactive Diffie-Hellman key exchange between $B$'s keypair and the ephemeral key pair $(x_A, X_A)$. We will use this shared secret to make the re-encryption key generation of the scheme non-interactive. 205 | \item Sample random $t-1$ elements $f_i\in \mathbb Z_q$, with $1 \leq i \leq t-1$, and compute $f_0 = a \cdot d^{-1} \bmod q$. 206 | \item Construct a polynomial $f(x) \in \mathbb Z_q[x]$ of degree $t-1$, such that $f(x) = f_0 + f_1x + f_2x^2 + ... + f_{t-1}x^{t-1}$. 207 | \item Compute $ D = H_6(pk_A, pk_B, pk_B^a)$ 208 | \item Initialize set $KF = \emptyset$ and repeat $N$ times: 209 | 210 | \begin{enumerate} 211 | \item Sample random $y, id \in \mathbb Z_q$ 212 | \item Compute $s_x = H_5(id, D)$ and $Y = g^y$. 213 | \item Compute $rk = f(s_x)$ 214 | \item Compute $U_1 = U^{rk}$. 215 | \item Compute $z_1 = H_4(Y, id, pk_A, pk_B, U_1, X_A)$, and $z_2 = y - a \cdot z_1$. 216 | \item Define a re-encryption key fragment $kFrag$ as the tuple $(id, rk, X_A, U_1, z_1, z_2)$. 217 | \item $KF = KF \cup \{kFrag\}$ 218 | \end{enumerate} 219 | 220 | \item Finally, output the set of re-encryption key fragments $KF$. 221 | \end{enumerate} 222 | \end{itemize} 223 | 224 | 225 | \subsubsection{Encapsulation and Decapsulation} 226 | 227 | \begin{itemize} 228 | \item $\mathsf{Encapsulate}(pk_A)$: On input the public key $pk_A$, the encapsulation algorithm $\mathsf{Encapsulate}$ first samples random $r, u \in \mathbb Z_q$ and computes $E = g^r$ and $V = g^u$. 229 | Next, it computes the value $s = u + r \cdot H_2(E, V)$. 230 | The derived key is computed as $K = \mathsf{KDF}((pk_A)^{r + u})$. 231 | The tuple $(E, V, s)$ is called $capsule$ and allows to derive again (i.e., ``decapsulate'') the symmetric key $K$. 232 | Finally, the encapsulation algorithm outputs $(K, capsule)$. 233 | 234 | \item $\mathsf{CheckCapsule}(capsule)$: On input a $capsule = (E, V, s)$, this algorithm examines the validity of the capsule by checking if the following equation holds: 235 | $$ g^s \stackrel{?}{=} V \cdot E^{H_2(E, V)}$$ 236 | 237 | \item $\mathsf{Decapsulate}(sk_A, capsule)$: On input the secret key $sk_A = a$, and an original $capsule = (E,V,s)$, the decapsulation algorithm $\mathsf{Decapsulate}$ first checks the validity of the capsule with $\mathsf{CheckCapsule}$ and outputs $\perp$ if the check fails. Otherwise, it computes $K = \mathsf{KDF}((E\cdot V)^{a})$. Finally, it outputs $K$. 238 | 239 | \end{itemize} 240 | 241 | \subsubsection{Re-Encapsulation and Fragments Decapsulation}%ryption and Verification of Re-Encryption} 242 | 243 | \begin{itemize} 244 | \item $\mathsf{ReEncapsulate}(kFrag, capsule)$: On input a re-encryption key fragment $kFrag= (id, rk, X_A, U_1, z_1, z_2)$, and a $capsule = (E,V,s)$, the re-encapsulation algorithm $\mathsf{ReEncapsulate}$ first checks the validity of the capsule with $\mathsf{CheckCapsule}$ and outputs $\perp$ if the check fails. Otherwise, it computes $E_1 = E^{rk}$ and $V_1 = V^{rk}$, and outputs the capsule fragment $cFrag = (E_1, V_1, id, X_A)$. 245 | 246 | \item $\mathsf{DecapsulateFrags}(sk_B, pk_A, \{cFrag_i\}_{i=1}^t)$: On input the secret key $sk_B = b$, the original public key $pk_A = g^a$, and a set of $t$ capsule fragments, being each of them $cFrag_i = (E_{1,i}, V_{1,i}, id_i, X_A)$, the fragments decapsulation algorithm $\mathsf{DecapsulateFrag}$ does the following: 247 | 248 | \begin{enumerate} 249 | \item Compute $ D = H_6(pk_A, pk_B, pk_A^b)$ 250 | \item Let $S = \{s_{x,i}\}_{i=1}^t$, for $s_{x,i} = H_5(id_i, D)$. For all $s_{x,i}\in S$, compute: 251 | \[\lambda_{i, S} = \prod\limits_{j=1, j\neq i}^{t} \frac{s_{x,j}}{s_{x,j}-s_{x,i}}\] 252 | \item Compute the values: 253 | $$E' = \prod\limits_{i=1}^{t} (E_{1,i})^{\lambda_{i, S}} 254 | \qquad 255 | V' = \prod\limits_{i=1}^{t} (V_{1,i})^{\lambda_{i, S}}$$ 256 | \item Compute $d = H_3(X_A, pk_B, X_A^b)$. Recall that $d$ is the result of a non-interactive Diffie-Hellman key exchange between $B$'s keypair and the ephemeral key pair $(x_A, X_A)$. Note also that the value $X_A$ is the same for all the $cFrags$ that are produced by re-encryptions using a $kFrag$ in the set of re-encryption key fragments $KF$. 257 | \item Finally, output the symmetric key $K= \mathsf{KDF}((E'\cdot V')^{d})$. 258 | \end{enumerate} 259 | 260 | 261 | 262 | 263 | \end{itemize} 264 | 265 | 266 | 267 | \subsection{The KEM/DEM construction} 268 | 269 | Extending Umbral KEM with a DEM results in a full-fledged proxy re-encryption scheme. As such, this defines encryption and decryption algorithms, rather than encapsulation and decapsulations. We require the DEM to be an authenticated encryption with associated data algorithm, which we will denote as $\mathsf{AEAD}$. Note also how the re-encryption algorithm actually does not involve any symmetric encryption operation. We omit the key generation algorithms since they are not changed in the extension. 270 | 271 | \begin{itemize} 272 | 273 | \item $\mathsf{Encrypt}(pk_A, M)$: On input the public key $pk_A$ and a message $M\in\mathcal{M}$, the encryption algorithm $\mathsf{Encrypt}$ first computes $(K, capsule) = \mathsf{Encapsulate}(pk_A)$. 274 | $encData$ is the result of applying $\mathsf{AEAD}$ to $M$ with key $K$, with $capsule$ as associated data. 275 | Finally, it outputs the ciphertext $C = (capsule, encData)$. 276 | 277 | \item $\mathsf{Decrypt}(sk_A, C)$: On input the secret key $sk_A$ and a ciphertext $C = (capsule, encData)$, the decryption algorithm $\mathsf{Decrypt}$ computes the key $K = \mathsf{Decapsulate}(sk_A, capsule)$, and decrypts ciphertext $encData$ using the decryption function of $\mathsf{AEAD}$ with key $K$ and $capsule$ as associated data, which results in message $M$ if decryption is correct, and $\perp$ otherwise. Finally, it outputs message $M$ (or $\perp$ if decryption was invalid). 278 | 279 | \item $\mathsf{ReEncrypt}(kFrag, C)$: On input a re-encryption key fragment $kFrag$ and a ciphertext $C = (capsule, encData)$, the re-encryption algorithm $\mathsf{ReEncrypt}$ applies $\mathsf{ReEncapsulate}$ to the $capsule$ to obtain a $cFrag$, and outputs the re-encrypted ciphertext $C' = (cFrag, encData)$. 280 | 281 | \item $\mathsf{DecryptFrags}(sk_B, \{C'_i\}_{i=1}^t)$: On input the secret key $sk_B$, a set of $t$ re-encrypted ciphertexts $C'_i = (cFrag_i, encData)$, the fragments decryption algorithm $\mathsf{DecryptFrags}$ first decapsulates the $cFrags$ with $\mathsf{DecapsulateFrags}(sk_B, \{cFrag_i\}_{i=1}^t)$ to produce key $K$, and decrypts ciphertext $encData$ using the decryption function of $\mathsf{AEAD}$ with key $K$ and $capsule$ as associated data, which results in message $M$ if decryption is correct, and $\perp$ otherwise. Finally, it outputs message $M$ (or $\perp$ if decryption was invalid). Note that the symmetric ciphertext $encData$ is the same for all the $C'_i$ that are re-encryptions of the same ciphertext $C$. 282 | 283 | \end{itemize} 284 | 285 | \section{Providing Proofs of Re-Encryption Correctness} 286 | 287 | %\subsubsection{Re-Encryption Correctness} 288 | %\begin{itemize} 289 | %\item $\mathsf{ProveCorrectness}(kFrag, capsule, cFrag, metadata)$: On input a re-encryption key fragment $kFrag$, a $capsule$, the re-encapsulation algorithm $\mathsf{ReEncapsulation}$ outputs the capsule fragment $cFrag$, or $\perp$ if the the process fails. 290 | 291 | To prove correctness of re-encryption, the proxy uses a non-interactive zero-knowledge proof of discrete logarithm equality that shows that both $E_1$ and $V_1$ are exponentiations of, respectively, $E$ and $V$ for the same exponent, and that this exponent is the same used in $U_1$ with respect to $U$. Since $U$ is a public parameter of the system, and $U_1$ is signed by Alice and attached to the proof, then this proofs that $E_1 = E^{rk}$ and $V_1 = V^{rk}$, given that $U_1 = U^{rk}$. In other words, let $dlog_B(X)$ be the discrete logarithm of $X \in \G$ with respect to element $B \in G$; the re-encryption correctness proof shows that $dlog_E(E_1) = dlog_V(V_1) = dlog_U(U_1)$. 292 | 293 | \subsection{Producing proofs of re-encryption correctness} 294 | 295 | This extends the $\mathsf{ReEncapsulate}$ algorithm to include a proof of correctness in the resulting $cFrag$. We also support the addition of an optional arbitrary input $aux$ to be added to the proof, and which can be used as metadata for the re-encryption request (e.g., in the NuCypher KMS this would include the proxy identifier, a timestamp, etc.). 296 | 297 | Let the re-encryption key fragment be $kFrag= (id, rk, X_A, U_1, z_1, z_2)$, and the input $capsule = (E,V,s)$. The resulting capsule fragment is $cFrag = (E_1, V_1, id, X_A)$. 298 | A correctness proof $\pi$ for $cFrag$ is generated as follows: 299 | \begin{enumerate} 300 | \item Sample random $\tau \in \mathbb Z_q$ 301 | \item Compute the values: 302 | $\qquad E_2 = E^{\tau} \qquad V_2 = V^\tau \qquad U_2 = U^\tau$ 303 | \item Compute the hash value $h = H(E, E_1, E_2, V, V_1, V_2, U, U_1, U_2, aux)$ 304 | \item Compute $\rho = \tau + h\cdot rk$ 305 | \item Output the proof $\pi = (E_2, V_2, U_2, U_1, z_1, z_2, \rho, aux)$ 306 | \end{enumerate} 307 | 308 | The result of the extended $\mathsf{ReEncapsulate}$ algorithm with correctness guarantees is the tuple $(cFrag, \pi)$. 309 | 310 | \subsection{Verifying proofs of re-encryption correctness} 311 | 312 | This extends the $\mathsf{DecapsulateFrags}$ algorithm to check the attached proof for each $cFrag$. 313 | 314 | Let the input $capsule$ be the tuple $(E,V,s)$. For each $cFrag = (E_1, V_1, id, X_A)$ and proof $\pi = (E_2, V_2, U_2, U_1, z_1, z_2, \rho, aux)$: 315 | \begin{enumerate} 316 | \item Check that the kFrag signature $(z_1, z_2)$ is correct. 317 | \item Compute the hash value $h = H(E, E_1, E_2, V, V_1, V_2, U, U_1, U_2, aux)$ 318 | \item Check that the following equations hold: 319 | \begin{align*} 320 | E^{\rho} &\stackrel{?}{=} E_2 \cdot E_1^h \\ 321 | V^{\rho} &\stackrel{?}{=} V_2 \cdot V_1^h \\ 322 | U^{\rho} &\stackrel{?}{=} U_2 \cdot U_1^h 323 | \end{align*} 324 | \end{enumerate} 325 | 326 | 327 | 328 | 329 | 330 | \section{Notes concerning Umbral reference implementation (\textsf{pyUmbral})} 331 | 332 | \subsection{Choice of elliptic curve} 333 | The only restriction that the Umbral cryptosystem imposes on the choice of EC curve is that it should generate a group of prime order, since we need to compute inverses modulo the order of this group. In our current setting, we use the \textsf{secp256k1} curve since it fulfills this latter requirement and it is widely used in the blockchain ecosystem; we are exploring other curve choices that could improve performance. 334 | 335 | \subsection{Hash functions} 336 | As described in Section~\ref{sec:setup_umbral}, Umbral requires several hash functions, such as $H_2: \mathbb G^2 \to \mathbb Z_q$, $H_3: \mathbb G^3 \to \mathbb Z_q$, and $H_4: \mathbb G^3 \times Z_q \to \mathbb Z_q$, which behave as random oracles that output an element of $\mathbb Z_q$. Since for elements of both $\mathbb G$ and $\mathbb Z_q$ there exists efficient encodings to bit string (e.g., compressed representation in the case EC points), in \textsf{pyUmbral} we implement these hash functions from a common hash function $H': \{0,1\}^* \to \mathbb Z_q$. For example, for the case of $H_2$, we can define it as $H_2(g_1, g_2) = H'(\mathsf{encode}(g_1)||\mathsf{encode}(g_2))$. 337 | 338 | This reduces the problem to the definition of $H'$. Let $n$ be the order of the group induced by the curve in use, $X$ a byte string of arbitrary size, and $\mathsf{digest}$ a cryptographic hash function with a digest size $> 64 + \log_2(n)$ (e.g., for a 256-bit curve, we use \textsf{BLAKE2b} with a digest size of 512 bits). The output $h_X$ of $H'(X)$ is computed as: 339 | $$h_X \Leftarrow 1 + \mathsf{int}(\mathsf{digest}(X)) \bmod (n-1)$$ 340 | 341 | In \pyumbral, this is implemented by the class method \texttt{CurveBN.hash()}. 342 | For reference, in the case of curve \secp~and BLAKE2b with a digest size of 512-bits: 343 | \begin{align*} 344 | X &= &\mathtt{616263} \text{\quad(ASCII string ``\textit{abc}'')}\\ 345 | n &= &\mathtt{fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141} \\ 346 | \mathsf{digest}(X) &= &\mathtt{ba80a53f981c4d0d6a2797b69f12f6e94c212f14685ac4b74b12bb6fdbffa2d1}\\ 347 | & &\mathtt{7d87c5392aab792dc252d5de4533cc9518d38aa8dbf1925ab92386edd4009923}\\ 348 | h_X &= &\mathtt{63b4973dd623699fe9b344da6ddd77fa5dd60413a21f6ad810186602d05dd1a4} 349 | \end{align*} 350 | 351 | \subsection{Symmetric encryption} 352 | As per the authenticated encryption scheme, we use Chacha20-Poly1305 as provided by cryptography.io \cite{chacha20-pyca}. 353 | %https://cryptography.io/en/latest/hazmat/primitives/aead/#cryptography.hazmat.primitives.ciphers.aead.ChaCha20Poly1305 354 | 355 | \subsection{Key derivation} 356 | For the KDF, we use \textsf{HKDF} with \textsf{BLAKE2b} as hash function, with a digest size of 64 bytes. 357 | 358 | %\subsection{Nothing-up-my-sleeve generation of public parameters} 359 | %Umbral requires a group element $U$ that is used as another generator. In order to 360 | 361 | 362 | \bibliographystyle{unsrt} % APS-like style for physics 363 | \bibliography{umbral-doc} 364 | \end{document} --------------------------------------------------------------------------------