Skip to content

[Bug]: hash_hkdf(): Argument #2 ($key) cannot be empty / HMAC does not match #34012

Description

@j-ed

⚠️ This issue respects the following points: ⚠️

  • This is a bug, not a question or a configuration/webserver/proxy issue.
  • This issue is not already reported on Github (I've searched it).
  • Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
  • Nextcloud Server is running on 64bit capable CPU, PHP and OS.
  • I agree to follow Nextcloud's Code of Conduct.

Bug description

After upgrading my server from Nextcloud v24.0.4 to v24.0.5 and also upgrading to PHP8 (I don't know if this is of importance), the Nextcloud cron job generates the following error output:

ValueError: hash_hkdf(): Argument #2 ($key) cannot be empty in .../lib/private/Security/Crypto.php:97
Stack trace:
#0 .../nextcloud/lib/private/Security/Crypto.php(97): hash_hkdf('sha512', '')
#1 .../nextcloud/lib/private/Security/IdentityProof/Manager.php(110): OC\Security\Crypto->encrypt('-----BEGIN PRIV...')
#2 .../nextcloud/lib/private/Security/IdentityProof/Manager.php(133): OC\Security\IdentityProof\Manager->generateKey('user-juergen')
#3 .../nextcloud/lib/private/Security/IdentityProof/Manager.php(146): OC\Security\IdentityProof\Manager->retrieveKey('user-juergen')
#4 .../nextcloud/lib/private/Security/IdentityProof/Signer.php(64): OC\Security\IdentityProof\Manager->getKey(Object(OC\User\User))
#5 .../nextcloud/apps/lookup_server_connector/lib/BackgroundJobs/RetryJob.php(150): OC\Security\IdentityProof\Signer->sign('lookupserver', Array, Object(OC\User\User))
#6 .../nextcloud/lib/public/BackgroundJob/Job.php(79): OCA\LookupServerConnector\BackgroundJobs\RetryJob->run(Array)
#7 .../nextcloud/apps/lookup_server_connector/lib/BackgroundJobs/RetryJob.php(113): OCP\BackgroundJob\Job->execute(Object(OC\BackgroundJob\JobList), Object(OC\Log))
#8 .../nextcloud/cron.php(151): OCA\LookupServerConnector\BackgroundJobs\RetryJob->execute(Object(OC\BackgroundJob\JobList), Object(OC\Log))
#9 {main}

Steps to reproduce

I don't know how to reproduce it at the moment but it seems to occur if notification should be send-out.

Expected behavior

Execute background job without running into an error condition.

Installation method

Community Manual installation with Archive

Operating system

No response

PHP engine version

PHP 8.0

Web server

Apache (supported)

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

Updated from a minor version (ex. 22.2.3 to 22.2.4)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

  • Default user-backend (database)
  • LDAP/ Active Directory
  • SSO - SAML
  • Other

Configuration report

## Environment
#### Server Configuration
OS: Linux 5.15.64
Web server: Apache2 2.4.53
Database: MariaDB 10.3.35
PHP version: 8.0.20
Nextcloud version: 24.0.5

#### Client Configuration
Browser: Mozilla Firefox 104.0.2
Operating system: Windows 10

List of activated Apps

Enabled:
  - accessibility: 1.10.0
  - activity: 2.16.0
  - admin_audit: 1.14.0
  - announcementcenter: 6.3.1
  - apporder: 0.15.0
  - audioplayer: 3.3.0
  - bookmarks: 11.0.1
  - bruteforcesettings: 2.4.0
  - calendar: 3.5.0
  - circles: 24.0.1
  - cloud_federation_api: 1.7.0
  - comments: 1.14.0
  - contacts: 4.2.0
  - contactsinteraction: 1.5.0
  - dav: 1.22.0
  - event_update_notification: 1.5.0
  - external: 4.0.0
  - federatedfilesharing: 1.14.0
  - federation: 1.14.0
  - files: 1.19.0
  - files_accesscontrol: 1.14.1
  - files_antivirus: 3.3.1
  - files_automatedtagging: 1.14.0
  - files_downloadactivity: 1.13.0
  - files_external: 1.16.1
  - files_pdfviewer: 2.5.0
  - files_photospheres: 1.24.1
  - files_retention: 1.13.2
  - files_rightclick: 1.3.0
  - files_sharing: 1.16.2
  - files_trashbin: 1.14.0
  - files_versions: 1.17.0
  - files_videoplayer: 1.13.0
  - firstrunwizard: 2.13.0
  - groupfolders: 12.0.1
  - guests: 2.2.0
  - impersonate: 1.11.0
  - logreader: 2.9.0
  - lookup_server_connector: 1.12.0
  - mail: 1.13.8
  - maps: 0.2.1
  - metadata: 0.16.0
  - news: 18.1.1
  - nextcloud_announcements: 1.13.0
  - notes: 4.5.1
  - notifications: 2.12.1
  - notify_push: 0.4.0
  - oauth2: 1.12.0
  - password_policy: 1.14.0
  - photos: 1.6.0
  - previewgenerator: 5.0.0
  - privacy: 1.8.0
  - provisioning_api: 1.14.0
  - serverinfo: 1.14.0
  - settings: 1.6.0
  - sharebymail: 1.14.0
  - smb_test: 0.3.4
  - spreed: 14.0.4
  - suspicious_login: 4.2.0
  - systemtags: 1.14.0
  - tasks: 0.14.4
  - text: 3.5.1
  - theming: 1.15.0
  - twofactor_backupcodes: 1.13.0
  - twofactor_gateway: 0.20.0
  - twofactor_totp: 6.4.0
  - twofactor_webauthn: 0.3.1
  - unsplash: 1.2.5
  - updatenotification: 1.14.0
  - user_status: 1.4.0
  - viewer: 1.8.0
  - workflow_script: 1.9.0
  - workflowengine: 2.6.0
Disabled:
  - dashboard: 7.0.0
  - encryption
  - epubreader: 1.4.7
  - files_trackdownloads: 1.11.0
  - recommendations: 0.6.0
  - support: 1.4.0
  - survey_client: 1.1.0
  - twofactor_admin: 3.2.0
  - user_ldap
  - weather_status: 1.0.0

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

.

Additional info

.

Activity

  1. added
    0. Needs triagePending check for reproducibility or if it fits our roadmap
    on Sep 10, 2022
  2. solracsf commented on Sep 11, 2022

    @solracsf
    Member

    Do you have a 'secret' value on your config.php file?

  3. j-ed commented on Sep 11, 2022

    @j-ed
    ContributorAuthor

    @solracsf Thank you, it seems that the parameter got lost somehow during one of the last couple of updates. I've now added the parameter again and will report if the error reappears again.

  4. CarlSchwan commented on Sep 12, 2022

    @CarlSchwan
    Member

    If secret is missing, you will see this error. Once you add it back, it should work again.

    Please reopen this issue if it happens again after adding the secret parameter

  5. j-ed commented on Sep 12, 2022

    @j-ed
    ContributorAuthor

    @CarlSchwan The problem seems to be more complex than I expected at the beginning. I found out that the secret parameter hasn't been set in the past at all on the server so that an empty value was used for encrypting passwords etc. The system excepted that setting and never complained about an empty value before.
    If I set 'secret' => '', in the configuration the displayed exception changes as follow - what is understandable somehow.

    ... -","app":"cron","method":"","url":"/cron.php","message":"hash_hkdf(): Argument #2 ($key) cannot be empty",
    

    Next I've provided a value to the secret parameter to get rid of the reported messages. As expected this had a bigger impact on the server because all application passwords and mount passwords hd to be changed. I tried to get this done and was able to successfully set new app passwords but I was unable to access my personal external storage anymore. As soon as I access the external storage configuration page I get an exception displayed on the screen with the recommendation to check the server log file.
    The server log files shows a HMAC does not match. exception, independently if mounts exists or not. So by setting a value for the secret parameter external storages got unusable. Now I'm sitting between two chairs and can only tell you that the incompatibility seems to have been introduced with NC 24.0.5.

  6. reopened this on Sep 12, 2022
  7. solracsf commented on Sep 12, 2022

    @solracsf
    Member

    Secret is used in many places.
    There are PRs ongoing about this:

    #31499
    #31492

  8. CarlSchwan commented on Sep 13, 2022

    @CarlSchwan
    Member

    #31499 is working and you can apply the patch. The reason why it is wip is that we wanted to have a migration step in the background adding the secret if it was missing :(

    I'll try to revive the branches

  9. self-assigned this
    on Sep 13, 2022
  10. j-ed commented on Sep 16, 2022

    @j-ed
    ContributorAuthor

    @CarlSchwan Unfortunately I've already fixed the problem on my server. After setting the 'secret' parameter in the configuration I truncated the `oc_storages_credentials' table, which allowed me to access the external storage settings again and to enter new credentials. After that I had to set all application passwords again because the previously generated once didn't work anymore. Additionally I had to reconnect the TOTP applications of my users again. Finally I had to drop all mail tables and reinstalled the mail app to get it up-and-running again. For now it seems to work. Nevertheless the provided patch will be the right way to go, because otherwise many systems will most likely left in an insecure state.

  11. CarlSchwan commented on Oct 17, 2022

    @CarlSchwan
    Member

    I merged the related PR

  12. denics commented on Dec 12, 2022

    @denics
  13. 58 remaining items

  14. denppa commented on Jan 4, 2025

    @denppa

    @joshtrichards

    I hit this bug when I tried to decrypt some e2e encrypted files on my mobile nextcloud client.

    The database was migrated, but I didn't copy over the old config.php in its entirety, which made certain things run with a newly generated 'secret' for a while before I finally copied the new one over.

    As I did not use external storage, not much else seemed to be affected aside from the inability to decrypt an e2e encrypted folder.

    I have also reset the user's e2d keys in hopes that the new keys would be encrypted by the restored 'secret', but this problem still occurs. Could the newly generated 'secret' be cached in the database somewhere and need to be removed in order for the instance to complete the migration?

  15. bkilinc commented on Feb 1, 2025

    @bkilinc

    Because of same problem, I am stucked to version '29.0.4.1'. Cannot upgrade. Previously; I moved from VM installation to Docker. I moved nextcloud data directory out of '/var/www'. These are the Errors I get, during upgrade.

    nextcloud  | Setting log level to debug
    nextcloud  | Turned on maintenance mode
    nextcloud  | Updating database schema
    nextcloud  | Updated database
    nextcloud  | Updating <oauth2> ...
    nextcloud  | An unhandled exception has been thrown:
    nextcloud  | ValueError: hash_hkdf(): Argument #2 ($key) cannot be empty in /var/www/html/lib/private/Security/Crypto.php:168
    
  16. Flachzange commented on Mar 2, 2025

    @Flachzange

    I ended up in the same situation doing a manual migration from Truecharts (v29) to Truenas app (v31). My mistake was to not copy over the old secret.

    I tried to fix it a couple fo times, but it seems a few more steps were required. I started all over again to migrate from scratch, i.e. database and user data. I also kept the old "instanceid" in the config. Now it seems to work.

    So in the end not a bug but rather not following the process properly.

  17. openstudio-one commented on Mar 24, 2025

    @openstudio-one

    I ended up in the same situation, but my secret is present in the config.php file

    Message: hash_hkdf(): Argument #2 ($key) must not be empty in file '/customers/f/d/9/DOMAIN/httpd.www/cloud/lib/private/Security/Crypto.php' line 147
    File: /customers/f/d/9/DOMAIN/httpd.www/cloud/lib/private/AppFramework/Http/Dispatcher.php
    Line: 146
    
  18. come-nc commented on Apr 14, 2025

    @come-nc
    Contributor

    @bkilinc Please do not publicly advise to delete data from random tables in Nextcloud, people may break their installation or lose data.

  19. bkilinc commented on Apr 14, 2025

    @bkilinc

    do not publicly advise to delete data from random tables in Nextcloud, people may break their installation or lose data.

    I deleted them

  20. lectrician1 commented on May 12, 2025

    @lectrician1

    I had this error with Nextcloud All-in-One and there was already a secret in my config.php. This was likely caused by when I migrated from a previous installation that had external storage points to All in one, which gave me a new secret and thus the info abou the old points could not be decrypted.

    I didn't need the old mount points so I solved the error with the below which deletes all information regarding the old mount points.

    docker exec -it nextcloud-aio-database psql -U oc_nextcloud -d nextcloud_database
    
    TRUNCATE TABLE oc_storages_credentials;
    
  21. florian-thoni-pandata commented on Jul 15, 2025

    @florian-thoni-pandata

    Due to an error in a migration, I had also ran for a few time with a wrong secret. Though I was not using at all any external drive or encryption.

    On my side, the problem generating the hash_hkdf() armgument #2 cannot be empty was a password for a user that got generated at this time and never changed.

    By changing it, I have solved the issue and I never have anymore any issue with it.

    I would be highly in favor of a tool in occ to list all inconstistent elements (storages, encrypted files, passwords) for which the secret is missing, which would simplify the manual remediation, and in addition some recommandations on what to do to resolve and the associated cavehats (removing the external storage, changing the password, re-uploading the file, …)

  22. shelterx commented on Sep 29, 2025

    @shelterx

    I have this error too, no idea if the secret changed during some previous upgrade. If it did, any backups is gone since then.
    So how do I fix it?

  23. melroy89 commented on Oct 10, 2025

    @melroy89
    Contributor

    Do you have a 'secret' value on your config.php file?

    Yes

    Running NC32.. error in html/lib/private/Security/Crypto.php' line 147

    However, maybe this could be a simple issue like when a user emptied their cookies and local cache in the web browser.. or not??

  24. denics commented on Dec 20, 2025

    @denics

    I confirm the issue and the solution in #34012 (comment) for version 31.x.x

  25. tyzbit commented on Dec 24, 2025

    @tyzbit

    #34012 (comment) worked for me as well.

    For those who are skimming the code in the comment and don't see an immediate difference to the file you have (especially since the Line 132 link in that comment goes to a different line of code now after some changes), do a diff. For me, the critical change is now on line 100 of my file:

                if ($password === '') {

    changes to:

                if ($password === $secret) {
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions