[erlang-questions] Problem with legacy code when upgrading to R16B03
Ryan Brown
ryankbrown@REDACTED
Thu Feb 19 22:11:20 CET 2015
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/20150219/b16127e2/attachment.htm>
More information about the erlang-questions
mailing list