diff --git a/Crypto/thoughts.txt b/Crypto/thoughts.txt
new file mode 100644
index 0000000..235cb39
--- /dev/null
+++ b/Crypto/thoughts.txt
@@ -0,0 +1,31 @@
+
+timing resistence
+
+In crypto there is a concept of side channels which are ways in which crypto can be weakened
+A side channel is some additional or implicit means to gain more data than what is evident
+in the raw data. For example when communicating between a client and server, there is the
+raw data going through the communication channel, but there is some additional implicit
+information that can imply something about the state of the server by the time between
+data. An attacker could deduce some information about the key being used by the server
+based on the time it takes to encrypt various data. This could reduce the strength of the
+crypto being used. The approximate magnitude of the modulus or exponent could be inferred
+for example because it could be known the relative amount of time certain operations take
+for various magnitudes of these for various data.
+
+So some crypto implementations attempt to avoid certain types of optimizations and aim more
+for a fixed amount of time etc.
+
+That is fine if the fixed time algorithm will not be any slower than the slowest running
+time of an optimized implementation. If it is, it may just be better to use an optimized
+implementation, save on the CPU time and running cost of the server, and just delay
+delivery of the response to the client.
+
+If the case is not a client-server over a network, it is still possible to on the same
+machine with IPC to make a program start a process it communicates to as if it were in a
+client-server setup.
+
+Probably worth adding in some non-deterministic timing delays too, just to make it harder
+for an attacker. How hard can that be rather than slowing down and using up more CPU
+resources.
+
+

diff --git a/Crypto/thoughts.txt b/Crypto/thoughts.txt
new file mode 100644
index 0000000..235cb39
--- /dev/null
+++ b/Crypto/thoughts.txt
@@ -0,0 +1,31 @@
+
+timing resistence
+
+In crypto there is a concept of side channels which are ways in which crypto can be weakened
+A side channel is some additional or implicit means to gain more data than what is evident
+in the raw data. For example when communicating between a client and server, there is the
+raw data going through the communication channel, but there is some additional implicit
+information that can imply something about the state of the server by the time between
+data. An attacker could deduce some information about the key being used by the server
+based on the time it takes to encrypt various data. This could reduce the strength of the
+crypto being used. The approximate magnitude of the modulus or exponent could be inferred
+for example because it could be known the relative amount of time certain operations take
+for various magnitudes of these for various data.
+
+So some crypto implementations attempt to avoid certain types of optimizations and aim more
+for a fixed amount of time etc.
+
+That is fine if the fixed time algorithm will not be any slower than the slowest running
+time of an optimized implementation. If it is, it may just be better to use an optimized
+implementation, save on the CPU time and running cost of the server, and just delay
+delivery of the response to the client.
+
+If the case is not a client-server over a network, it is still possible to on the same
+machine with IPC to make a program start a process it communicates to as if it were in a
+client-server setup.
+
+Probably worth adding in some non-deterministic timing delays too, just to make it harder
+for an attacker. How hard can that be rather than slowing down and using up more CPU
+resources.
+
+
diff --git a/Crypto/todo.txt b/Crypto/todo.txt
new file mode 100644
index 0000000..f6d7b52
--- /dev/null
+++ b/Crypto/todo.txt
@@ -0,0 +1,10 @@
+
+
+ASN1 probably needs to move from Crypto -> Serializing
+
+The tests moved to Tests
+
+
+
+
+