diff --git a/README.md b/README.md index 373d7fde..43fc5765 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -Cross-Platform Web Cryptography Implemenation +Cross-Platform Web Cryptography Implementation ============================================= This package provides a cross-platform implementation of the [Web Cryptograph API][webcrypto-spec]. diff --git a/doc/design-rationale.md b/doc/design-rationale.md index abf990fe..5c71a198 100644 --- a/doc/design-rationale.md +++ b/doc/design-rationale.md @@ -24,7 +24,7 @@ cryptography implementation. This option comes with significant draw backs: * Custom implementations of cryptographic algorithms requires domain experts and extensive security reviews. * A Javascript implementation is unlikely to achieve performance comparable to - the native crytography algorithms shipped with the browser. + the native cryptography algorithms shipped with the browser. * A Javascript implementation would need to use WebWorker to off-load computation from the main-thread, while the browsers native implementation can do this for free. @@ -38,7 +38,7 @@ for golang, this package will not provide low-level access to underlying primitives. However, most Dart developers are also unlikely to need such advanced features for using a modern Web API. -Crytography is not simple, and should not be simplfied +Cryptography is not simple, and should not be simplified ------------------------------------------------------ This isn't entirely true of course, cryptography isn't so hard _if_ you know what you're doing. If you don't know what you're doing, then you shouldn't be @@ -74,7 +74,7 @@ This does not follow `package:crypto` by implementing `Converter` because `convert()` cannot be asynchronous as required by WebCrypto. Besides users (hint Flutter) would likely prefer to avoid heavy computations -like crypto on the main-thread. Even if an initial implemention doesn't move +like crypto on the main-thread. Even if an initial implementation doesn't move computation off-the-mainthread, it would be preferable to keep the option open by returning futures. diff --git a/doc/webcrypto-parity.md b/doc/webcrypto-parity.md index e1a3f359..aba5ed90 100644 --- a/doc/webcrypto-parity.md +++ b/doc/webcrypto-parity.md @@ -33,7 +33,7 @@ developers to harden their applications against accidental misuse of keys. If we wanted to support this feature we would introduce a `KeyUsages` enum, and allow all key import and generation methods to accept a set of usages, as well -as an `extractable` bit. Various key opertions would then throw +as an `extractable` bit. Various key operations would then throw `UnsupportedError` if the key capabilities is violated. This is not an unreasonable API design. However, this feature can also be @@ -102,7 +102,7 @@ This also equivalent to decrypting the key and then importing the key. Similar to `deriveKey` this is useful when limiting a key to specific usages to prevent a key from accidentally being misused. If we wanted to support this -feature we would also be introducing intermediate objets similar to the design +feature we would also be introducing intermediate objects similar to the design outlined for `deriveKey`. Instead these would be `WrapKeyOptions` and `UnwrapKeyOptions`, and keys that can be wrapped would have methods for creating these options with different encapsulated key-formats. diff --git a/src/symbols.yaml b/src/symbols.yaml index 99a138c8..db96c5ac 100644 --- a/src/symbols.yaml +++ b/src/symbols.yaml @@ -24,7 +24,7 @@ # or OpenSSL that might be linked into the final application, because we only # expose the `webcrypto_lookup_symbol` symbol. # -# On most platforms, like Android, the the BoringSSL sources and `webcrypto.c` +# On most platforms, like Android, the BoringSSL sources and `webcrypto.c` # is compiled to a dynamic library `webcrypto.so`, in this case symbol conflicts # is unlikely (if loaded correctly). #