Secure software enclave for storage of sensitive information in memory.

Overview

MemGuard

Software enclave for storage of sensitive information in memory.


This package attempts to reduce the likelihood of sensitive data being exposed when in memory. It aims to support all major operating systems and is written in pure Go.

Features

  • Sensitive data is encrypted and authenticated in memory with XSalsa20Poly1305. The scheme used also defends against cold-boot attacks.
  • Memory allocation bypasses the language runtime by using system calls to query the kernel for resources directly. This avoids interference from the garbage-collector.
  • Buffers that store plaintext data are fortified with guard pages and canary values to detect spurious accesses and overflows.
  • Effort is taken to prevent sensitive data from touching the disk. This includes locking memory to prevent swapping and handling core dumps.
  • Kernel-level immutability is implemented so that attempted modification of protected regions results in an access violation.
  • Multiple endpoints provide session purging and safe termination capabilities as well as signal handling to prevent remnant data being left behind.
  • Side-channel attacks are mitigated against by making sure that the copying and comparison of data is done in constant-time.
  • Accidental memory leaks are mitigated against by harnessing the garbage-collector to automatically destroy containers that have become unreachable.

Some features were inspired by libsodium, so credits to them.

Full documentation and a complete overview of the API can be found here. Interesting and useful code samples can be found within the examples subpackage.

Installation

$ go get github.com/awnumar/memguard

API is experimental and may have unstable changes. You should pin a version. [modules]

Contributing

  • Submitting program samples to ./examples.
  • Reporting bugs, vulnerabilities, and any difficulties in using the API.
  • Writing useful security and crypto libraries that utilise memguard.
  • Implementing kernel-specific/cpu-specific protections.
  • Submitting performance improvements.

Issues are for reporting bugs and for discussion on proposals. Pull requests should be made against master.

