Since plaintext/unencrypted keys do not have a cipher or KDF (as there's no encryption key or algorithm used), they use the string "none" to identify these (and entirely leave out the KDF options).
====
[id=struct_ed25519_plain]
====== Structure
[source,text,linenums]
----
0.0 "openssh-key-v1" string plus terminating nullbyte (15 bytes)
4.0.1.0 uint32 decryption "checksum" #1 (should match 4.0.1.1) (4 bytes)
4.0.1.1 uint32 decryption "checksum" #2 (should match 4.0.1.0) (4 bytes)
4.0.1.2 Copy of 4.0.0.0; allocator for 4.0.1.2.0 (4 bytes)
4.0.1.2.0 Copy of 4.0.0.0.0 (ASCII bytes)
4.0.1.3 Copy of 4.0.0.1; allocator for 4.0.1.3.0 (4 bytes)
4.0.1.3.0 Copy of 4.0.0.1.0 (bytes)
4.0.1.4 uint32 allocator for 4.0.1.4.0 (4 bytes)
4.0.1.4.0 Private key #n (bytes)
4.0.1.5 uint32 allocator for 4.0.1.5.0 (4 bytes)
4.0.1.5.0 comment for key #n string (ASCII bytes)
4.0.1.6 sequential padding
----
[NOTE]
====
*Chunk 3.0.0 to 3.0.1:* These blocks are not present in unencrypted keys (see the <<struct_ed25519_crypt, encrypted key structure>> for what these look like). *3.0* reflects this, as it's always going to be `00000000` (0).
*Chunk 4.0:* This is technically currently unused; upstream hardcodes to 1 (left zero-padded `0x01`).
*Chunk 4.0.1.4.0:* This is a 64-byte block for ED25519, but the second half of the private key (`[32:]`) is always the same as the public key.
*Chunk 4.0.1.6:* The padding used aligns the private key (*4.0.1.0* to *4.0.1.5.0*) to the cipher blocksize. For plaintext keys, a blocksize of 8 is used.
