diff options
| author | SoniEx2 <endermoneymod@gmail.com> | 2018-09-14 02:42:25 -0300 |
|---|---|---|
| committer | SoniEx2 <endermoneymod@gmail.com> | 2018-09-14 02:42:25 -0300 |
| commit | 791ab635f6558c2ec67570265ef9cffb457f9af3 (patch) | |
| tree | d12f9979524793023b9fe96fabb6df5cf7a3f174 | |
Initial commit. Add all known versions of newclog.
Version 0 is the latest.
Version -1 is the second latest.
Version -2 is the third latest.
Versions -3 and back, I didn't manage to recover.
| -rw-r--r-- | v-1 | 94 | ||||
| -rw-r--r-- | v-2 | 77 | ||||
| -rw-r--r-- | v0 | 102 |
3 files changed, 273 insertions, 0 deletions
@@ -0,0 +1,94 @@ +CAP prefix/clog
+===============
+
+Copyright (c) Soni L. \<fakedme plus irkv3 at gmail dot com>
+
+This capability provides a mechanism for identifying and conveying a cryptographically secured list of messages to IRC clients.
+
+This specification also suggests a mechanism by which IRC clients can sync logs, using the information provided by this capability.
+
+Cap syntax
+----------
+
+The capability shall be specified as
+
+ prefix/clog=hash_type,hash_type/tag,tag,tag
+
+Example:
+
+ prefix/clog=sha1,sha256/server-time
+
+`server-time` is always implicitly specified, and should be omitted.
+
+The `HASH` S2C command
+----------------------
+
+The `HASH` command shall be sent for hashes associated with a channel.
+
+Each hash must be a cryptographic hash. Non-cryptographic hashes must be ignored. Broken hash algorithms should be avoided. MD5 is explicitly disallowed and must not be used.
+
+The counter must be able to store numbers in the `0..2^62-1` range.
+
+These hashes specify the current "heads" of the clog. This is similar to git heads, if you're familiar with them.
+
+Syntax:
+
+ HASH #channel :hash_type=counter/hash,type=counter/hash,...
+
+Example:
+
+ >>> JOIN #channel
+ <<< JOIN #channel
+ <<< NAMES etc
+ <<< HASH #channel :sha1=20,something_long
+ <<< HASH #channel :sha1=60,something_else sha256=70,another
+
+Optionally, the server may include a server name with the HASH command:
+
+ <<< :server1.example.com HASH #channel :etc
+ <<< :server2.example.com HASH #channel :other
+
+The `hash` message tag
+----------------------
+
+The `hash` mesaage tag shall be sent with every `PRIVMSG`, `TOPIC` and `NOTICE`.
+
+Syntax:
+
+ hash=type=counter/short_hash,type=counter/short_hash,...
+
+The use of `short_hash` lowers bandwidth requirements. Consult your cryptography expert for best practices on using cryptography.
+
+These hashes specify the previous "head(s)" of the clog. "Merges" are just messages with hashes from different sources.
+
+Example:
+
+ TODO
+
+Security Considerations
+-----------------------
+
+Clogs are meant for channels that want public logging. An example is the Rust IRC channel. As such, anything in a clog should be assumed public.
+
+It's possible to recover deleted clogs by setting up a separate IRC network and sending the right hashes on the right channel. However, you'd still need to know the hashes.
+Thus, this isn't a vulnerability, because if you had the hashes, you could just request the logs directly, without going through the process of setting up an IRC network.
+
+The network could be made to sign all hashes, but you'd need to share the signing key across all servers for it to work correctly. This still doesn't prevent someone
+from getting access to an intercepted, correctly-signed hash, and by sharing the signing key you increase the attack surface.
+
+[FIXME there may be more]
+
+The `SYNC` CTCP (informative)
+-----------------------------
+
+*This section is informative.*
+
+The `SYNC` CTCP is a hypothetical CTCP for syncing logs.
+
+Syntax:
+
+ SYNC <tox-compatible public key> <port> <host> <host> <...> -[nospam+checksum]
+
+This is a highly flexible command supporting ipv4, ipv6, hostname, tor, i2p and tox ID.
+
+Messages sent over non-tox channels must be encrypted with the tox-compatible public key.
@@ -0,0 +1,77 @@ +CAP prefix/clog
+===============
+
+Copyright (c) Soni L. \<fakedme plus irkv3 at gmail dot com>
+
+This capability provides a mechanism for identifying and conveying a cryptographically secured list of messages to IRC clients.
+
+This specification also suggests a mechanism by which IRC clients can sync logs, using the information provided by this capability.
+
+Cap syntax
+----------
+
+The capability shall be specified as
+
+ prefix/clog=hash_type,hash_type/tag,tag,tag
+
+Example:
+
+ prefix/clog=sha1,sha256/server-time
+
+`server-time` is always implicitly specified, and should be omitted.
+
+The `HASH` S2C command
+----------------------
+
+The `HASH` command shall be sent for hashes associated with a channel.
+
+Each hash must be a cryptographic hash. Non-cryptographic hashes must be ignored. Broken hash algorithms should be avoided. MD5 is explicitly disallowed and must not be used.
+
+The counter must be able to store numbers in the `0..2^62-1` range.
+
+Syntax:
+
+ HASH #channel :hash_type=counter/hash,type=counter/hash,...
+
+Example:
+
+ >>> JOIN #channel
+ <<< JOIN #channel
+ <<< NAMES etc
+ <<< HASH #channel :sha1=20,something_long
+ <<< HASH #channel :sha1=60,something_else sha256=70,another
+
+Optionally, the server may include a server name with the HASH command:
+
+ <<< :server1.example.com HASH #channel :etc
+ <<< :server2.example.com HASH #channel :other
+
+The `hash` message tag
+----------------------
+
+The `hash` mesaage tag shall be sent with every `PRIVMSG`, `TOPIC` and `NOTICE`.
+
+Syntax:
+
+ hash=type=counter/short_hash,type=counter/short_hash,...
+
+The use of `short_hash` lowers bandwidth requirements. Consult your cryptography expert for best practices on using cryptography.
+
+Example:
+
+ TODO
+
+The `SYNC` CTCP (informative)
+-----------------------------
+
+*This section is informative.*
+
+The `SYNC` CTCP is a hypothetical CTCP for syncing logs.
+
+Syntax:
+
+ SYNC <tox-compatible public key> <port> <host> <host> <...> -[nospam+checksum]
+
+This is a highly flexible command supporting ipv4, ipv6, hostname, tor, i2p and tox ID.
+
+Messages sent over non-tox channels must be encrypted with the tox-compatible public key.
@@ -0,0 +1,102 @@ +CAP prefix/clog
+===============
+
+Copyright (c) Soni L. \<fakedme plus irkv3 at gmail dot com>
+
+This capability provides a mechanism for identifying and conveying a cryptographically secured list of messages to IRC clients.
+
+This specification also suggests a mechanism by which IRC clients can sync logs, using the information provided by this capability.
+
+Cap syntax
+----------
+
+The capability shall be specified as
+
+ prefix/clog=hash_type,hash_type/tag,tag,tag
+
+Example:
+
+ prefix/clog=sha1,sha256/server-time,prefix/hash
+
+`server-time` and `prefix/hash` are always implicitly specified, and should be omitted.
+
+The `HASH` S2C command
+----------------------
+
+The `HASH` command shall be sent for hashes associated with a channel.
+
+Each hash must be a cryptographic hash. Non-cryptographic hashes must be ignored. Broken hash algorithms should be avoided. MD5 is explicitly disallowed and must not be used.
+
+The counter must be able to store numbers in the `0..2^62-1` range.
+
+These hashes specify the current "heads" of the clog. This is similar to git heads, if you're familiar with them.
+
+Syntax:
+
+ HASH #channel :hash_type=counter/hash,type=counter/hash,...
+
+Example:
+
+ >>> JOIN #channel
+ <<< JOIN #channel
+ <<< NAMES etc
+ <<< HASH #channel :sha1=20,something_long
+ <<< HASH #channel :sha1=60,something_else sha256=70,another
+
+Optionally, the server may include a server name with the HASH command:
+
+ <<< :server1.example.com HASH #channel :etc
+ <<< :server2.example.com HASH #channel :other
+
+The `hash` message tag
+----------------------
+
+The `hash` mesaage tag shall be sent with every `PRIVMSG`, `TOPIC` and `NOTICE`.
+
+Syntax:
+
+ prefix/hash=type=counter/short_hash,type=counter/short_hash,...
+
+The use of `short_hash` lowers bandwidth requirements. Consult your cryptography expert for best practices on using cryptography.
+
+These hashes specify the previous "head(s)" of the clog. "Merges" are just messages with hashes from different sources.
+
+The hash encompasses the message tags specified by the capability (e.g. `server-time` and `hash`), sorted according to UTF-8 byte order, and the contents of the IRC message, as seen in the following format:
+
+ @prefix/hash=...;server-time=... :nick!user@host PRIVMSG #channel :message
+
+(This line is what gets hashed)
+
+Examples:
+
+ TODO
+
+Security Considerations
+-----------------------
+
+Clogs are meant for channels that want public logging. An example is the Rust IRC channel. As such, anything in a clog should be assumed public.
+
+It's possible to recover deleted clogs by setting up a separate IRC network and sending the right hashes on the right channel. However, you'd still need to know the hashes.
+Thus, this isn't a vulnerability, because if you had the hashes, you could just request the logs directly, without going through the process of setting up an IRC network.
+
+The network could be made to sign all hashes, but you'd need to share the signing key across all servers for it to work correctly. This still doesn't prevent someone
+from getting access to an intercepted, correctly-signed hash, and by sharing the signing key you increase the attack surface.
+
+The server can and should be able to "undo" hashes. This is useful if, for example, someone posts child pornography - you likely don't want that permanently recorded in a channel's history.
+
+[FIXME there may be more]
+
+The `SYNC` CTCP (informative)
+-----------------------------
+
+*This section is informative.*
+
+The `SYNC` CTCP is a hypothetical CTCP for syncing logs.
+
+Syntax:
+
+ SYNC <tox-compatible public key> <port> <host> <host> <...> -[nospam+checksum]
+
+This is a highly flexible command supporting ipv4, ipv6, hostname, tor, i2p and tox ID.
+
+Messages sent over non-tox channels must be encrypted with the tox-compatible public key.
|