Bug 545 - Reentrant Fallback method invocation occured. on some Unicode string
Summary: Reentrant Fallback method invocation occured. on some Unicode string
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: 4.x
Hardware: Other Mac OS
: --- major
Target Milestone: Untriaged
Assignee: Sebastien Pouliot
Depends on:
Reported: 2011-08-30 13:52 UTC by René Ruppert
Modified: 2011-08-31 08:51 UTC (History)
4 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Comment 2 Sebastien Pouliot 2011-08-30 14:09:45 UTC
Interesting, this happens with Mono master (and likely on 2.10 since this affects MonoTouch too) but it was working in Mono 2.6.7.
Comment 3 René Ruppert 2011-08-30 14:10:59 UTC
Do you think it is an easy fix? Because then I can stop looking for an alternative.
Comment 4 Sebastien Pouliot 2011-08-30 14:44:56 UTC
This is an encoding issue (unrelated to the crypto code). Try adding a C.WL
after calling GetString, e.g.

            string sResult = oEncoding.GetString (bHash);
Console.WriteLine (sResult);
            return sResult;

and the same exception will now occurs inside Console.WriteLine.

You're trying to build a string out of a random stream of bytes and I'm pretty
sure that's not (always) legal Unicode-wise even if, in this case, MS.NET
accept it (which does not mean it's a legal string). c.c. Atsushi as he knows a
lot more on this subject than me.

Back to your original code I don't understand why:

a) you're not passing the string directly to Rfc2898DeriveBytes. The algorithm
is designed to accept strings and produce random bytes from it. Preprocessing
the input string does not give you any more security;

b) (if you pre-process) you're not using the Rfc2898DeriveBytes constructor
that accept a byte[] (instead of constructing a new string instance). That
would skip the unicode encoding (which only takes extra time, but does not add
any security) and would not hit the bug (if it's a legal string).

If you look for an alternative then I suggest (a) over (b).
Comment 5 Atsushi Eno 2011-08-31 00:48:24 UTC
I could summarize the issue within one line of code:

Encoding.UTF8.GetBytes ("\uDE7E\uDE7E");

This is an issue in UTF8Encoding with EncoderReplacementFallbackBuffer, which is *enabled* in mono 2.10 (the patch was originally from JB, https://github.com/mono/mono/commit/f4aff310cfdee02ccf672c648d9736dd386274df#mcs/class/corlib/System.Text ) and thus it didn't happen in 2.6.*.
Comment 6 Atsushi Eno 2011-08-31 01:06:34 UTC
I committed fixes in git master (5b18ed7) and mono-2-10 (059a6a6).

Aside from the bug existence, I discourage your usage of this pseudo-cryptic UTF bytes. The Unicode encoder replaces invalid bytes (in UTF8 context) into *empty* string, which means, your input string just becomes shorter (sort of insecure).
Comment 7 René Ruppert 2011-08-31 03:24:09 UTC
I will give your proposal a try. Could somebody please explain what it means  that this "fallback buffer" stuff was "enabled" in 2.10?
Comment 8 Atsushi Eno 2011-08-31 04:23:37 UTC
Encoder fallback feature is explained here: http://msdn.microsoft.com/en-us/library/ms404377.aspx#fallbackstrategy
It's just that the fallback implementation existed earlier but was not used until 2.10.
Comment 9 René Ruppert 2011-08-31 04:28:58 UTC
I see. But that means that this implementaion of the fallback strategy had a bug and that's what you fixed now. Correct?
Comment 10 Atsushi Eno 2011-08-31 04:48:25 UTC
Yes, exactly :)
Comment 11 Sebastien Pouliot 2011-08-31 08:48:32 UTC
Thanks Atsushi! I've cherry-picked this into monotouch (mobile-master) for future releases. 

However I urge Rene not to depend on this fix since all invalid strings will be empty, hence they will all share the same password using your current code (and that would be very insecure). Please adopt 'a' (or something similar) for your application and note that 'b' is not better since it will be using an empy byte array, representing the empty sting.
Comment 12 René Ruppert 2011-08-31 08:51:00 UTC
Understood and I will adopt "a".