I was learning about the CPDB and saw that this is a central table that was originally empty.
I decided to migrate the local participants from my first survey to the CPDB. I had already added one custom attribute "attribute_1" to document per participant what company they are from.
From then on, I was no longer able to enter the CPDB because of the message in the Subject of this topic. I guess there is an issue with moving local participants with custom attributes to the CPDB. I have not yet logged this as an technical issue because I don't know how. I have been a member for a week now.
I would like to start over with the Participants. It's not a long list to rekey. What is the best way to get rid of this issue?
A>> Remove tables "lime_participant_attribute" "lime_participant_attribute_names" "lime_participant_attribute_names_lang" and "lime_participant_attribute_values"?
B>> Download my survey structures, then reinstall Lime and upload again?
C>> Somehow removing the reference to this attribute 1 elsewhere so that the CPDB no longer hits this problem and I can start over creating custom attributes directly in the CPDB.

Update; I thougth to be smart and went directly to /limesurvey/index.php/admin/participants/sa/attributeControl. I told the system to remove my custom attribute, but the message stays the same.

I encountered the same problem when trying to migrate local participants into the central participants database, no custom attributes involved though. So I don't think that these are part of the problem. I couldn't fix it for now.

If using the latest 3.x LTS or 4.x version, please file a bug report.

I've just encountered the same problem : I tried to add to CPDB two participants from an existing survey, and immediately after was not able to access the CPDB because "Argument 1 must be at least CRYPTO_SIGN_BYTES long".

Having direct access to the MySQL database, I identified and looked into the table named lime_participants, and saw that all other participants had their own "firstname" and "lastname" encrypted, whereas these fields were plainly readable (unencrypted) for the two participants transferred from my survey.

I had them manually removed (via the MySQL commands:

delete from lime_participants where firstname="Aaron";
delete from lime_participants where firstname="Zack";

) and the system started working again (i.e. I could again access the CPDB from the website).

I conclude that the script which transfers participants from one survey to the CPDB does not pre-encrypt the required fields.

Best,

Giuseppe.

tpartner wrote: If using the latest 3.x LTS or 4.x version, please file a bug report.

community.limesurvey.org/bug-tracker/

That was it. It must have something to do with the encryption tool "Sodium". As no participant names had been encrypted in my table, I have first exported the rows then truncated the table. Now I can enter the table again.

I am now continuing working with the central participants table and the tables for the surveys. I have tried to add a central participant to a survey. It gives me a garbled participant. I know it is the encrypted value of the participant from the central table. It tells me that the survey participants table is not encrypted and the values are stored as is.
I have checked the survey participants table and indeed encryption is off. The solution is to, per survey, set the attributes all to being encrypted.