') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); })(); ecdsa: add hazmat primitives; remove/reverse curve dependencies by tarcieri · Pull Request #96 · RustCrypto/signatures · GitHub
Skip to content

ecdsa: add hazmat primitives; remove/reverse curve dependencies - #96

Merged
tarcieri merged 1 commit into
masterfrom
ecdsa/hazmat-primitives
Jul 13, 2020
Merged

ecdsa: add hazmat primitives; remove/reverse curve dependencies#96
tarcieri merged 1 commit into
masterfrom
ecdsa/hazmat-primitives

Conversation

@tarcieri

@tarcieritarcieri commented Jul 12, 2020

Copy link
Copy Markdown
Member

Adds "hazmat" ECDSA signing and verification traits intended to be implemented by individual elliptic curve implementations:

  • SignPrimitive: intended to be implemented on Scalar
  • VerifyPrimitive: intended to be implemented on AffinePoint

The traits are generic over elliptic curves, allowing one type to potentially support multiple curves. This is potentially useful for things like FFI bindings to multi-curve libraries, or host libraries for hardware devices which support ECDSA signing for multiple elliptic curves.

These traits must be consumed directly by elliptic curve implementations, which means we need to reverse the current relationship where the ecdsa crate has optional features for k256, p256, and p384.

Instead, we can add an ecdsa feature to the k256, p256, and p384 crates which optionally pulls this crate in.

With the dependency relationship reversed, we can support an open ended number of elliptic curves including 3rd party non-RustCrypto implementations (as well as 3rd party ECDSA implementations ala aforementioned hardware tokens).

This allows the ecdsa crate to focus on only the high-level details of the ECDSA algorithm, like RFC 6979 deterministic signatures.

It also allows for wrapping complete ECDSA implementations, including assembly optimized ECDSA primitives or things like hardware accelerators.

@tarcieritarcieri changed the title ecdsa: add hazmat primitives; remove/reverse curve depsecdsa: add hazmat primitives; remove/reverse curve dependenciesJul 12, 2020
@tarcieri
tarcieriforce-pushed the ecdsa/hazmat-primitives branch 2 times, most recently from f8620cd to 3ed7d6dCompareJuly 12, 2020 02:37
@codecov-commenter

codecov-commenter commented Jul 12, 2020•
edited
Loading

Copy link
Copy Markdown

Codecov Report

Merging #96 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@ Coverage Diff @@## master #96 +/- ##
======================================
Coverage 0.00% 0.00% ======================================
Files 6 4 -2 Lines 209 179 -30 ======================================
+ Misses 209 179 -30
Impacted FilesCoverage Δ
ecdsa/src/asn1_signature.rs0.00% <ø> (ø)
ecdsa/src/convert.rs0.00% <ø> (ø)
ecdsa/src/fixed_signature.rs0.00% <ø> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9d8f4b6...9eb75b4. Read the comment docs.

