Obfuscation

Package obfuscate implements quantizing and obfuscating of tags and resources for a set of spans matching a certain criteria. This module is used in the Datadog Agent, the Go tracing client (dd-trace-go) and in the OpenTelemetry Collector Datadog exporter./ End-user behavior is stable, but there are no stability guarantees on its public Go API. Nonetheless, if editing try to avoid breaking API changes if possible and double check the API usage on all module dependents.

garble obfuscates Go code by wrapping the Go toolchain.

garble obfuscates Go code by wrapping the Go toolchain.

Package obfs4 provides an implementation of the Tor Project's obfs4 obfuscation protocol.

Package obfs2 provides an implementation of the Tor Project's obfs2 obfuscation protocol. This protocol is considered trivially broken by most sophisticated adversaries.

Package fn implements the traditional map/filter/reduce/each functions and an array type (A) for those who prefer a more object-oriented approach. Unlike other implementations, the array (slice) is always first preventing the first-class in-line anonymous function from obfuscating the parameter list of the functional function.

Package gqlgen contains an implementation of a gqlgen tracer, and functions to construct and configure the tracer. The tracer can be passed to the gqlgen handler (see package github.com/99designs/gqlgen/handler) Warning: Data obfuscation hasn't been implemented for graphql queries yet, any sensitive data in the query will be sent to Datadog as the resource name of the span. To ensure no sensitive data is included in your spans, always use parameterized graphql queries with sensitive data in variables.

Package obfs4 provides an implementation of the Tor Project's obfs4 obfuscation protocol.

Package obfs2 provides an implementation of the Tor Project's obfs2 obfuscation protocol. This protocol is considered trivially broken by most sophisticated adversaries.

Package gopaque implements the OPAQUE protocol. The OPAQUE protocol, described as of this writing in the RFC draft at https://tools.ietf.org/html/draft-krawczyk-cfrg-opaque-01, is a protocol that allows a user with a password to register and authenticate with a server without ever giving that server the password. It uses the OPAQUE password authenticated key exchange (PAKE) which uses derived keys for registration authentication. A high-level introduction to OPAQUE (and PAKEs in general) is available at https://blog.cryptographyengineering.com/2018/10/19/lets-talk-about-pake/. This implementation uses the https://github.com/dedis/kyber crypto library. The implementation is intentionally very extensible and exposed, but sensible default implementations are provided for every abstraction. The registration and authentication flows are below, followed by a couple of code examples clarifying usage. This was developed by a hobbyist, not a cryptographer. The code has not been reviewed for accuracy or security. No care was taken to obfuscate the errors or prevent timing attacks. Only use after reviewing the code and understanding the implications. OPAQUE registration is a 3-message process starting with the user where a user registers with the server. The only input a user needs is the password and after registration, the server has the info to perform authentication. The steps for a user are: 1 - Create a NewUserRegister with the user ID 2 - Call Init with the password and send the resulting UserRegisterInit to the server 3 - Receive the server's ServerRegisterInit 4 - Call Complete with the server's ServerRegisterInit and send the resulting UserRegisterComplete to the server The steps for a server are: 1 - Receive the user's UserRegisterInit 2 - Create a NewServerRegister with a private key 3 - Call Init with the user's UserRegisterInit and send the resulting ServerRegisterInit to the user 4 - Receive the user's UserRegisterComplete 5 - Call Complete with the user's UserRegisterComplete and persist the resulting ServerRegisterComplete OPAQUE authentication is intended to be used in conjunction with a key exchange protocol to authenticate a user. Gopaque supports either an external key exchange protocol or one embedded into the auth process. The pure OPAQUE part of the flow is only a 2-message process, but validation with a key exchange often adds a third message. The steps below assume the key exchange is embedded in the auth process instead of being external. The steps for a user are: 1 - Create a NewUserAuth with an embedded key exchange 2 - Call Init with the password and send the resulting UserAuthInit to the server 3 - Receive the server's ServerAuthComplete 4 - Call Complete with the server's ServerAuthComplete. The resulting UserAuthFinish has user and server key information. This would be the last step if we were not using an embedded key exchange. Since we are, take the resulting UserAuthComplete and send it to the server. The steps for a server are: 1 - Receive the user's UserAuthInit 2 - Create a NewServerAuth with an embedded key exchange 3 - Call Complete with the user's UserAuthInit and persisted ServerRegisterComplete and send the resulting ServerAuthComplete to the user. This would be the last step if we were not using an embedded key exchange. 4 - Receive the user's UserAuthComplete 5 - Call Finish with the user's UserAuthComplete This simple example doesn't marshal the messages, it just sends them. This example is a more complex example showing marshalling and using separate user and server-side connections.

Package obfuscate implements quantizing and obfuscating of tags and resources for a set of spans matching a certain criteria.

Package jettyobf is a go implementation of the Jetty Password Obfuscation algorithm https://www.eclipse.org/jetty/documentation/current/configuring-security-secure-passwords.html Note: obfuscated passwords have no security benifits. Obfuscated passwords are easily reverted to their plain-text form. THIS IS NOT A REPLACEMENT FOR PROPER PASSWORD HASHING OR ENCRYPTION.

