<div dir="ltr"><div class="gmail_default" style="font-family:garamond,serif;font-size:large">If/when this is available, please post on the Crosswire facebook page. :-) I will promote it. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 30, 2019 at 6:31 PM Troy A. Griffitts <<a href="mailto:scribe@crosswire.org">scribe@crosswire.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Jaak,<br>
<br>
Thank you for pointing out one problematic input condition which passes<br>
the validation checks already in the code.<br>
<br>
Your statement that there is no validation on input is incorrect. There<br>
is validation on input. You found one case which passed those<br>
validation checks. An additional check has been added to handle your<br>
case of passing an empty personalization prefix to the depersonalization<br>
mechanism.<br>
<br>
We appreciate your reporting of this unvalidated scenario. If you find<br>
additional strings which cause issues, please continue to provide feedback.<br>
<br>
Regarding the publisher's reason for requesting personalized unlock<br>
codes, in their mind, a user is less likely to share their unlock code<br>
if it is, e.g.,<br>
<br>
RISTIOJAJA2019-wEt-lum-UIw-GlQN<br>
<br>
They know it does not provide any additional software protection.<br>
<br>
I agree with their reasoning that it is a disincentive to share one's<br>
unlock key if the origin of that shared key can be traced back to a user.<br>
<br>
Hope this makes sense,<br>
<br>
Troy<br>
<br>
<br>
On 10/30/19 3:30 PM, Jaak Ristioja wrote:<br>
> Hello!<br>
><br>
> On 29.10.19 23:42, Troy A. Griffitts wrote:<br>
>> #1 was included as an update to our engine with this commit:<br>
>><br>
>> commit f4ac4caeacd762c90c2b2cef5755bf745e3a6d58<br>
>> Author: scribe <scribe@bcd7d363-81e1-0310-97ec-a550e20fc99c><br>
>> Date: Sat Dec 29 21:23:25 2018 +0000<br>
>><br>
>> Added personalization mechanism for cipher keys<br>
>> git-svn-id: <a href="https://crosswire.org/svn/sword/trunk@3614" rel="noreferrer" target="_blank">https://crosswire.org/svn/sword/trunk@3614</a><br>
>> bcd7d363-81e1-0310-97ec-a550e20fc99c<br>
><br>
> As the maintainer of Sword++, I regularly merge in changes from Sword.<br>
> When this commit was made in 2018, I did not figure out why exactly it<br>
> was needed. Because the code also seemed suspicious, I decided not to<br>
> merge this commit into the Sword++ codebase at that point. Haven now<br>
> given it some additional thought, I'm even more sceptical.<br>
><br>
> The current implementation does not seem to provide any additional<br>
> security benefits. It could actually make things worse by providing a<br>
> false sense of security. Could you please explain why exactly the<br>
> "personal keys" logic is needed in the first place? What do the<br>
> stakeholders believe to gain?<br>
><br>
> On a more technical side, the function seems to make certain<br>
> undocumented presumptions about the input string. The function does<br>
> not validate its inputs and crashes in simple cases like in the<br>
> following:<br>
><br>
> SWBuf test("-asdf");<br>
> SWCipher::personalize(test, false); // SIGFPE !?<br>
><br>
> Since it is not acceptable for frontends to crash on invalid user<br>
> input, they would need to validate the input before passing it to this<br>
> function. How should they do that? What is the format for the input<br>
> string? Would it be possible document these requirements in the inline<br>
> code documentation for SWCipher::personalize() please?<br>
><br>
><br>
> Best regards,<br>
> J<br>
><br>
> _______________________________________________<br>
> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
> <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
> Instructions to unsubscribe/change your settings at above page<br>
<br>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page</blockquote></div>