<p>As a hobby right now, I am writing a fork of archive/zip to allow reading/writing of password protected .zip files that use Winzip's AES encryption method <a href="http://www.winzip.com/aes_info.htm" rel="nofollow">http://www.winzip.com/aes_info.htm</a>. There was a request for this feature <a href="https://forum.golangbridge.org/t/reading-password-protected-zip-archives/783" rel="nofollow">here</a> and on the golang issue tracker. But, I've hit a brick wall when it comes to the initialization vector used as input in to AES-CTR. I've written a small demo that helps explain my problem: <a href="http://play.golang.org/p/YTByCFClJZ" rel="nofollow">http://play.golang.org/p/YTByCFClJZ</a>. You will have to run this outside of the playground to work. But that example successfully decrypts the contents "Hello World\r\n".</p>
<p>My confusion comes from the lines:</p>
<pre><code>// Generate the IV (or counter?)
var iv [aes.BlockSize]byte
iv[0] = 1 // Why is this 1 instead of 0?!?!?!?
</code></pre>
<p>When I first implemented this I left off the iv[0]=1 which failed to decrypt the correct contents. It was just by chance that I decided to try out iv[0]=1 and it worked! The reason I'm confused is because all the information that I've read says that the IV (or counter) starts off at 0 not 1. See the 9th slide here: <a href="https://www.cs.jhu.edu/%7Eastubble/dss/winzip.pdf" rel="nofollow">https://www.cs.jhu.edu/~astubble/dss/winzip.pdf</a>. Maybe I have the IV and counter confused?</p>
<p>Anyone have any insights into this?</p>
<hr/>**评论：**<br/><br/>nindalf: <pre><p>The counter for Counter mode can start with any value, it doesn't need to be all 0s. The most important requirement is that a key is never reused with the same counter and that will certainly occur if we start with all 0s for each new plaintext.</p>
<p>As for why your counter in this case is 000...1, I'm not sure. They could have chosen it that way for whatever reason. However, the best practice would have been to generate a random 128-bit value.</p></pre>alexwhoizzle: <pre><p>Yea I'm not sure why its implemented the way it is, but I checked DotNetZip library for c# and confirmed what I was seeing. </p>
<p>I don't believe I need to worry about reusing the key+counter combo b/c a new key is generated from a password with a random salt for each file encrypted.</p></pre>