Package revealer will "de-obfuscate" email addresses. It has been tested on a fairly large corpus of obfuscated email addresses. See README.md for more info.

Package presents implements a block cipher-based method of converting 64-bit unsigned integers to and from strings. The intended application is towards the obfuscation of sequential database IDs. This example show how to encode and decode IDs. This example shows how to use a custom alphabet as well as shuffling it.

Package chainable provides an easy and convenient way of chaining function calls in Golang. It's common to find Go programs similar to the one below: Error handling can make the codebase messy. At the same time, chaining function calls can obfuscate errors and cascading calls can increase the cognitive complexity. Elixir, F# and other languages solve this problem with the support to pipes, but Golang hasn't such feature. Chainable provides a clearer way to chain function calls, using the output of the previous function as the input of the next one. The example above could be re-written using Chainable as follow: Another advantage is that Chainable automatically handle errors in a chain. Thus, if one of the methods returns an error as the last argument, the chain is broken and the error is returned by the "Unwrap" method: If automatic error handling isn't desired (i.e. the error should be chained along with the other arguments), the method "ChainDummy" should be used instead of "Chain". Pay attention that the next function in the chain must be able to receive the error generated by the previous one: "Chain" and "DummyChain" methods are variadics, and can be used in conjunction: Finally, to reset a chain and make it ready to be reused, just call the method "Reset":

Package lampshade provides a transport between Lantern clients and proxies that provides obfuscated encryption as well as multiplexing. The protocol attempts to be indistinguishable in content and timing from a random stream of bytes, and mostly follows the OBFS4 threat model - https://github.com/Yawning/obfs4/blob/master/doc/obfs4-spec.txt#L35 Lampshade attempts to minimize overhead, so it uses less padding than OBFS4. Also, to avoid having to pad at all, lampshade coalesces consecutive small writes into single larger messages when there are multiple pending writes. Due to lampshade being multiplexed, especially during periods of high activity, coalescing is often possible. Definitions: Protocol: General Protocol Features protocol attempts to be indistinguishable in content and timing from a random stream of bytes, following the OBFS4 threat model - https://github.com/Yawning/obfs4/blob/master/doc/obfs4-spec.txt#L35 all numeric fields are unsigned integers in BigEndian format Client Init Message Session Framing: Encryption: Padding: Stream Framing: Flow Control: Ping Protocol:

Package mse (Message Stream Encryption) provides a transparent wrapper for bidirectional data streams (e.g. TCP transports) that prevents passive eavesdroping and thus protocol or content identification. It is also designed to provide limited protection against active MITM attacks and portscanning by requiring a weak shared secret to complete the handshake. You should note that the major design goal was payload and protocol obfuscation, not peer authentication and data integrity verification. Thus it does not offer protection against adversaries which already know the necessary data to establish connections (that is IP/Port/Shared Secret/Payload protocol). To minimize the load on systems that employ this protocol fast cryptographic methods have been chosen over maximum-security algorithms. See http://wiki.vuze.com/w/Message_Stream_Encryption for details.

Package lampshade provides a transport between Lantern clients and proxies that provides obfuscated encryption as well as multiplexing. The protocol attempts to be indistinguishable in content and timing from a random stream of bytes, and mostly follows the OBFS4 threat model - https://github.com/Yawning/obfs4/blob/master/doc/obfs4-spec.txt#L35 Lampshade attempts to minimize overhead, so it uses less padding than OBFS4. Also, to avoid having to pad at all, lampshade coalesces consecutive small writes into single larger messages when there are multiple pending writes. Due to lampshade being multiplexed, especially during periods of high activity, coalescing is often possible. Definitions: Protocol: General Protocol Features protocol attempts to be indistinguishable in content and timing from a random stream of bytes, following the OBFS4 threat model - https://github.com/Yawning/obfs4/blob/master/doc/obfs4-spec.txt#L35 all numeric fields are unsigned integers in BigEndian format Client Init Message Session Framing: Encryption: Padding: Stream Framing: Flow Control: Ping Protocol:

Package lampshade provides a transport between Lantern clients and proxies that provides obfuscated encryption as well as multiplexing. The protocol attempts to be indistinguishable in content and timing from a random stream of bytes, and mostly follows the OBFS4 threat model - https://github.com/Yawning/obfs4/blob/master/doc/obfs4-spec.txt#L35 Lampshade attempts to minimize overhead, so it uses less padding than OBFS4. Also, to avoid having to pad at all, lampshade coalesces consecutive small writes into single larger messages when there are multiple pending writes. Due to lampshade being multiplexed, especially during periods of high activity, coalescing is often possible. Definitions: Protocol: General Protocol Features protocol attempts to be indistinguishable in content and timing from a random stream of bytes, following the OBFS4 threat model - https://github.com/Yawning/obfs4/blob/master/doc/obfs4-spec.txt#L35 all numeric fields are unsigned integers in BigEndian format Client Init Message Session Framing: Encryption: Padding: Stream Framing: Flow Control: Ping Protocol: