SRP_VBASE_NEW(3ossl)

📦
version 3.5.9 · 8 versions
, in fedora 43, fedora 44

💖 SRP_VBASE_NEW — aka the SRP user verifier stack glow-up (3ossl) 💖

okay bestie, gather round, because we're talking about the OpenSSL manual page SRP_VBASE_NEW(3ossl) and honestly? it's giving "legacy but make it cute". these are the functions that create and manage a stack of SRP user verifier information, and yes they're all deprecated, but we still gotta know them, iykyk 🫶

✨ NAME ✨

SRP_VBASE_new, SRP_VBASE_free, SRP_VBASE_init, SRP_VBASE_add0_user, SRP_VBASE_get1_by_user, SRP_VBASE_get_by_user — the little squad of functions that create and manage a stack of SRP user verifier information 🌸

🌈 SYNOPSIS 🌈

first things first, you gotta pull in the header:

#include <openssl/srp.h>
⚠️ heads up bestie: every single function on this page has been deprecated since OpenSSL 3.0, and you can hide them entirely by defining OPENSSL_API_COMPAT with a suitable version value. go peek at openssl_user_macros(7) for the deets 💅

here's the whole cast, in all their deprecated glory:

SRP_VBASE *SRP_VBASE_new(char *seed_key);
void SRP_VBASE_free(SRP_VBASE *vb);

int SRP_VBASE_init(SRP_VBASE *vb, char *verifier_file);

int SRP_VBASE_add0_user(SRP_VBASE *vb, SRP_user_pwd *user_pwd);
SRP_user_pwd *SRP_VBASE_get1_by_user(SRP_VBASE *vb, char *username);
SRP_user_pwd *SRP_VBASE_get_by_user(SRP_VBASE *vb, char *username);

🎀 DESCRIPTION 🎀

okay so, the whole situation here: all of the functions described on this page are deprecated. there are no available replacement functions at this time. that's it, that's the vibe, we move 😭

let's go one by one, bestie:

🦋 SRP_VBASE_new()

this one allocates a structure to store server side SRP verifier information. iconic.

  • if seed_key is not NULL, a copy is stored and used to generate dummy parameters for users that are not found by SRP_VBASE_get1_by_user().
  • why tho? so the server can hide the fact that it doesn't have a verifier for a particular username — exactly like it says in section 2.5.1.3 'Unknown SRP' of RFC 5054. sneaky, love that for us 💅
  • the seed string should contain random NUL terminated binary data… which means (and this is important!) the random data should not contain NUL bytes! 🚨

🧚 SRP_VBASE_free()

frees up the vb structure. and if vb is NULL? nothing happens. no drama, no crash, we simply do nothing, periodt ✨

🌸 SRP_VBASE_init()

this one parses the info in a verifier file and populates the vb structure.

the verifier file is a text file containing multiple entries, and the format of each entry is:

flag base64(verifier) base64(salt) username gNid userinfo(optional)

where flag can be:

  • 'V' — valid ✅
  • 'R' — revoked ❌
💀 ngl, important: the base64 encoding used here is non-standard, so it is recommended to use openssl-srp(1) to generate this file. don't hand-roll it, bestie.

👑 SRP_VBASE_add0_user()

adds the user_pwd verifier information to the vb structure. need to create and populate that record first? go see SRP_user_pwd_new(3) 🫶

⚠️ ownership tea: the library takes ownership of user_pwd, so it should not be freed by the caller. don't double-free, that's not the moment.

💜 SRP_VBASE_get1_by_user()

returns the password info for the user whose username matches username. it replaces the deprecated SRP_VBASE_get_by_user(). main character energy, honestly.

here's the juicy part:

  • if no matching user is found but a seed_key and default gN parameters have been set, dummy authentication information is generated from the seed_key, letting the server hide the fact that it doesn't have a verifier for a particular username 🙈
  • when using SRP as a TLS authentication mechanism, this will cause the handshake to proceed normally but the first client will be rejected with a "bad_record_mac" alert, as if the password was incorrect. gaslight gatekeep girlboss, I guess 💅
  • if no matching user is found and the seed_key is not set, NULL is returned.
  • ownership of the returned pointer is released to the caller, so it must be freed with SRP_user_pwd_free(). no leaks, bestie, we're better than that 🎀

⭐ RETURN VALUES ⭐

  • SRP_VBASE_init() returns SRP_NO_ERROR (0) on success and a positive value on failure. the error codes are:
    • SRP_ERR_OPEN_FILE — if the file could not be opened 📂
    • SRP_ERR_VBASE_INCOMPLETE_FILE — if the file could not be parsed 😵
    • SRP_ERR_MEMORY — on memory allocation failure 💀
    • SRP_ERR_VBASE_BN_LIB — for invalid decoded parameter values 🚩
  • SRP_VBASE_add0_user() returns 1 on success and 0 on failure. simple math, slay ✨

🌈 SEE ALSO 🌈

go read these too, they're all part of the lore:

📜 HISTORY 📜

the timeline, bestie:

  • SRP_VBASE_add0_user() was added in OpenSSL 3.0.
  • all other functions were added in OpenSSL 1.0.1.
  • all of these functions were deprecated in OpenSSL 3.0.

so yeah, they're old, they're deprecated, but they're still ours 🥲

Copyright 2018-2021 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

and that's the whole page, bestie!! 🫶✨ this was OpenSSL 3.5.9, dated 2026-09-29, and the manual page's name is SRP_VBASE_NEW(3ossl). mwah, go forth and please stop using deprecated functions 💅🎀🦋

📦 where this page comes from