chore: fix some minor issues in comments

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].

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<S,T>`
 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.
 

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<T>`, and keys that can be wrapped would have methods for
 creating these options with different encapsulated key-formats.

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).
 #