# HG changeset patch
# User Mychaela Falconia <falcon@freecalypso.org>
# Date 1613960383 0
# Node ID b6331ae4eea920d001132d67735c9f5a12c145e1
# Parent  08e6c475e55936c365ec4257acbc6f9f934a91a5
Note-about-padding added

diff -r 08e6c475e559 -r b6331ae4eea9 Note-about-padding
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Note-about-padding	Mon Feb 22 02:19:43 2021 +0000
@@ -0,0 +1,33 @@
+The complex logic in smswrap/ota-smswrap-sjs1.c for getting the secured message
+into just the right format to be accepted by the card has been copied from
+Osmocom Python program shadysim.py - that Python code appears to be the only
+existing reference for using the RFM feature of Sysmocom SIM cards.  However,
+in the process of studying that code and extracting the logic from it, I found
+what appeared to be a bug in their code and logic, and sure enough, further
+investigation has confirmed it to be a bug indeed, a bug that is tolerated by
+sysmoUSIM-SJS1 cards, but not the newer sysmoISIM-SJA2 - hence the test_rfm
+function of that Python tool does not work on the new cards.
+
+When the application message payload is encrypted with any variant of DES
+(including the two-key 3DES used on Sysmocom SIMs), the length of the ciphertext
+has to be a multiple of 8 bytes - hence if the plaintext length is not a
+multiple of 8 bytes, the plaintext needs to be padded.  But what should happen
+if the plaintext length going into the cipher just happens to be a perfect
+multiple of 8 bytes?  The correct answer (ought to be obvious) is to apply no
+padding at all, i.e., zero bytes of padding.  However, the Python code in
+shadysim.py adds 8 bytes of padding, and sets the number of padding bytes in the
+header to 8.  The resulting encrypted message should be considered malformed per
+standard specs, but sysmoUSIM-SJS1 cards are liberal in what they accept in this
+instance, thus the bug went unnoticed.  The newer sysmoISIM-SJA2 cards do not
+accept such malformed messages with invalid padding, and it just so happens that
+the message generated by the test_rfm function has 40 bytes of plaintext going
+into the cipher, perfectly divisible by 8 - hence their test_rfm function fails
+on the new cards.
+
+Our ota-smswrap-sjs1 program accepts an optional third argument after the two
+key arguments, selecting the padding mode.  The default mode is correct padding;
+if the extra padding mode argument is set to 1, our tool replicates the bogus
+behaviour of the reference Python code.  This bug-compatible mode has been
+implemented to make sure that we can generate the exact same packet starting
+with data/shadysim-rfm-test (verifying that we have copied the logic correctly),
+but it should not be used further beyond these debugging tests.