2026-09-19T06:10:47Zhttps://dspace.mit.edu/server/oai/requestoai:dspace.mit.edu:1721.1/416712022-01-13T07:54:29Zcom_1721.1_7582com_1721.1_7581col_1721.1_131023
Silvio Micali.
Reich, Eitan
Massachusetts Institute of Technology. Dept. of Electrical Engineering and Computer Science.
Massachusetts Institute of Technology. Department of Electrical Engineering and Computer Science
2008-05-19T16:07:24Z
2008-05-19T16:07:24Z
2007
2007
http://hdl.handle.net/1721.1/41671
220931319
Thesis (M. Eng.)--Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, 2007.
Includes bibliographical references (p. 55-57).
Ring Signatures were developed by Rivest, Shamir and Tauman, in a paper titled How to Leak a Secret, as a cryptographically secure way to authenticate messages with respect to ad-hoc groups while still maintaining the signer's anonymity. While their initial scheme assumed the existence of random oracles, in 2005 a scheme was developed that does not use random oracles and meets the strongest security definitions known in the literature. We argue that this scheme is not deniable, meaning if someone signs a message with respect to a ring of possible signers, and at a later time the secret keys of all of the possible signers are confiscated (including the author), then the author's anonymity is no longer guaranteed. We propose a modification to the scheme that guarantees anonymity even in this situation, using a scheme that depends on ring signature users generating keys that do not distinguish them from other users who did not intend to participate in ring signature schemes, so that our scheme can truly be called a deniable ring signature scheme.
by Eitan Reich.
M.Eng.
57 p.
eng
Massachusetts Institute of Technology
M.I.T. theses are protected by
copyright. They may be viewed from this source for any purpose, but
reproduction or distribution in any format is prohibited without written
permission. See provided URL for inquiries about permission.
http://dspace.mit.edu/handle/1721.1/7582
Electrical Engineering and Computer Science.
Deniable Ring Signatures
Thesis
application/pdf
false
Publication
unknown
unknown
<Publication xmlns="https://www.openaire.eu/cerif-profile/1.1/" id="71712dcc-19a5-4373-b16e-b803d3d27684">
<Type xmlns="https://www.openaire.eu/cerif-profile/vocab/COAR_Publication_Types">http://purl.org/coar/resource_type/c_1843</Type>
<Language>eng</Language>
<Title>Deniable Ring Signatures</Title>
<PublishedIn>
<Publication>
</Publication>
</PublishedIn>
<PublicationDate>2007</PublicationDate>
<Authors>
<Author>
<DisplayName>Reich, Eitan</DisplayName>
<Affiliation>
<OrgUnit>
</OrgUnit>
</Affiliation>
</Author>
</Authors>
<Editors>
</Editors>
<Publishers>
<Publisher>
<DisplayName>Massachusetts Institute of Technology</DisplayName>
<OrgUnit />
</Publisher>
</Publishers>
<License>http://dspace.mit.edu/handle/1721.1/7582</License>
<Keyword>Electrical Engineering and Computer Science.</Keyword>
<Abstract>Ring Signatures were developed by Rivest, Shamir and Tauman, in a paper titled How to Leak a Secret, as a cryptographically secure way to authenticate messages with respect to ad-hoc groups while still maintaining the signer's anonymity. While their initial scheme assumed the existence of random oracles, in 2005 a scheme was developed that does not use random oracles and meets the strongest security definitions known in the literature. We argue that this scheme is not deniable, meaning if someone signs a message with respect to a ring of possible signers, and at a later time the secret keys of all of the possible signers are confiscated (including the author), then the author's anonymity is no longer guaranteed. We propose a modification to the scheme that guarantees anonymity even in this situation, using a scheme that depends on ring signature users generating keys that do not distinguish them from other users who did not intend to participate in ring signature schemes, so that our scheme can truly be called a deniable ring signature scheme.</Abstract>
<Access xmlns="http://purl.org/coar/access_right"
>
</Access>
</Publication>