[erlang-questions] Problem with legacy code when upgrading to R16B03

Ryan Brown ryankbrown@REDACTED
Fri Feb 20 17:48:06 CET 2015


Ok, I cannot make it break now. I'm perplexed as I had several engineers
look at it and test it. Argh!

Thank you for the educational comments. Whether on not this was a red
herring, I have learned a lot and I very much appreciate it.

Best regards.

On Thu, Feb 19, 2015 at 3:17 PM, Felix Gallo <felixgallo@REDACTED> wrote:

> 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?
>
> On Thu, Feb 19, 2015 at 1:11 PM, Ryan Brown <ryankbrown@REDACTED> wrote:
>
>> 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).
>>
>> 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.
>>
>> Best regards,
>>
>> Ryan
>>
>> On Thu, Feb 19, 2015 at 1:33 PM, Felix Gallo <felixgallo@REDACTED>
>> wrote:
>>
>>> 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' (
>>> http://en.wikipedia.org/wiki/Rubber_duck_debugging)).  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.
>>>
>>> For the purposes of this discussion I created a test() function:
>>>
>>> test() ->
>>>   X = <<1:128>>,
>>>   Y = <<1:53>>,
>>>   Z = <<1:1>>,
>>>   pad_binary_128(X),
>>>   pad_binary_128(Y),
>>>   pad_binary_128(Z).
>>>
>>> and then I run it like so:
>>>
>>> Eshell V6.1  (abort with ^G)
>>> 1> c(a),l(a),a:test().
>>> Line 100
>>> Line 97
>>> ** exception error: bad argument
>>>      in function  a:pad_binary_128/1 (a.erl, line 12)
>>>      in call from a:test/0 (a.erl, line 22)
>>>
>>> and see your error when I am trying to use a 53 bit bitstring.
>>>
>>> In this particular scenario that matches the clause:
>>>
>>> pad_binary_128(Data) when bit_size(Data) < 128 ->
>>>     io:format("Line ~p~n", [97]),
>>>     pad_binary_128(<<Data/binary,0:1>>);
>>>
>>> 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.
>>>
>>> As a debug step, let's break out the construction attempt from the
>>> function call:
>>>
>>> New = <<Data/binary,0:1>>;
>>> pad_binary_128(New);
>>>
>>> now we get the error at the constructor.  How exciting!
>>>
>>> So we turn to the documentation (
>>> http://www.erlang.org/doc/programming_examples/bit_syntax.html) 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> https://github.com/Cloven/bitpad128/blob/master/bit_example.erl
>>>
>>> F.
>>>
>>> On Thu, Feb 19, 2015 at 11:02 AM, Ryan Brown <ryankbrown@REDACTED>
>>> wrote:
>>>
>>>> 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.
>>>>
>>>> In a crude attempt to trace the issue down, I added a bunch of
>>>> io:formats and ran in the shell.
>>>>
>>>> pad_binary_128(Data) when bit_size(Data) > 128 ->
>>>>   io:format("Line ~p~n", [89]),
>>>>   {Kept, _Lost} = split_binary(Data, size(Data) - 1),
>>>>   io:format("Line ~p~n", [94]),
>>>>   pad_binary_128(Kept);
>>>> pad_binary_128(Data) when bit_size(Data) < 128 ->
>>>>   io:format("Line ~p~n", [97]),
>>>>   pad_binary_128(<<Data/binary,0:1>>);
>>>> pad_binary_128(Data) ->
>>>>   io:format("Line ~p~n", [100]),
>>>>   Data.
>>>>
>>>> This is the output I get:
>>>>
>>>> Line 97
>>>> ** exception error: bad argument
>>>>      in function  omac1:pad_binary_128/1 (src/omac1.erl, line 97)
>>>>      in call from omac1:cmac_aes_cbc_128/6 (src/omac1.erl, line 78)
>>>>
>>>> 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.
>>>>
>>>>
>>>> http://erldocs.com/R15B01/erts/erlang.html?i=0&search=erlang:bit#bit_size/1
>>>>
>>>> http://erldocs.com/R16B03/erts/erlang.html?i=0&search=erlang:bit#bit_size/1
>>>>
>>>> Thanks in advance.
>>>>
>>>> Best,
>>>>
>>>> Ryan
>>>>
>>>> On Tue, Feb 17, 2015 at 5:21 PM, Felix Gallo <felixgallo@REDACTED>
>>>> wrote:
>>>>
>>>>> I made your same changes to the module, and also added the following
>>>>> function to the module:
>>>>>
>>>>> test() ->
>>>>>   Key = <<1:128>>,
>>>>>   Data = <<1:128>>,
>>>>>   generate_tag_aes_cbc_128(Key, Data).
>>>>>
>>>>> and when run in a shell:
>>>>>
>>>>> Eshell V6.1  (abort with ^G)
>>>>> 1> c(omac1),l(omac1),omac1:test().
>>>>> <<173,219,62,66,7,255,149,96,196,74,41,116,238,229,211,35>>
>>>>>
>>>>> 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.
>>>>>
>>>>> On Tue, Feb 17, 2015 at 3:27 PM, Ryan Brown <ryankbrown@REDACTED>
>>>>> wrote:
>>>>>
>>>>>> 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)
>>>>>>
>>>>>> But alas, I'm still seeing the same error.
>>>>>>
>>>>>> On Tue, Feb 17, 2015 at 3:10 PM, Felix Gallo <felixgallo@REDACTED>
>>>>>> wrote:
>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> I suggest opening
>>>>>>>
>>>>>>> http://erldocs.com/R15B01/crypto/crypto.html
>>>>>>>
>>>>>>> and
>>>>>>>
>>>>>>> http://erldocs.com/R16B03/crypto/crypto.html
>>>>>>>
>>>>>>> and seeing if you can figure out where the changes occurred.  I
>>>>>>> suspect those are the cause of your badargs.
>>>>>>>
>>>>>>> F.
>>>>>>>
>>>>>>> On Tue, Feb 17, 2015 at 1:55 PM, Ryan Brown <ryankbrown@REDACTED>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hello all,
>>>>>>>>
>>>>>>>> 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:
>>>>>>>>
>>>>>>>> https://github.com/PearsonEducation/subpub/blob/master/src/omac1.erl
>>>>>>>>
>>>>>>>> For the life of me I cannot find the root cause. I am just
>>>>>>>> receiving a badarg error pointing to line 74.
>>>>>>>>
>>>>>>>> Any guidance would be greatly appreciated.
>>>>>>>>
>>>>>>>> Thank you.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> erlang-questions mailing list
>>>>>>>> erlang-questions@REDACTED
>>>>>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150220/2c4fdfb7/attachment.htm>


More information about the erlang-questions mailing list