This was referenced Jul 12, 2020
Closed
Closed
Closed
@tarcieri
tarcieriforce-pushed the ecdsa/hazmat-primitives branch from 3ed7d6d to a3aac91CompareJuly 12, 2020 02:49
@tarcieritarcieri mentioned this pull request Jul 12, 2020
Closed
@tarcieri
ecdsa: add hazmat primitives; remove/reverse curve deps
9eb75b4
Adds "hazmat" ECDSA signing and verification traits intended to be
implemented by individual elliptic curve implementations:
- `SignPrimitive`: intended to be implemented on `Scalar`
- `VerifyPrimitive`: intended to be implemented on `AffinePoint`
The traits are generic over elliptic curves, allowing one type to
potentially support multiple curves. This is potentially useful for
things like FFI bindings to multi-curve libraries, or host libraries for
hardware devices which support ECDSA signing for multiple elliptic
curves.
These traits must be consumed directly by elliptic curve
implementations, which means we need to reverse the current relationship
where the `ecdsa` crate has optional features for `k256`, `p256`, and
`p384`.
Instead, we can add an `ecdsa` feature to the `k256`, `p256`, and `p384`
crates which optionally pulls this crate in.
With the dependency relationship reversed, we can support an open ended
number of elliptic curves including 3rd party non-RustCrypto
implementations (as well as 3rd party ECDSA implementations ala
afforementioned hardware tokens).
This allows the `ecdsa` crate to focus on only the high-level details of
the ECDSA algorithm, like RFC 6979 deterministic signatures.
It also allows for wrapping complete ECDSA implementations, including
assembly optimized ECDSA primitives or things like hardware
accelerators.
@tarcieri
tarcieriforce-pushed the ecdsa/hazmat-primitives branch from a3aac91 to 9eb75b4CompareJuly 13, 2020 14:05
@tarcieri
tarcieri merged commit 30390b3 into masterJul 13, 2020
@tarcieri
tarcieri deleted the ecdsa/hazmat-primitives branch July 13, 2020 14:33
tarcieri added a commit to RustCrypto/elliptic-curves that referenced this pull request Jul 14, 2020
@tarcieri
ECDSA types
ffbf284
The equivalents of these types used to live in the `ecdsa` crate, but
were removed in this PR:
RustCrypto/signatures#96
The goal of that PR was to reverse the previous relationship where the
`ecdsa` crate depended on the `k256`/`p256`/`p384` crates, and instead
have the curve implementation crates consume the `ecdsa` crate as an
(optional) dependency.
It makes each curve implementation a one-stop-shop for everything
related to that curve, while allowing the ECDSA crate to provide some
common functionality like ASN.1 (de)serialization, in addition to
allowing it to export "primitive" traits which can be used with the
goal of a reusable high-level ECDSA implementation which is generic over
elliptic curves.
This commit ports over equivalent types that were removed in
`RustCrypto/signatures#96`, but also incorporates these changes:
RustCrypto/signatures#98
Where the `ecdsa` crate previously had `Asn1Signature` and
`FixedSignature` types generic over a curve, the PR above refactored it
to make the "fixed" form the preferred `Signature` type, and refactoring
ASN.1 DER support into an `ecdsa::asn1::Document` type.
The nice advantage of that approach is it means the curve
implementations no longer need to worry about an `Asn1Signature` type
and can focus on `ecdsa::Signature` as the type they need to support.
tarcieri added a commit to RustCrypto/elliptic-curves that referenced this pull request Jul 14, 2020
@tarcieri
ECDSA types (#73)
2adf766
The equivalents of these types used to live in the `ecdsa` crate, but
were removed in this PR:
RustCrypto/signatures#96
The goal of that PR was to reverse the previous relationship where the
`ecdsa` crate depended on the `k256`/`p256`/`p384` crates, and instead
have the curve implementation crates consume the `ecdsa` crate as an
(optional) dependency.
It makes each curve implementation a one-stop-shop for everything
related to that curve, while allowing the ECDSA crate to provide some
common functionality like ASN.1 (de)serialization, in addition to
allowing it to export "primitive" traits which can be used with the
goal of a reusable high-level ECDSA implementation which is generic over
elliptic curves.
This commit ports over equivalent types that were removed in
`RustCrypto/signatures#96`, but also incorporates these changes:
RustCrypto/signatures#98
Where the `ecdsa` crate previously had `Asn1Signature` and
`FixedSignature` types generic over a curve, the PR above refactored it
to make the "fixed" form the preferred `Signature` type, and refactoring
ASN.1 DER support into an `ecdsa::asn1::Document` type.
The nice advantage of that approach is it means the curve
implementations no longer need to worry about an `Asn1Signature` type
and can focus on `ecdsa::Signature` as the type they need to support.
@tarcieritarcieri mentioned this pull request Aug 11, 2020
Merged
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@tarcieri@codecov-commenter