Package tlock provides an API for encrypting/decrypting data using drand time lock encryption. This allows data to be encrypted and only decrypted in the future.
Package ntlmssp provides NTLM/Negotiate authentication over HTTP Protocol details from https://msdn.microsoft.com/en-us/library/cc236621.aspx, implementation hints from http://davenport.sourceforge.net/ntlm.html . This package only implements authentication, no key exchange or encryption. It only supports Unicode (UTF16LE) encoding of protocol strings, no OEM encoding. This package implements NTLMv2.
Package srp Secure Remote Password protocol The principal interface provided by this package is the SRP type. The end aim of the caller is to to have an SRP server and SRP client arrive at the same key. See the documentation for the SRP structure and its methods for the nitty gritty of use. BUG(jpg): This does not use the same padding and hashing scheme as in RFC 5054, and therefore is not interoperable with those clients and servers. Perhaps someday we'll add an RFC 5054 mode that does that, but today is not that day. It would be nice if this package could be used without having some understanding of the SRP protocol, but too much of the language and naming depends on at least some familiarity. Here is a summary. The Secure Remote Password protocol involves a server and a client proving to each other that they know (or can derive) their long term secrets. The client's long term secret is known as "x" and the corresponding server secret, the verifier, is known as "v". The verifier is mathematically related to x and is computed by the client on first enrollment and transmitted to the server. Typically the server will store the verifier and the client will derive x from a user secret such as a password. Because the verifier can used like a password hash with respect to cracking, the derivation of x should be designed to resist password cracking if the verifier is compromised. The client and the server must both use the same Diffie-Hellman group to perform their computations. The server and the client each send an ephemeral public key to each other. (The client sends A; the server sends B.) With their private knowledge of their own ephemeral secrets (a or b) and their private knowledge of x (for the client) and v (for the server) along with public knowledge they are able to prove to each other that they know their respective secrets and can generate a session key, K, which may be used for further encryption during the session. Quoting from http://srp.stanford.edu/design.html (with some modification for KDF and and checks) This package does not address the actual communication between client and server. But through the SRP type it not only performs the calculations needed, it also performs safety and sanity checks on its input, and it hides everything from the caller except what the caller absolutely needs to provide. The key derivation function, KDF() 1. Both client and server: Checking whether methods have returned without error. This is particularly true of SRP.Key() and SetOthersPublic() 2. Client: Using an appropriate key derivation function for deriving x from the user's password (and nudging user toward a good password) 3. Server: Storing the v securely (sent by the client on first enrollment). A captured v can be used to impersonate the server. The verifier, v, can also be used like a password hash in a password cracking attempt 4. Both: Proving to each other that both have the same key. The package includes methods that can assist with that. ExampleServerClientKey is an example.
Package beanstalk provides a beanstalk client. The Producer is used to put jobs into tubes. It provides a connection pool: Putting a job in a tube is done by calling Put, which will select a random connection for its operation: If a Put operation fails on a connection, another connection in the pool will be selected for a retry. The Consumer is used to reserve jobs from tubes. It provides a connection pool: The ratio of Multiply and NumGoroutines is important. Multiply determines the size of the connection pool and NumGoroutines determines how many reserved jobs you have in-flight. If you have a limited number of connections, but a high number of reserved jobs in-flight, your TCP connection pool might experience congestion and your processing speed will suffer. Although the ratio depends on the speed by which jobs are processed, a good rule of thumb is 1:10. Reserve jobs from the tubes specified in NewConsumer is done by calling Receive, which will reserve jobs on any of the connections in the pool: If the context passed to Receive is cancelled, Receive will finish processing the jobs it has reserved before returning. When Receive offers a job the goroutine is responsible for processing that job and finishing it up. A job can either be deleted, released or buried: If the Producer and Consumer abstractions are too high, then Conn provides the lower level abstraction of a single connection to a beanstalk server: The Config structure offers hooks for info and error logs that allows hooking in to a custom log solution. NewProducer, NewConsumer and Dial take a URI or a list of URIs as their first argument, who can be described in various formats. In the above examples the beanstalk server was referenced by the host:port notation. This package also supports URI formats like beanstalk:// for a plaintext connection, and beanstalks:// or tls:// for encrypted connections. In the case of encrypted connections, if no port has been specified it will default to port 11400 as opposed to the default 11300 port.
Package age implements file encryption according to the age-encryption.org/v1 specification. For most use cases, use the Encrypt and Decrypt functions with X25519Recipient and X25519Identity. If passphrase encryption is required, use ScryptRecipient and ScryptIdentity. For compatibility with existing SSH keys use the filippo.io/age/agessh package. age encrypted files are binary and not malleable. For encoding them as text, use the filippo.io/age/armor package. age does not have a global keyring. Instead, since age keys are small, textual, and cheap, you are encouraged to generate dedicated keys for each task and application. Recipient public keys can be passed around as command line flags and in config files, while secret keys should be stored in dedicated files, through secret management systems, or as environment variables. There is no default path for age keys. Instead, they should be stored at application-specific paths. The CLI supports files where private keys are listed one per line, ignoring empty lines and lines starting with "#". These files can be parsed with ParseIdentities. When integrating age into a new system, it's recommended that you only support X25519 keys, and not SSH keys. The latter are supported for manual encryption operations. If you need to tie into existing key management infrastructure, you might want to consider implementing your own Recipient and Identity. Files encrypted with a stable version (not alpha, beta, or release candidate) of age, or with any v1.0.0 beta or release candidate, will decrypt with any later versions of the v1 API. This might change in v2, in which case v1 will be maintained with security fixes for compatibility with older files. If decrypting an older file poses a security risk, doing so might require an explicit opt-in in the API.
Package stream is a Golang library that transforms any net.Conn or io.ReadWriter stream to an encrypted and/or authenticated stream. 1. The encrypted stream implements net.Conn and io.ReadWriter and can be used as drop-in replacement. 2. Works with any encryption, authentication, or authenticated encryption algorithm or even arbitrary transformation. Only a cipher that implements encrypt/decrypt needs to be provided. XSalsa20-Poly1305 and AES-GCM are provided as reference cipher. 3. The encrypted stream only adds a small constant memory overhead compared to the original stream. Note: this library does not handle handshake or key exchange. Handshake should be done separately before using this library to compute a shared key.
Package sessions provides a minimalist and lightweight HTTP session cookie implementation for Go. Session cookies are encrypted and authenticated using nacl/secretbox. Example usage:
Package sqlite3 provides interface to SQLite3 databases. This works as a driver for database/sql. Installation Currently, go-sqlite3 supports the following data types. You can write your own extension module for sqlite3. For example, below is an extension for a Regexp matcher operation. It needs to be built as a so/dll shared library. And you need to register the extension module like below. Then, you can use this extension. You can hook and inject your code when the connection is established. database/sql doesn't provide a way to get native go-sqlite3 interfaces. So if you want, you need to set ConnectHook and get the SQLiteConn. If you want to register Go functions as SQLite extension functions, call RegisterFunction from ConnectHook. See the documentation of RegisterFunc for more details.