<div dir="ltr">I also would find that surprising, and indeed your code seems to crash on 15B01 as well, at least with my inputs.  Is it possible that there is something else that happened along the way which is causing different inputs to be presented to the function, or some circumstance which is causing that branch to get triggered where it never has before?</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 19, 2015 at 1:11 PM, Ryan Brown <span dir="ltr"><<a href="mailto:ryankbrown@gmail.com" target="_blank">ryankbrown@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thank you for the excellent clarification Felix. This code was written five years ago and we are just trying to update the version of Erlang it's running on. Everything seems to run fine on R15B (has been in production w/o issue for five years). <div><br></div><div>So, while I was able to refactor the code to work, I suppose I am still scratching my head as to why this would have changed between R15 and R16. I've read the release readme and don't see anything obvious.</div><div><br></div><div>Best regards,</div><div><br></div><div>Ryan</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 19, 2015 at 1:33 PM, Felix Gallo <span dir="ltr"><<a href="mailto:felixgallo@gmail.com" target="_blank">felixgallo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>A constructive note: it's hard for readers (e.g. me) to reason about what's happening without a full, minimal failing test case, including the data you're passing in.  Just the act of creating a minimal failing test case is also a great debugging step that often illuminates/solves the problem (along the lines of 'rubber duck debugging' (<a href="http://en.wikipedia.org/wiki/Rubber_duck_debugging)" target="_blank">http://en.wikipedia.org/wiki/Rubber_duck_debugging)</a>).  For example, maybe you're passing in the wrong kind of data; that is very common and is frequently exposed when you type it in a second time and look at it.</div><div><br></div><div>For the purposes of this discussion I created a test() function:</div><div><br></div><div><div>test() -></div><div>  X = <<1:128>>,</div><div>  Y = <<1:53>>,</div><div>  Z = <<1:1>>,</div><div>  pad_binary_128(X),</div><div>  pad_binary_128(Y),</div><div>  pad_binary_128(Z).</div></div><div><br></div><div>and then I run it like so:</div><div><br></div><div><span><div>Eshell V6.1  (abort with ^G)</div></span><div>1> c(a),l(a),a:test().</div><div>Line 100</div><span><div>Line 97</div><div>** exception error: bad argument</div></span><div>     in function  a:pad_binary_128/1 (a.erl, line 12)</div><div>     in call from a:test/0 (a.erl, line 22)</div></div><div><br></div><div>and see your error when I am trying to use a 53 bit bitstring.</div><div><br></div><div>In this particular scenario that matches the clause:</div><span><div><br></div><div><div>pad_binary_128(Data) when bit_size(Data) < 128 -></div><div>    io:format("Line ~p~n", [97]),</div><div>    pad_binary_128(<<Data/binary,0:1>>);</div></div><div><br></div></span><div>this appears to me be an excessively clever attempt to right-pad the binary with zeroes.  In particular, the original author thought <<Data/binary,0:1>> would construct a binary with one zero to the right, and then recursion would continue until the string was 128 bits long.</div><div><br></div><div>As a debug step, let's break out the construction attempt from the function call:</div><div><br></div><div>New = <<Data/binary,0:1>>;</div><div>pad_binary_128(New);</div><div><br></div><div>now we get the error at the constructor.  How exciting!  </div><div><br></div><div>So we turn to the documentation (<a href="http://www.erlang.org/doc/programming_examples/bit_syntax.html" target="_blank">http://www.erlang.org/doc/programming_examples/bit_syntax.html</a>) and see that you will get badarg errors when you attempt to construct a binary that has an unaligned byte boundary -- e.g., anything not divisible by 8.  In this case, Data/binary could be attempting to convert an unaligned bitstring into a binary, which can't be done.</div><div><br></div><div>In order to fix the problem in a short term way, you could change that to <<Data/bitstring, 0:1>> and it would run fine.  But it also recurses for every single bit of padding, which is a little, ah, corkbrained.  </div><div><br></div><div>Better would be to refactor this code a little so it's a bit more sensible.  I am by no means an erlang grandmaster but here's how I personally would do it.  The specs pass dialyzer and there's a brief test suite that hits some of the high notes.</div><div><br></div><div><a href="https://github.com/Cloven/bitpad128/blob/master/bit_example.erl" target="_blank">https://github.com/Cloven/bitpad128/blob/master/bit_example.erl</a></div><span><font color="#888888"><div><br></div><div>F.</div></font></span><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 19, 2015 at 11:02 AM, Ryan Brown <span dir="ltr"><<a href="mailto:ryankbrown@gmail.com" target="_blank">ryankbrown@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Thank you Felix. I did get that to work standalone. It appears that there is something in the pad_binary method that I have not been able to track-down.<div><br></div><div>In a crude attempt to trace the issue down, I added a bunch of io:formats and ran in the shell.</div><div><br></div><div><div>pad_binary_128(Data) when bit_size(Data) > 128 -></div><div>  io:format("Line ~p~n", [89]),</div><div>  {Kept, _Lost} = split_binary(Data, size(Data) - 1),</div><div>  io:format("Line ~p~n", [94]),</div><div>  pad_binary_128(Kept);</div><div>pad_binary_128(Data) when bit_size(Data) < 128 -></div><div>  io:format("Line ~p~n", [97]),</div><div>  pad_binary_128(<<Data/binary,0:1>>);</div><div>pad_binary_128(Data) -></div><div>  io:format("Line ~p~n", [100]),</div><div>  Data.</div></div><div><br></div><div>This is the output I get:</div><div><br></div><div><div>Line 97</div><div>** exception error: bad argument</div><div>     in function  omac1:pad_binary_128/1 (src/omac1.erl, line 97)</div><div>     in call from omac1:cmac_aes_cbc_128/6 (src/omac1.erl, line 78)</div></div><div><br></div><div>So, it almost seems like there may be a difference in the way that bit_size/1 is handled in R1603. However, I do not see anything that stands-out to me in the docs.</div><div><br></div><div><a href="http://erldocs.com/R15B01/erts/erlang.html?i=0&search=erlang:bit#bit_size/1" target="_blank">http://erldocs.com/R15B01/erts/erlang.html?i=0&search=erlang:bit#bit_size/1</a><br></div><div><a href="http://erldocs.com/R16B03/erts/erlang.html?i=0&search=erlang:bit#bit_size/1" target="_blank">http://erldocs.com/R16B03/erts/erlang.html?i=0&search=erlang:bit#bit_size/1</a><br></div><div><br></div><div>Thanks in advance.</div><div><br></div><div>Best,</div><div><br></div><div>Ryan</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 17, 2015 at 5:21 PM, Felix Gallo <span dir="ltr"><<a href="mailto:felixgallo@gmail.com" target="_blank">felixgallo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">I made your same changes to the module, and also added the following function to the module:<div><div><br></div><div>test() -></div><div>  Key = <<1:128>>,</div><div>  Data = <<1:128>>,</div><div>  generate_tag_aes_cbc_128(Key, Data).</div></div><div><br></div><div>and when run in a shell:</div><div><br></div><div><div>Eshell V6.1  (abort with ^G)</div><div>1> c(omac1),l(omac1),omac1:test().</div><div><<173,219,62,66,7,255,149,96,196,74,41,116,238,229,211,35>></div></div><div><br></div><div>this appears to work (at least, it doesn't crash with badarg.  I don't know whether the data is correct).  Are you sure your aes key is 128, 192, or 256 bits long?  It's possible the crypto module is throwing badarg when it detects an improper length key.</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 17, 2015 at 3:27 PM, Ryan Brown <span dir="ltr"><<a href="mailto:ryankbrown@gmail.com" target="_blank">ryankbrown@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Thank you Felix. It looks like the aes_cbc_128_encrypt method is gone so I changed all to use crypto:block_encrypt(aes_cbc128, Key, IV, ToBeEncrypted)<div><br></div><div>But alas, I'm still seeing the same error.</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 17, 2015 at 3:10 PM, Felix Gallo <span dir="ltr"><<a href="mailto:felixgallo@gmail.com" target="_blank">felixgallo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">I'm not super familiar with the crypto library, but it looks like its function signatures changed significantly between 15B01 and 16B03.  In particular, it appears that some of the functions you are calling are no longer in the library, and have been replaced with equivalents.<div><br></div><div>I suggest opening </div><div><br></div><div><a href="http://erldocs.com/R15B01/crypto/crypto.html" target="_blank">http://erldocs.com/R15B01/crypto/crypto.html</a><br></div><div><br></div><div>and </div><div><br></div><div><a href="http://erldocs.com/R16B03/crypto/crypto.html" target="_blank">http://erldocs.com/R16B03/crypto/crypto.html</a><br></div><div><br></div><div>and seeing if you can figure out where the changes occurred.  I suspect those are the cause of your badargs.</div><div><br></div><div>F.</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Tue, Feb 17, 2015 at 1:55 PM, Ryan Brown <span dir="ltr"><<a href="mailto:ryankbrown@gmail.com" target="_blank">ryankbrown@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div dir="ltr">Hello all,<div><br></div><div>I am in the process of upgrading a legacy application from R15B01 to R16B03 in order to get SHA 384 support. However, I am getting an error creating my CMAC from the library located here:</div><div><br></div><div><a href="https://github.com/PearsonEducation/subpub/blob/master/src/omac1.erl" target="_blank">https://github.com/PearsonEducation/subpub/blob/master/src/omac1.erl</a><br></div><div><br></div><div>For the life of me I cannot find the root cause. I am just receiving a badarg error pointing to line 74.</div><div><br></div><div>Any guidance would be greatly appreciated.</div><div><br></div><div>Thank you.</div><div><br></div><div><br></div></div>
<br></div></div>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>