小编How*_*owl的帖子

在PHP中,mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_CBC);返回值32,因此显然说AES-256需要32字节的初始化向量.但是,这是欺骗,在上述征求意见mcrypt_encrypt:

此外,MCRYPT_RIJNDAEL_256它不是AES-256,它是Rijndael分组密码的不同变体.如果您想在mcrypt中使用AES-256,则必须使用MCRYPT_RIJNDAEL_12832字节密钥.OpenSSL使您更明显地使用哪种模式(即'aes-128-cbc'vs'aes-256-ctr').

当然,对于32字节的IV,以下示例在Go中不起作用(它引起恐慌).

score := decodePost(c.PostForm("score"))
iv := decodePost(c.PostForm("iv"))

aesKey := getAESKey()
baseAES, err := aes.NewCipher([]byte(aesKey))
if err != nil {
    c.AbortWithError(500, err)
    return
}
block := cipher.NewCBCDecrypter(baseAES, []byte(iv))
block.CryptBlocks(score, score)

引用文档crypto/cipher:

iv的长度必须与Block的块大小相同,并且必须与用于加密数据的iv匹配.

(当然,Go中的AES块大小为16字节).

那么,最后,我如何在Go中解密这样的字符串？

在struct panics的字段上调用atomic.AddInt64 invalid memory address or nil pointer dereference,但是当我们重新排列字段顺序时不会; 为什么？

使用此类型:

type CountHandler struct {
    c     *RequestContext
    count int64
}

并且在此时调用atomic.AddInt64(&countHandler.count, 1)(字段c为零)恐慌.但是当我们将其重写为:

type CountHandler struct {
    count int64
    c     *RequestContext
}

错误消失了.

我想它应该是这样,因为Go以顺序方式将数据保存在内存中并且达到一个nil值会破坏这个序列(字节); 但我想知道为什么会这样,因为指针应该有固定的大小nil或其他值.

这是Windows上的Go x86 1.4.2并且完整的错误消息是:

2015/02/23 12:56:44 http: panic serving [::1]:51886: runtime error: invalid memory address or nil pointer dereference
goroutine 5 [running]:
net/http.func·011()
        c:/go/src/net/http/server.go:1130 +0xa8
sync/atomic.AddUint64(0x731144, 0x1, 0x0, 0x0, 0x263168)
        c:/go/src/sync/atomic/asm_386.s:118 +0xc
main.(*CountHandler).ServeHTTP(0x731140, 0x263180, 0x122f6380, 0x122f62a0)
        C:/Workshop/Devox/Workshop-Go/src/geoho/web/app/app.go:62 +0x42 …