aboutsummaryrefslogtreecommitdiff
path: root/contrib/pgcrypto/pgp-mpi-openssl.c
diff options
context:
space:
mode:
Diffstat (limited to 'contrib/pgcrypto/pgp-mpi-openssl.c')
-rw-r--r--contrib/pgcrypto/pgp-mpi-openssl.c6
1 files changed, 3 insertions, 3 deletions
diff --git a/contrib/pgcrypto/pgp-mpi-openssl.c b/contrib/pgcrypto/pgp-mpi-openssl.c
index 24484a6c54e..afece269186 100644
--- a/contrib/pgcrypto/pgp-mpi-openssl.c
+++ b/contrib/pgcrypto/pgp-mpi-openssl.c
@@ -74,7 +74,7 @@ bn_to_mpi(BIGNUM *bn)
}
/*
- * Decide the number of bits in the random componont k
+ * Decide the number of bits in the random component k
*
* It should be in the same range as p for signing (which
* is deprecated), but can be much smaller for encrypting.
@@ -82,8 +82,8 @@ bn_to_mpi(BIGNUM *bn)
* Until I research it further, I just mimic gpg behaviour.
* It has a special mapping table, for values <= 5120,
* above that it uses 'arbitrary high number'. Following
- * algorihm hovers 10-70 bits above gpg values. And for
- * larger p, it uses gpg's algorihm.
+ * algorithm hovers 10-70 bits above gpg values. And for
+ * larger p, it uses gpg's algorithm.
*
* The point is - if k gets large, encryption will be
* really slow. It does not matter for decryption.