Repository navigation
Bad hyperlink, typos, possible small errors in "Introduction to Java Encryption/Decryption" tutorial ( https://dev.java/learn/security/intro/ ) #262
Description
Activity
(Noting the example ciphertext I gave
bbe01eb98d135368893d8c5d4a33f98dis only to illustrate the format; the actual ciphertext will vary each run due to random key and other randomness. Same with the expected byte[].toString() output I gave,[B@421faab1(fromObject.toString(): getClass().getName() + '@' + Integer.toHexString(hashCode()) which is the format that the code the dev.java team has currently provided would show for the ciphertext in the symmetric encryption example (which appears unintentional). I am suggesting the full ciphertext hex format consistent with later examples be used again, not that the specific result numbers should be the preceding.)Forgot to post here, but I pushed a fix 3 weeks ago.
Thanks for fixing the items reported above!
Here are some other items that may be of interest (or not) to update:
In the latest version of https://dev.java/learn/security/intro/ (archived as is at https://megalodon.jp/2026-0809-0522-46/https://dev.java:443/learn/security/intro (web.archive.org is not succeeding at archiving the current version of this particular page, so using megalodon this time))
-
In the text block
Register the provider either:
- Statically by modifying the conf/security/java.security configuration file, e.g. security.provider.5=SunJCEII. Be aware that in JDK 8 the java.security file is in java.home/lib/security/java.security.
- Dynamically by invoking Security.addProvider(java.security.Provider) and Security.insertProviderAt(java.security.Provider,int).
It may be worth mentioning that the
conf/security/java.securityfile mentioned does not need to be directly modified;
by default (unlesssecurity.overridePropertiesFileis set to false),
as one can specify-Djava.security.properties=<URL>to specify an additional security properties file which can append to the original ( https://docs.oracle.com/en/java/javase/26/security/security-properties-file.html#GUID-2578FE1D-AA9C-46E6-9B56-410EFB2F6AB4 ) -
In the line of example code
IO.println("Verification: " + verify(plainText.getBytes(), digitalSignature, keypair.getPublic()));"Verification: " should probably be "Verified: " (as "Verified: true/false" is meaningful whereas "Verification" is always attempted whether the verification would succeed or not), though this is less important than the previous change to say "sign" instead of "encrypt" for the digital signature demo.
-
In the text
how you can implement basic encryption and decryption mechanisms using Java Security API.
"using Java Security API" might be more grammatical as "using the Java Security API".
-
In the text
Among those standards are:
- TLS (Transport Layer Security) v1.2, v1.3 – RFC 5246, RFC 8446
- RSA Cryptography Specifications PKCS Request: Sample Requested Issue #1 – RFC 8017
- Cryptographic Token Interface Standard (PKCS#11)
- The ECDSA signature algorithms as defined in ANSI X9.62, etc.
It may be useful to update just the line
Cryptographic Token Interface Standard (PKCS#11)
to link to https://www.cryptsoft.com/pkcs11doc/ which is an authoritative page linking to all versions of that standard (the standard originated at cryptosoft.com (archived as is at https://web.archive.org/web/20260807020719/https://www.cryptsoft.com/pkcs11doc/ ), with recent versions being maintained at oasis-open.org but the cryptosoft.com page has the easiest navigation and is the version linked in many places).
This would make this entry consistent with the other standards described which ALL have links.
Thanks so much!
-
Hello dev.java team!
Thanks again for all this excellent content. To contribute back, I am reporting the typos/bad hyperlinks and other such issues I have found as usual.
In the latest version of https://dev.java/learn/security/intro/ (archived as is at https://web.archive.org/web/20260712074541/https://dev.java/learn/security/intro/ )
In the sentence
"SecureRandom" links to https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/security/KeyPairGenerator.html ,
when it should instead link to https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/security/SecureRandom.html .
In the sentences
"Asymmetrical encryption" should probably be "asymmetric encryption" (the latter is the typical term and compare to e.g. Oracle's upstream documentation at https://docs.oracle.com/en/java/javase/26/security/java-security-overview1.html#:~:text=Asymmetric%20encryption ),
"mathematical related keys" should be "mathematically related keys",
and "In the example bellow" should be "In the example below" ("bellow" should be "below").
In the "Implementing Basic Asymmetric Encryption/Decryption" example,
Was the method "generateRSAKKeyPair" intended to be "generateRSAKeyPair"?
(the "KKey" instead of "Key" seems unintentional)
In the sentence
"Electronic handling contracts" may have been intended to be "Electronically handling contracts".
In the sentence
"algorithms publicly available" is a less common phrasing than "publicly available algorithms",
and the meaning of "control to the data" may be unclear.
Just a humble suggestion, but it may be useful to invoke a named principle here so that readers who are not familiar can do additional research as necessary, by quoting
"Kerckhoffs's principle [...which] holds that a cryptosystem should be secure, even if everything about the system, except the key, is public knowledge." ( https://en.wikipedia.org/w/index.php?title=Kerckhoffs%27s_principle&oldid=1361573367 ).
In the sentence
"map an arbitrary sized set of bytes into a finite size of a relatively unique set of bytes" should probably be "map an arbitrarily large input data byte sequence to a fixed length, relatively unique, output byte sequence"
or something similar as the inputs/outputs are not set-typed.
In the sentence
When using the term initialization vector, it seems this might be clearer if moved up to the paragraph on encryption/decryption, and instead of being mentioned later at the end of the paragraph on hashing, as
https://docs.oracle.com/en/java/javase/26/docs/api/java.base/javax/crypto/Cipher.html#init(int,java.security.Key,java.security.AlgorithmParameters) , https://docs.oracle.com/en/java/javase/26/docs/api/java.base/javax/crypto/spec/IvParameterSpec.html are used to initialize Cipher ( https://docs.oracle.com/en/java/javase/26/docs/api/java.base/javax/crypto/Cipher.html ) , NOT MessageDigest ( https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/security/MessageDigest.html) to my understanding. Maybe if this was moved up to the paragraph on encryption/decryption, then when mentioning the use of "salt" for hashing in this subsequent paragraph salt can be noted as analogous to the use of the initialization vector with encryption/decryption to maintain the existing connection between the concepts.
In the symmetric cryptography example, the encrypted ciphertext is printed by using byte[] toString:
which produces output like
[B@421faab1(from Object.toString():getClass().getName() + '@' + Integer.toHexString(hashCode())).It would be more useful to actually show the encrypted String data, not its hashcode, and that is what is done in the subsequent example.
Thus the IO.println above should probably be replaced with:
(this would also be consistent with how ciphertext is printed in later examples)
which would print the full ciphertext hex-encoded as "bbe01eb98d135368893d8c5d4a33f98d" .
In the text
"asymmetrical encryption" was probably intended to be "asymmetric encryption" (the latter is the typical term and compare to e.g. Oracle's upstream documentation at https://docs.oracle.com/en/java/javase/26/security/java-security-overview1.html#:~:text=Asymmetric%20encryption )
(Nit, optional) In the sentence
"agnostic from security providers" might be clearer as "agnostic about security providers" ("agnostic about" is the much more frequent phrasing).
In the code example demonstrating digital signatures
the example seems to be incomplete, unlike the prior examples, as keypair and plainText are undeclared.
Since the prior examples all are compilable (provided one puts all the snippets for a given example into an enclosing class and imports the referenced classes),
I suspect the omitted declarations here were unintentional. The full main method could be updated as follows for a complete copy-pasteable example (when combined with other snippets provided):
Thanks very much!