improve grammar for all articles

content/posts/bidirectional-totp/index.md

@@ -10,10 +10,10 @@ Image sourced from [Wikimedia](https://commons.wikimedia.org/wiki/File:Berlin_-_
 attributed according to the Creative Commons Attribution 2.0 Generic license.
 
 ## Motivation
-Time-Based One Time Password (TOTP) authentication is extremely beneficial.
+Time-Based One-Time Password (TOTP) authentication is extremely beneficial.
 It lets you quickly add two‑factor authentication (2FA) to online accounts according
 to a simple and open standard. Simply scan a QR code into a TOTP app like [Aegis](https://github.com/beemdevelopment/Aegis).
-As long as you have access to your phone, you can then use the TOTP app to generate 2FA codes whenever need be.
+As long as you have access to your phone, you can then use the TOTP app to generate 2FA codes as needed.
 No risk of [SIM swapping](https://en.wikipedia.org/wiki/SIM_swap_scam), no need for SMS reception or a phone number, and no need for proprietary 2FA apps.
 
 **But TOTP as it's currently widely implemented has a shortcoming; it doesn't prevent phishing attacks.**
@@ -30,9 +30,9 @@ Existing TOTP implementations *don't* authenticate websites to users (think "I'm
 ## Bi-Directional Alternative
 Imagine the scenario where, in addition to asking you for your TOTP code (let's call this `z`), a website also provided you with its own TOTP code (let's call this `z'`).
 Within your authenticator app, you'd select the desired website from a list of stored websites.
-But rather than being shown a TOTP code right away (`z`), you'd be prompted for the TOTP code provided from the website (`z'`).
+But rather than being shown a TOTP code right away (`z`), you'd be prompted for the TOTP code provided by the website (`z'`).
 
-If the website is a phishing website, they can't produce valid TOTP codes `z` or `z'`.
+If the website is a phishing website, it can't produce valid TOTP codes `z` or `z'`.
 Your authenticator app would check that the TOTP code provided by the website (`z'`) is valid.
 The legitimate website would check that the TOTP code provided by your authenticator app (`z`) is valid.
 
@@ -80,7 +80,7 @@ Rather than generate a new key `k'` just for website-to-client authentication, i
 For example, implementations could use a [key derivation function](https://en.wikipedia.org/wiki/Key_derivation_function)
 such as Argon2 or PBKDF2, taking as inputs `K` and some salt which is fixed for the protocol.
 
-The biggest advantages to this approach is that it negates the need for network transmission of `k'` upon enrollment.
+The advantage to this approach is that it negates the need for network transmission of `k'` upon enrollment.
 It also allows for finer-grained time/value tradeoffs to be made regarding when `k'` is derived and stored.
 The drawback is added complexity and an increased implementation attack surface.
 
@@ -95,7 +95,7 @@ TOTP limits accessibility by using short timeouts (30 seconds by default).
 Adding a second code implies a twofold increase in the amount of time required by a user to authenticate to a service.
 Further, TOTP codes aren't intuitive to a non-technical audience. In my opinion, this is evidenced by a lack of wider adoption. Adding a second code to the mix only increases the potential for confusion.
 
-I understand the absence of a widely-implemented bi-directional TOTP standard in light of these constraints.
+I understand the absence of a widely implemented bi-directional TOTP standard in light of these constraints.
 
 
 ## Appendix: Phishing vs TOTP Timeouts

content/posts/cleveland-air-show/index.md

@@ -11,7 +11,7 @@ The Cleveland Air Show[^1][^2] sucks.
 - The Cleveland Air Show causes noise pollution
 - The Cleveland Air Show causes air pollution
 
-**Labor Day weekend should be a celebration of the labor movement and workers rights, not a jingoistic endorsement of the military industrial complex.** Why should people across Greater Cleveland put up with the sound of fighter jets buzzing their homes and workplaces?
+**Labor Day weekend should be a celebration of the labor movement and workers rights, not a jingoistic endorsement of the military-industrial complex.** Why should people across Greater Cleveland put up with the sound of fighter jets buzzing their homes and workplaces?
 It's not just on Labor Day itself, either. The exercises start several days in advance.
 And the organizers have the audacity to charge admittance!
 
@@ -20,4 +20,4 @@ The Cleveland Air Show sucks.
 References
 
 [^1]: Cleveland Air Show (Sep 3, 2023). ["Cleveland Air Show"](https://www.clevelandairshow.com/). Cleveland Air Show. [Archived](https://web.archive.org/web/20230903013215/https://www.clevelandairshow.com/) from the original on September 3, 2023. Retrieved September 3, 2023.  
-[^2]: Cleveland Air Show Sponsors (Sep 3, 2023). ["Cleveland Air Show Sponsors"](https://www.clevelandairshow.com/partners/sponsors/). Cleveland Air Show Sponsors. [Archived](https://web.archive.org/web/20230323213435/https://www.clevelandairshow.com/partners/sponsors/) from the original on March 23, 2023. Retrieved September 3, 2023.  
+[^2]: Cleveland Air Show Sponsors (Sep 3, 2023). ["Cleveland Air Show Sponsors"](https://www.clevelandairshow.com/partners/sponsors/). Cleveland Air Show Sponsors. [Archived](https://web.archive.org/web/20230323213435/https://www.clevelandairshow.com/partners/sponsors/) from the original on March 23, 2023. Retrieved September 3, 2023.  

content/posts/dnssec/index.md

@@ -28,10 +28,10 @@ The textual representation of ECDSA public keys depends partially on whether it
 
 The field size of NIST P-256 is 256 bits, or 32 bytes. An uncompressed ECDSA public key consists of an x and y‑coordinate, and since each coordinate is a field element (i.e., for NIST P-256, is at most 32 bytes in length), an ECDSA public key for Curve P-256 requires 64 bytes, not including a prefix. When the (well-known) prefix 0x04 is prepended, the total length is 65 bytes. 
 
-The prefix is used to quickly differentiate between uncompressed (0x04) and compressed (0x02, 0x03) form. Compressed form takes advantage of the property that the y‑coordinate of an ECDSA public key can be unambiguously derived given the curve equation, x‑coordinate, and a odd-even flag (prefix).  Solving the curve equation for y given x yields two possible values for y. One solution is always even, one solution is always odd. By prefixing the compressed form with a well-known byte (0x02 for even, 0x03 for odd), the public key can be unambiguously specified with a total of $$32+1=33$$ bytes.
+The prefix is used to quickly differentiate between uncompressed (0x04) and compressed (0x02, 0x03) forms. The compressed form takes advantage of the property that the y‑coordinate of an ECDSA public key can be unambiguously derived given the curve equation, x‑coordinate, and an odd-even flag (prefix).  Solving the curve equation for y given x yields two possible values for y. One solution is always even, one solution is always odd. By prefixing the compressed form with a well-known byte (0x02 for even, 0x03 for odd), the public key can be unambiguously specified with a total of $$32+1=33$$ bytes.
 
 ## ECDSA Key Format for DNSKEY
-When used in DNSKEY records, ECDSA public keys are given in uncompressed form. References to some of the relevant RFCs are given below. Practically, this means that the DNSSEC public keys for juniperspring.xyz should each be $32*2=64$ bytes long when no prefix is used. These keys are always *exactly* 64 bytes long, probably because the RFCs strictly specify uncompressed form (i.e, a prefix would be redundant) and because small DNS records are desirable.
+When used in DNSKEY records, ECDSA public keys are given in uncompressed form. References to some of the relevant RFCs are given below. Practically, this means that the DNSSEC public keys for juniperspring.xyz should each be $32*2=64$ bytes long when no prefix is used. These keys are always *exactly* 64 bytes long, probably because the RFCs strictly specify uncompressed form (i.e., a prefix would be redundant) and because small DNS records are desirable.
 
 The RFC on DNSSEC records (RFC4034[^4]) describes the DNSKEY Public Key Field briefly:
 > The Public Key Field holds the public key material. The format depends on the algorithm of the key being stored and is described in separate documents.
@@ -56,13 +56,13 @@ let b64ToHex = (b64) => [...atob(b64)].map(c=> c.charCodeAt(0).toString(16).padS
 b64ToHex(zsk) // '4868e18e47cf51d925fa53085528749bf54150bbfc77369c1232e2f05f729280930f11583cc410a58bfe98e3e410c75b16ea12d75b999fb8228c8e1dfc130c8f'
 b64ToHex(ksk) // '4f8dbc3d5bc1daea8983535a51712887ef65b758dbc31d43aaabb585a779729ed1e3c34488671366583cfb07730ed9d0ac9a2c33ed86f1f0abc67289c58349a1'
 ```
-Each of the resulting hex strings are 128 chars (64 bytes) long and do not contain a 0x04 prefix byte, consistent with the format of uncompressed ECDSA P-256 public keys.
+Each of the resulting hex strings is 128 chars (64 bytes) long and does not contain a 0x04 prefix byte, consistent with the format of uncompressed ECDSA P-256 public keys.
 
 ## DNSSEC and Namecheap
 At the time of writing, the juniperspring.xyz domain is provided by Namecheap.
 The Namecheap web interface provides a toggle for enabling DNSSEC for the domain (DNSSEC is disabled by default).
 ![DNSSEC in the Namecheap management interface](namecheap-dnssec.png)
-Apparently, Namecheap uses `ECDSAP256SHA256` as the signature algorithm by default, generates the requisite key pairs, and (I assume) stores the private keys on Namecheap's servers. You can check the resulting DNSSEC records with an online tool provided by Verisign Labs[^6].
+Empirically, Namecheap uses `ECDSAP256SHA256` as the signature algorithm by default, generates the requisite key pairs, and (I assume) stores the private keys on Namecheap's servers. You can check the resulting DNSSEC records with an online tool provided by Verisign Labs[^6].
 
 ## On the Ethereum DNSSEC Oracle
 Having a working knowledge of DNS and DNSSEC enables a better understanding of the Ethereum Name Service (ENS)[^7] and the Ethereum DNS Oracle[^8]. Submitting a proof to the DNSSEC oracle is significantly more expensive (multiple times the cost of purchasing juniperspring.eth for four years) than purchasing a `.eth` domain.

content/posts/ethereum-name-service/index.md

@@ -9,7 +9,7 @@ You can view the entry through the ENS web app: https://app.ens.domains/junipers
 
 If you enjoy my blog and/or want to support my work, feel free to send ether to `juniperspring.eth`. If you're using a modern (as of 2023) Ethereum wallet, you should be able to specify `juniperspring.eth` directly in the address field. Any ether will (legally I should say *probably will*) go toward enabling me to continue participating in open source, collaborative, and freely-licensed work.
 
-The ENS entry expires June 6, 2027. Hopefully I have reason to update it before then 🙂
+The ENS entry expires on June 6, 2027. Hopefully I have reason to update it before then 🙂
 
 ~ Eric 🌱❤️
 

content/posts/locked-out-of-keybase/index.md

@@ -18,7 +18,7 @@ keybase account lockdown
 keybase logout
 ```
 
-Apparently those are bad commands to run when you've revoked all other devices and forgot your Keybase password. I still have keys for one of my devices, but AFAIK they're encrypted with some secret derived from my Keybase password.
+Apparently, those are bad commands to run when you've revoked all other devices and forgot your Keybase password. I still have keys for one of my devices, but AFAIK they're encrypted with some secret derived from my Keybase password.
 
 juniperspring is digitally stateless now 😔⛵
 unmoored and untethered from Keybase, my account lives on in Merkle forest hashes,
@@ -28,4 +28,4 @@ floating among memos on the Stellar chain
 Missing me one place search another,  
 I stop somewhere waiting for you.  
 
-— Walt Whitman 🌱
+— Walt Whitman 🌱