Issues
  • [Suggestions] Can the API be improved?

    [Suggestions] Can the API be improved?

    As we move closer to v1.0.0, do you have any suggestions for improvements to the API?

    I've used the library myself in my own projects, so primarily that's the only indication I have of the suitability, ease-of-use, and just general quality of the API.

    So, to those of you that use memguard (or not), add a comment with your opinions or suggestions.

    help wanted 
    opened by awnumar 24
  • Memguard Panics After Creating 15 Objects

    Memguard Panics After Creating 15 Objects

    Program:

    package main
    
    import (
    	"fmt"
    	"github.com/libeclipse/memguard"
    )
    
    func main() {
    	for i := 0; i < 100; i++ {
    		key := []byte("123456768901234567890123456789012")
    		safeKey, err := memguard.NewFromBytes(key, true)
    		if err != nil {
    			panic(err.Error())
    		}
    		fmt.Printf("%v: %v\n", i, safeKey)
    	}
    }
    

    Output on a CentOS Linux release 7.3.1611 VM:

    0: &{{0 0} [49 50 51 52 53 54 55 54 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50] true false}
    1: &{{0 0} [49 50 51 52 53 54 55 54 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50] true false}
    2: &{{0 0} [49 50 51 52 53 54 55 54 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50] true false}
    3: &{{0 0} [49 50 51 52 53 54 55 54 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50] true false}
    4: &{{0 0} [49 50 51 52 53 54 55 54 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50] true false}
    5: &{{0 0} [49 50 51 52 53 54 55 54 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50] true false}
    6: &{{0 0} [49 50 51 52 53 54 55 54 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50] true false}
    7: &{{0 0} [49 50 51 52 53 54 55 54 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50] true false}
    8: &{{0 0} [49 50 51 52 53 54 55 54 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50] true false}
    9: &{{0 0} [49 50 51 52 53 54 55 54 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50] true false}
    10: &{{0 0} [49 50 51 52 53 54 55 54 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50] true false}
    11: &{{0 0} [49 50 51 52 53 54 55 54 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50] true false}
    12: &{{0 0} [49 50 51 52 53 54 55 54 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50] true false}
    13: &{{0 0} [49 50 51 52 53 54 55 54 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50] true false}
    14: &{{0 0} [49 50 51 52 53 54 55 54 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50] true false}
    15: &{{0 0} [49 50 51 52 53 54 55 54 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50 51 52 53 54 55 56 57 48 49 50] true false}
    panic: memguard.memcall.Lock(): could not acquire lock on 0x7f7711a67000 [Err: cannot allocate memory]
    
    goroutine 1 [running]:
    github.com/libeclipse/memguard/memcall.Lock(0x7f7711a67000, 0x1000, 0x2000)
    	~/go/src/github.com/libeclipse/memguard/memcall/memcall_unix.go:18 +0x16c
    github.com/libeclipse/memguard.New(0x21, 0x4cd800, 0x21, 0x30, 0x21)
    	~/go/src/github.com/libeclipse/memguard/memguard.go:78 +0xf6
    github.com/libeclipse/memguard.NewFromBytes(0xc420010bd0, 0x21, 0x30, 0xc420010b01, 0x21, 0x30, 0x0)
    	~/go/src/github.com/libeclipse/memguard/memguard.go:113 +0x34
    main.main()
    	try.go:11 +0x8a
    

    It happens on every run on this host. I get the same results on a CentOS release 6.9 (Final) VM. It does not fail on my Mac.

    documentation 
    opened by theory 24
  • Maybe get rid of most package level variables

    Maybe get rid of most package level variables

    Maybe I should have thought this through a bit more, but it seems to me that there is too much package level variables. I think that prevents memguard from being used by multiple dependencies of a Go program. For example; consider a program "package a" that depends on memguard/core and also on "package b", which in turn depends on memguard/core. Suppose both "a" and "b" try to set core.Interval, then there is a data race as it is not known which store to core.Interval happened last and which will affect the memguard funcs.

    proposal 
    opened by nsajko 16
  • Multiple changes

    Multiple changes

    • Refactoring of functionality into core package.
    • Addition of Enclave objects which store encrypted data.
    • Rewrite of signals handling. Should make implementing further data catching much easier.
    • Rewrite and simplification of the API.
    • Addition of examples package.
    • Patched data races in interrupt handling functionality.
    • Conceal mapped memory from core dumps on OpenBSD.
    • Additional functionality added such as safe panicking.
    • Disable core dumps by default. Users that want them can enable themselves.
    • Use local entropy pool for fast random bytes reading.
    • Use a variable sized canary value with 32 <= len(canary) <= ~pagesize.
    • Other optimisations and improvements.
    • ...
    patch feature api-change performance security needs-review 
    opened by awnumar 14
  • Use finalizers to prevent leaks

    Use finalizers to prevent leaks

    As suggested in https://www.reddit.com/r/golang/comments/6s84ky/memory_security_in_go/dlcmzp3/

    Some cosmetic/ux changes may be needed. LockedBuffers() was removed to allow implementing automatic destruction. This shouldn't be much of a problem since I can't think of any good use cases outside of DeleteAll().

    feature 
    opened by CAFxX 10
  • Support custom randomness source

    Support custom randomness source

    Is your feature request related to a problem? Please describe. When testing cryptographic systems it's always useful to be able to have a predictable source of randomness so you can support test vectors. For NewImmutableRandom, NewMutableRandom, FillRandomBytes, FillRandomBytesAt it would be nice to be able to provide predictable randomness during a test phase.

    Describe the solution you'd like One way of solving the problem would be to have a way of temporarily setting a rand Reader for the package temporarily. Another solution would be that each LockedBuffer has an io.Reader associated with it, that can be set (although that doesn't help for NewImmutableRandom and NewMutableRandom. Another solution would be to add functions that take a Reader for the randomness source.

    Describe alternatives you've considered I don't really have any good alternatives to how to solve this.

    tests proposal 
    opened by olabini 10
  • Memguard must manage memory allocation to work

    Memguard must manage memory allocation to work

    See HN article for more detail. TL;DR, golang does not specify any particular semantics about memory addresses. Calling mlock on a go-managed memory address provide little to nothing in the way of guarantees, because that memory will be copied and moved around as the runtime sees fit.

    This is pretty much unavoidable. The address you call mlock on isn't even guaranteed to be the address passed in via memlock.Lock(b).

    bug 
    opened by stouset 9
  • proposal: protect data with noaccess until it is read

    proposal: protect data with noaccess until it is read

    Is your feature request related to a problem? Please describe. Currently the guard pages use noaccess protection, but the inner region (canary + data) is still readable. This leaves the inner region vulnerable to memory scans (have verified this locally).

    Describe the solution you'd like It would be nice to have an option to make the inner region always be set to noaccess and only make it read-only when it needs to be read. Making this a default behavior would likely require a breaking API change. This is also similar to what's described in https://download.libsodium.org/doc/memory_management#guarded-heap-allocations in the sodium_mprotect_noaccess related info (specifically, This function can be used to make confidential data inaccessible except when actually needed for a specific operation.).

    We have Java and C# implementations that are very similar to your project and libsodium (we only came across your project when our Go implementation was started). The approach we've taken is:

    • accepting a lambda/function from the user that operates on the data
    • call mprotect with readonly before the lambda invocation and then mprotect with noaccess after the lambda completes
    • we use a lock and access counter to minimize the mprotect readonly and noaccess system calls to only be done when needed (readonly after 1st access, noaccess after last caller exits)

    You can refer to how we've implemented this in https://github.com/godaddy/asherah/blob/4ead9ca1803056d2fe2ea006aaa771b3301ae28b/languages/java/secure-memory/src/main/java/com/godaddy/asherah/securememory/protectedmemoryimpl/ProtectedMemorySecret.java#L89-L113.

    Describe alternatives you've considered

    1. We considered using Enclave instead of LockedBuffer but we expect that for our use case, it will likely result in higher unmanaged memory usage (lot of caching and concurrent reads of keys).
    2. We've considered seeing if we can replicate the page boundary calculations to get an unsafe handle on the inner region start, but this seems very messy and error prone.
    3. We're considering replicating our Secure Memory implementation in Go, similar to what we did for Java/C#, but we're hoping to use your implementation for Go instead. The only other thing that may be an issue for us is whether the guard pages cause too much unmanaged memory in our workloads, but we'll cross that bridge when we get there.

    Additional context Think I covered all the details. Let me know if you have any questions on this. I can add the script that was used to verify the memory is readable if you'd like.

    proposal resolved 
    opened by jpaskhay 9
  • How to invalidate Enclaves?

    How to invalidate Enclaves?

    I'm implementing a transparently encrypted in-memory filesystem, and I'm storing the data of in-memory files as pointers to Enclaves *memguard.Enclave. I'm not sure what to do when I need to delete a file, or truncate a file to 0. I know that LockedBuffers can be destroyed with the Destroy method, but Enclaves don't have such a method.

    I'm also aware that when memguard.Purge is called, Enclaves are rendered useless by rolling the decryption key for them, which makes sense. How then can I safely invalidate a single enclave at will? Is that possible?

    question 
    opened by capnspacehook 9
  • Q: panic: <memcall> could not acquire lock

    Q: panic: could not acquire lock

    Hi, I am just wasting some time so I thought I'd compare performance requirements and I am getting panic from enclave.Open(). Any idea why?

    package whatever
    
    import (
    	"github.com/awnumar/memguard"
    	"testing"
    )
    
    func BenchmarkEnclaveOpen(b *testing.B) {
    	secret := []byte("secret secret secret")
    	e := memguard.NewEnclave(secret)
    
    	for i := 0; i < b.N; i++ {
    		e.Open()
    	}
    }
    
    func BenchmarkEnclaveOpenRead(b *testing.B) {
    	secret := []byte("secret secret secret")
    	e := memguard.NewEnclave(secret)
    
    	for i := 0; i < b.N; i++ {
    		lb, _ := e.Open()
    		lb.String()
    	}
    }
    
    func BenchmarkLBRead(b *testing.B) {
    	secret := []byte("secret secret secret")
    	lb := memguard.NewBufferFromBytes(secret)
    
    	for i := 0; i < b.N; i++ {
    		lb.String()
    	}
    }
    
    question resolved 
    opened by ghost 8
  • What's possible reason .Bytes() returns an empty slice on LockedBuffer from enclave.Open() ?

    What's possible reason .Bytes() returns an empty slice on LockedBuffer from enclave.Open() ?

    We encountered an infrequent problem at runtime in one of Ubuntu docker containers:

    panic: runtime error: slice bounds out of range [:32] with capacity 0
    goroutine 147009 [running]:
    github.com/xxx/secretsclient.EncryptMapData(0xc03ca81c80, 0x4, 0xc0209ba1b0, 0xc0004d5200, 0x45, 0x5e, 0x0, 0x0)
    	/go/pkg/mod/github.com/xxx/[email protected]/encrypt.go:125 +0x1fae
    ...
    

    The code segment around encrypt.go:125 is (with an added line # and comments)

    (119)	keyIVBuf, err := encKeyIV.Open()  // encKeyIV was from keyiv.Seal() with keyiv.Size() == KeyIVSIZE(48)
    	if err != nil {
    		return err
    	}
    	defer keyIVBuf.Destroy()
    
    (125)	block, err := aes.NewCipher(keyIVBuf.Bytes()[:cKeySize])  // cKeySize = 32
    	if err != nil {
    		return err
    	}
    

    Couldn't figure out what went wrong... would a low memlock ulimit possibly cause this? Thanks. (we do have ulimit setting

    / # cat /etc/security/limits.conf
    * soft memlock 512000
    * hard memlock 1024000
    

    Somehow the ulimit command still shows the default (this would encounter problems quickly for us):

    / # ulimit -l
    64
    

    so a little puzzled here too.) Appreciate your help!!

    Additional info: version github.com/awnumar/memguard v0.22.2 OS: Ubuntu 16.04 docker image Go 1.13

    We are also seeing the following error now in one of the docker instances (same instance as above):

    panic: runtime error: index out of range [0] with length 0
    goroutine 6911 [running]:
    github.com/awnumar/memguard/core.(*Coffer).View(0xc00001ec90, 0x0, 0x0, 0x0)
    	/go/pkg/mod/github.com/awnumar/[email protected]/core/coffer.go:112 +0x207
    github.com/awnumar/memguard/core.Open(0xc00979aa20, 0x661f81, 0xc00000ab40, 0x0)
    	/go/pkg/mod/github.com/awnumar/[email protected]/core/enclave.go:101 +0x60
    github.com/awnumar/memguard.(*Enclave).Open(0xc009482150, 0xc034b6d278, 0x4, 0xc009482150)
    	/go/pkg/mod/github.com/awnumar/[email protected]/enclave.go:43 +0x32
    github.com/xxx/secretsclient.EncryptMapData(0xc034b6d278, 0x4, 0xc02fd7cea0, 0xc00016d6c0, 0x16, 0x1c, 0x0, 0x0)
    	/go/pkg/mod/github.com/xxx/[email protected]/encrypt.go:119 +0x9d
    ...
    
    bug duplicate question 
    opened by ns-gzhang 8
  • panic: runtime error: coffer partition disappears

    panic: runtime error: coffer partition disappears

    Describe the bug

    This example crashes sporadically on my system.

    To Reproduce

    go test -v -count=10 ./examples/deadlock

    Traces

    === RUN   TestPanicsPoC
    [] [14 227 172 214 47 31 152 84 236 122 1 107 223 116 37 0 158 52 188 103 100 78 201 60 202 48 122 169 17 135 212 236]
    panic: open verify fail
    
    goroutine 26 [running]:
    github.com/awnumar/memguard/examples/deadlock.immediateOpen(0x59ed20, 0xc000054420, 0xc00000e060, 0xc000014440, 0x20, 0x20)
    	/home/awn/projects/src/go/src/github.com/awnumar/memguard/examples/deadlock/poc.go:80 +0x26e
    github.com/awnumar/memguard/examples/deadlock.OpenEnclave.func1(0xc000010230, 0xa, 0xa, 0xc00001c260, 0xc000136000, 0xa, 0xa, 0xa, 0x59ed20, 0xc000054420)
    	/home/awn/projects/src/go/src/github.com/awnumar/memguard/examples/deadlock/poc.go:40 +0xe8
    created by github.com/awnumar/memguard/examples/deadlock.OpenEnclave
    	/home/awn/projects/src/go/src/github.com/awnumar/memguard/examples/deadlock/poc.go:32 +0x2bf
    FAIL	github.com/awnumar/memguard/examples/deadlock	0.010s
    FAIL
    
    === RUN   TestPanicsPoC
    panic: runtime error: index out of range [0] with length 0
    
    goroutine 266 [running]:
    github.com/awnumar/memguard/core.(*Coffer).View(0xc0001082a0, 0x0, 0x0, 0x0)
    	/home/awn/projects/src/go/src/github.com/awnumar/memguard/core/coffer.go:123 +0x207
    github.com/awnumar/memguard/core.Open(0xc0000a80c0, 0x0, 0x0, 0x0)
    	/home/awn/projects/src/go/src/github.com/awnumar/memguard/core/enclave.go:101 +0x60
    github.com/awnumar/memguard.(*Enclave).Open(0xc0000a2038, 0x0, 0x0, 0x0)
    	/home/awn/projects/src/go/src/github.com/awnumar/memguard/enclave.go:43 +0x32
    github.com/awnumar/memguard/examples/deadlock.openVerify(0xc0000a2038, 0xc0000a6240, 0x20, 0x20, 0x0, 0x0)
    	/home/awn/projects/src/go/src/github.com/awnumar/memguard/examples/deadlock/poc.go:55 +0x58
    github.com/awnumar/memguard/examples/deadlock.immediateOpen.func1(0xc0000a2038, 0xc0000a6240, 0x20, 0x20, 0xc000180960)
    	/home/awn/projects/src/go/src/github.com/awnumar/memguard/examples/deadlock/poc.go:71 +0x49
    created by github.com/awnumar/memguard/examples/deadlock.immediateOpen
    	/home/awn/projects/src/go/src/github.com/awnumar/memguard/examples/deadlock/poc.go:70 +0xc8
    FAIL	github.com/awnumar/memguard/examples/deadlock	0.068s
    

    System (please complete the following information):

    • OS and Kernel Versions: Linux 5.6.15-300.fc32.x86_64
    • Memguard Version: master
    • Go Version: go version go1.14.3 linux/amd64
    bug duplicate 
    opened by awnumar 0
  • open enclave dead lock

    open enclave dead lock

    Describe the bug Open enclave may cause RWMutex lock, caused by recursive rlock the RWMutex which is not permitted by golang.

    in file: src/sync/rwmutex.go

    // If a goroutine holds a RWMutex for reading and another goroutine might
    // call Lock, no goroutine should expect to be able to acquire a read lock
    // until the initial read lock is released. In particular, this prohibits
    // recursive read locking. This is to ensure that the lock eventually becomes
    // available; a blocked Lock call excludes new readers from acquiring the
    // lock
    

    To Reproduce Steps to reproduce the behaviour:

    1. create a testcase that open the enclave parallel, maybe 20 goroutines.
    2. the process will locked in about 5 minutes, at Rlock() in func (s *Coffer) Destroyed() bool {
    3. this problem occurs in OSX and Linux

    Expected behaviour all process run normally

    Screenshots If applicable, add screenshots to help explain your problem.

    System (please complete the following information):

    • OS and Kernel Versions: OSX 10.15
    • Memguard Version: v0.19.1 & v0.22.1
    • Go Version: go1.12 & go1.14

    Additional context Use testcase below can generate the case. CPU usage start at about 100%, then decrease to 0%. now the process is locked.

    package main
    
    import (
    	"bytes"
    	"context"
    	"crypto/rand"
    	"errors"
    	"fmt"
    	"io"
    	"os"
    	"os/signal"
    	"syscall"
    	"time"
    
    	"github.com/awnumar/memguard"
    )
    
    func main() {
    	sigs := make(chan os.Signal, 1)
    	signal.Notify(sigs, syscall.SIGINT, syscall.SIGTERM)
    
    	ctx, cancel := context.WithTimeout(context.Background(), 5*time.Minute)
    	go func() {
    		select {
    		case <-sigs:
    			cancel()
    		}
    	}()
    	OpenEnclave(ctx)
    }
    
    func OpenEnclave(ctx context.Context) {
    	n := 10
    	data := make([][]byte, n)
    	enclaves := make([]*memguard.Enclave, n)
    	for i := range data {
    		data[i] = make([]byte, 32)
    		buf := make([]byte, 32)
    		io.ReadFull(rand.Reader, buf)
    		copy(data[i], buf)
    		enclaves[i] = memguard.NewEnclave(buf)
    	}
    
    	threads := 20
    	for i := 0; i < threads; i++ {
    		j := 0
    		go func(ctx context.Context) {
    			for {
    				select {
    				case <-ctx.Done():
    					return
    				default:
    					{
    						// fmt.Printf("open enclave %d \n", j)
    						immediateOpen(ctx, enclaves[j], data[j])
    						j = (j + 1) % n
    					}
    				}
    			}
    		}(ctx)
    	}
    	<-ctx.Done()
    	time.Sleep(time.Second)
    }
    
    func openVerify(lock *memguard.Enclave, exp []byte) error {
    	lb, err := lock.Open()
    	if err != nil {
    		return err
    	}
    	defer lb.Destroy()
    	if !bytes.Equal(lb.Bytes(), exp) {
    		return errors.New("open verify fail")
    	}
    	return nil
    }
    
    func immediateOpen(ctx context.Context, lock *memguard.Enclave, exp []byte) {
    	start := time.Now()
    	c1 := make(chan error, 1)
    	go func() {
    		err := openVerify(lock, exp)
    		c1 <- err
    	}()
    	var dur time.Duration
    	select {
    	case err := <-c1:
    		{
    			dur = time.Since(start)
    			if err != nil {
    				fmt.Printf("### open fail: %s \n", err)
    			}
    		}
    	case <-ctx.Done():
    		{
    			dur = time.Since(start)
    			fmt.Printf("### timeout \n")
    		}
    	}
    	// fmt.Printf("%d, %d \n", start.UnixNano(), dur.Nanoseconds())
    	_ = dur
    }
    
    bug 
    opened by wodadehencou 6
  • proposal: minimise the amount of unmanaged memory

    proposal: minimise the amount of unmanaged memory

    Is your feature request related to a problem? Please describe. Using guard pages has a tradeoff of taking up more unmanaged memory pages, which could be a potential concern in high traffic scenarios.

    Describe the solution you'd like Would be nice if there was an option to skip use guard pages when creating LockedBuffers. Can obviously keep using them by default but allow the user to pass in an option to avoid them. Whether this is exposed as part of the Enclave related usage should be considered, but could probably be handled separately, if needed.

    Describe alternatives you've considered Considered using Enclave, but in the expected traffic/usage patterns (cached keys, multiple concurrent users), it would likely lead to more unmanaged memory usage.

    Additional context N/A

    performance proposal 
    opened by jpaskhay 3
Releases(v0.22.2)
Owner
Awn
Security researcher and programmer.
Awn
DERO: Secure, Anonymous Blockchain with Smart Contracts. Subscribe to Dero announcements by sending mail to [email protected] with subject: subscribe announcements

Welcome to the Dero Project DERO News Forum Wiki Explorer Source Twitter Discord Github Stats WebWallet Medium Table of Contents ABOUT DERO PROJECT DE

null 256 Nov 30, 2021
fastrand implements a cryptographically secure pseudorandom number generator.

10x faster than crypto/rand. Uses securely allocated memory. The generator is seeded using the system's default entropy source, and thereafter produces random values via repeated hashing. As a result, fastrand can generate randomness much faster than crypto/rand, and generation cannot fail beyond a potential panic during init().

Awn 149 Dec 3, 2021
A simple, modern and secure encryption tool (and Go library) with small explicit keys, no config options, and UNIX-style composability.

A simple, modern and secure encryption tool (and Go library) with small explicit keys, no config options, and UNIX-style composability.

Filippo Valsorda 9.2k Nov 28, 2021
Get any cryptocurrencies ticker and trade data in real time from multiple exchanges and then save it in multiple storage systems.

Cryptogalaxy is an app which will get any cryptocurrencies ticker and trade data in real time from multiple exchanges and then saves it in multiple storage systems.

Pavan Shetty 79 Nov 26, 2021
A Go client and CLI for Filecoin Storage Auctions.

go-auctions-client A Go library and CLI to interact with Filecoin Storage Auctions. Join us on our public Slack channel for news, discussions, and sta

textile.io 3 Nov 1, 2021
An implementation of the Filecoin Distributed Storage Network

Project Lotus - 莲 Lotus is an implementation of the Filecoin Distributed Storage Network. For more details about Filecoin, check out the Filecoin Spec

null 0 Oct 27, 2021
Secure software enclave for storage of sensitive information in memory.

MemGuard Software enclave for storage of sensitive information in memory. This package attempts to reduce the likelihood of sensitive data being expos

Awn 2k Nov 27, 2021
ARP spoofing tool based on go language, supports LAN host scanning, ARP poisoning, man-in-the-middle attack, sensitive information sniffing, HTTP packet sniffing

[ARP Spoofing] [Usage] Commands: clear clear the screen cut 通过ARP欺骗切断局域网内某台主机的网络 exit exit the program help display help hosts 主机管理功能 loot 查看嗅探到的敏感信息

Re 6 Nov 6, 2021
Sensitive information protection toolkit

godlp 一、简介 为了保障企业的数据安全和隐私安全,godlp 提供了一系列针对敏感数据的识别和处置方案, 其中包括敏感数据识别算法,数据脱敏处理方式,业务自定义的配置选项和海量数据处理能力。 godlp 能够应用多种隐私合规标准,对原始数据进行分级打标、判断敏感级别和实施相应的脱敏处理。 In

Bytedance Inc. 17 Nov 26, 2021
Secure logger in Go to avoid output sensitive data in log

zlog A main distinct feature of zlog is secure logging that avoid to output secret/sensitive values to log. The feature reduce risk to store secret va

Masayoshi Mizutani 16 Dec 5, 2021
Easy to use cryptographic framework for data protection: secure messaging with forward secrecy and secure data storage. Has unified APIs across 14 platforms.

Themis provides strong, usable cryptography for busy people General purpose cryptographic library for storage and messaging for iOS (Swift, Obj-C), An

Cossack Labs 1.4k Nov 25, 2021
Easy to use cryptographic framework for data protection: secure messaging with forward secrecy and secure data storage. Has unified APIs across 14 platforms.

Themis provides strong, usable cryptography for busy people General purpose cryptographic library for storage and messaging for iOS (Swift, Obj-C), An

Cossack Labs 1.4k Dec 3, 2021
Mattermost is an open source platform for secure collaboration across the entire software development lifecycle.

Mattermost is an open source platform for secure collaboration across the entire software development lifecycle. This repo is the primary source for c

Mattermost 21.6k Dec 5, 2021
Implement a toy in-memory store information service for a delivery company

Implement a toy in-memory store information service for a delivery company

Ahmad Berahman 0 Nov 22, 2021
Fast, secure and efficient secure cookie encoder/decoder

Encode and Decode secure cookies This package provides functions to encode and decode secure cookie values. A secure cookie has its value ciphered and

Christophe Meessen 55 Nov 15, 2021
Speed up the memory allocation and improve the GC performance, especially for dynamic-memory-heavy applications.

Linear Allocator for Golang Goal Speed up the memory allocation and improve the GC performance, especially for dynamic-memory-heavy applications. Pote

crazybie 23 Nov 30, 2021
gpu-memory-monitor is a metrics server for collecting GPU memory usage of kubernetes pods.

gpu-memory-monitor is a metrics server for collecting GPU memory usage of kubernetes pods. If you have a GPU machine, and some pods are using the GPU device, you can run the container by docker or kubernetes when your GPU device belongs to nvidia. The gpu-memory-monitor will collect the GPU memory usage of pods, you can get those metrics by API of gpu-memory-monitor

null 1 Oct 26, 2021
EarlyBird is a sensitive data detection tool capable of scanning source code repositories for clear text password violations, PII, outdated cryptography methods, key files and more.

EarlyBird is a sensitive data detection tool capable of scanning source code repositories for clear text password violations, PII, outdated cryptograp

American Express 457 Nov 27, 2021
Parametrized JSON logging library in Golang which lets you obfuscate sensitive data and marshal any kind of content.

Noodlog Summary Noodlog is a Golang JSON parametrized and highly configurable logging library. It allows you to: print go structs as JSON messages; pr

Gyoza Tech 34 Nov 24, 2021
Golang JSON decoder supporting case-sensitive, number-preserving, and strict decoding use cases

Golang JSON decoder supporting case-sensitive, number-preserving, and strict decoding use cases

Kubernetes SIGs 8 Nov 22, 2021
Drone Plugin for detecting credentials or other sensitive data in your repository

A plugin to detect hard-coded secrets and sensitive data in your source code files. Building Build the plugin binary: scripts/build.sh Build the plug

Drone by Harness 1 Nov 9, 2021
A database connection tool for sensitive data

go-sql 用于快速统计数据库行数、敏感字段匹配、数据库连接情况。 usage ./go-sql_darwin_amd64 -h ./go-sql_darwin_amd64 -f db.yaml -k name,user ./go-sql_darwin_amd64 -f db.yaml --min

null 4 Nov 29, 2021
Jsonmask use for mask sensitive data from json format

Jsonmask use for mask sensitive data from json format Installation go get -u github.com/rkritchat/jsonmask Code example package main import ( "fmt"

rkritchat 1 Nov 25, 2021
CSI driver NVMf mainly supports RDMA and TCP for Software Defined Storage by NVMf

CSI NVMf driver Overview This is a repository for NVMe-oF CSI Driver. Currently it implements bare minimum of th CSI spec. Requirements The CSI NVMf d

Kubernetes CSI 20 Nov 29, 2021
Secure storage for personal records built to comply with GDPR

Databunker Databunker is a Personally Identifiable Information (PII) Data Storage Service built to Comply with GDPR and CCPA Privacy Requirements. Pro

null 923 Dec 2, 2021
TurtleDex is a decentralized cloud storage platform that radically alters the landscape of cloud storage

TurtleDex is a decentralized cloud storage platform that radically alters the landscape of cloud storage. By leveraging smart contracts, client-side encryption, and sophisticated redundancy (via Reed-Solomon codes), TurtleDex allows users to safely store their data with hosts that they do not know or trust.

TurtleDev 531 May 29, 2021
TurtleDex is a decentralized cloud storage platform that radically alters the landscape of cloud storage.

TurtleDex is a decentralized cloud storage platform that radically alters the landscape of cloud storage. By leveraging smart contracts, client-side e

TurtleDev 18 Feb 17, 2021
Rclone ("rsync for cloud storage") is a command line program to sync files and directories to and from different cloud storage providers.

Rclone ("rsync for cloud storage") is a command line program to sync files and directories to and from different cloud storage providers.

rclone 30.2k Dec 5, 2021