summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorChristian Pointner <equinox@anytun.org>2009-04-09 20:39:52 +0000
committerChristian Pointner <equinox@anytun.org>2009-04-09 20:39:52 +0000
commit72c60ca29e5c0eaeb92bbc7810bce3945059e92f (patch)
treef9219ae949882f5dbc341f4f6b64b256ee82ae21
parentadded warning to options parser when mixing cluster and connection options (diff)
updated ChangeLog and Readme
fixed Typo at new draft<
-rw-r--r--ChangeLog26
-rw-r--r--README13
-rw-r--r--papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.xml2
3 files changed, 17 insertions, 24 deletions
diff --git a/ChangeLog b/ChangeLog
index a51df92..aafd8e4 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,16 +1,22 @@
-2008.12.23 -- Version 0.3_rc1_svn655
-* IMPORTANT: no automatic default route
- if you are using anytun in single connection mode
- (without configuration server)
- make sure to add
- route 0.0.0.0/0 for ipv4 and
- route ::/0 for ipv6 to your config
-* changed used libarys (to boost)
+2009.??.?? -- Version 0.3 svn???
+
+* updated to new protocol specification (extended label and crypto role)
+ Due to this changes this version is incompatible to version 0.2 and prior
+* the auth tag length can now be configured
+* added extended logging support (syslog, file stdout and stderr)
+* changed -n|--ifconfig parameter to new behavior
+ tun and tap devices now use the same syntax
+* added seperate resolver thread
+* fixed packet length errors
+* dropping privileges is now possible wihtout chroot
* full ipv6 support
- - ipv6 multible connection routing
+ - ipv6 multiple connection routing
- syncronisation over ipv6
- 4in6,6in6 tunnels
-* code cleanup for easier porting
+* replaced several dependencies with boost libs
+* ported basic functionality to Windows
+* dropped OpenBSD Port due to multi threading issues
+* code cleanup
2008.6.20 -- Version 0.2.1svn556
diff --git a/README b/README
index afa4c1f..b7168e2 100644
--- a/README
+++ b/README
@@ -48,18 +48,6 @@ Microsoft Visual C++ 2008 Redistributable Package (x86):
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF
-OpenBSD
--------
-
-using libgcrypt:
- libgcrypt
- libgpg-error
-
-common:
- boost
- gmake
-
-
Installation
============
@@ -89,7 +77,6 @@ Notes:
- if using openssl pre 0.9.8 you have to disable passphrase
because openssl had no SHA256 implementation prior to this
version
- - on OpenBSD you have to use gmake instead of make
Errors:
diff --git a/papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.xml b/papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.xml
index 46df7d0..a57f1b4 100644
--- a/papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.xml
+++ b/papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.xml
@@ -447,7 +447,7 @@ SATP uses two types of keys: master keys and session keys. A session key is mean
with PRF and x defined as in <xref target="sec_key_derivation" />.<vspace blankLines="1" />
Basically AES in counter mode generates a pseudo random keystream seeded by the session key, session salt as well as the sequence number, sender id and mux value of the packet and encrypts a single SATP packet using this stream. The encryption process consits of the generation of that keystream and then bitwise exclusive-oring it onto the packets payload. If the packet length doesn't fit a multiple of 128 bits the remaining bits (least significant) of the keystream are simple ingored. Therefore this transform does not need any padding. Decryption of the packet can be achieved by generating the same keystream and exclusive-oring it onto the encrypted portion.
</t>
- <section title="Keystram Generation">
+ <section title="Keystream Generation">
<t>
In principle AES in counter mode consists of encrypting an incrementing integer. However the starting point of the integer value has to be randomized to get a good pseudo random key stream. A keystream consits of several keystream segements with a size of 128 bits (AES blocksize). Each segement can be computed by applying AES with key k on the block CTR. The whole keystream is a concatination of all its successive segements. Therefore a keystream looks as follows:<vspace blankLines="1" />
AES(session_key, CTR) || AES(session_key, CTR + 1 mod 2^128) || AES(session_key, CTR + 2 mod 2^128) ...<vspace blankLines="1" />