← Back to Standards index

ViaThinkSoft Modular Crypt Format 1.x (VTS MCF1)

ViaThinkSoft/Webfan Standards Header

VIATHINKSOFT/WEBFAN                                         D. Marschall
SPECIFICATION No. 4                                         ViaThinkSoft
First Draft: 2023                                          20 April 2026


        === ViaThinkSoft Modular Crypt Format 1.x (VTS MCF1) ===

Abstract

  This document describes the Modular Crypt Format "VTS MCF1", which
  allows arbitrary hash values to be expressed and stored using the
  standardized MCF string structure.

Identification of this Document

   Revision:  2026-04-20
   State:     In Force
   Filename:  viathinksoft-std-0004-mcf1.txt
   URN:       urn:x-viathinksoft:std:0004:2026-04-20
   OID:       1.3.6.1.4.1.37476.3.0.1.1
              { iso(1) identified-organization(3) dod(6) internet(1)
                private(4) enterprise(1) 37476 specifications(3)
                misc(0) modular-crypt-format(1) vts-crypt-v1(1) }
   WEID:      P-SX0-3-0-1-1-5
   IETF/RFC:  (None)

Attachments

   Reference implementation in PHP:
   https://github.com/danielmarschall/php_utils/blob/master/
   vts_crypt.inc.php

Copyright Notice

   Copyright (c) 2023-2026 ViaThinkSoft and the persons identified as
   the document authors.  All rights reserved.

   Licensed under the terms of the Apache 2.0 License.

Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Introduction: Modular Crypt Format (MCF)

The Modular Crypt Format (MCF) is a standardized string format used to store password hashes in a self-describing way. Instead of just storing a raw hash, MCF encodes not only the hash itself but also the algorithm, parameters, and salt—all in a single structured string. This makes it easier for software systems to verify passwords without needing external metadata.

Structure and Components

An MCF string typically follows this general structure:

$id$parameters$salt$hash

Not all algorithms use every field, but the structure remains consistent enough to allow parsers to interpret it correctly.

How MCF Works

When a password is hashed using MCF:

  1. A hashing algorithm is selected (e.g., MD5, SHA-512, bcrypt).
  2. A random salt is generated.
  3. Optional parameters (like cost factors) are applied.
  4. The hash is computed.
  5. All of this information is encoded into a single MCF string.

During verification, the system reads the $id$ and parameters from the stored string, recomputes the hash using the same configuration, and compares the results.

Standardized Identifiers

MCF relies on standardized identifiers to specify the hashing algorithm. Some commonly used ones include:

These identifiers ensure that systems can correctly interpret which algorithm to use when validating a password.

Examples

Here are a few example MCF strings:

Each example embeds all required information for verification directly in the string.

OID-Based Identification

In addition to traditional identifiers like $1$, a more formal approach to defining MCF schemes is described in a book that assigns each format a unique Object Identifier (OID).

An OID is a globally unique hierarchical identifier used to name objects in a standardized way.

By associating each MCF variant with an OID, this system ensures there are no naming conflicts between different hashing schemes, even across independent implementations or future extensions.

Introduction: About ViaThinkSoft Modular Crypt Format 1.x (VTS MCF1)

ViaThinkSoft Modular Crypt Format

The ViaThinkSoft Modular Crypt Format is a Modular Crypt Format (MCF) variant identified by the Object Identifier (OID) 1.3.6.1.4.1.37476.3.0.1.1.

Format of VTS MCF1:

Structure

    $1.3.6.1.4.1.37476.3.0.1.1$a=<algo>[,ai=<algo-internal>],m=<mode>[,i=<iterations>]$<salt>$<hash>

Parameter a=<algo> and ai=<algo-internal>

a and ai are any valid hash algorithm (name scheme of PHP hash_algos() preferred), e.g.

NOT possible with VTS MCF are these hashes (because they have a special salt-handling and output their own crypt format):

ai=<algo-internal> is only required if m=<mode> uses the hash[...] formula (see below) and can be omitted if it is equal to a=<algo>.

Parameter m=<mode>

In VTS MCF 1.0, the mode can be one of these:

In MCF 1.1, the following modes were added:

The formulas for the new modes in VTS MCF 1.1 can be any custom formula with the following elements:

Example: m=hash[shbx(sp)] means that the hash will be Hash(Salt+Hash(Salt+Password)).

Parameter i=<iterations>

The parameter i can be omitted if 0.

It is required for m=pbkdf2 and m=pbkdf2[...].

For other modes it is optional, and implemented as follows:

Alphabet of salt and hash

Like most Crypt-hashes, and are Radix64 coded with alphabet './0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz' and no padding.

Link to the online specification: https://www.viathinksoft.de/std/viathinksoft-std-0004-mcf1.html

Reference implementation in PHP: https://github.com/danielmarschall/php_utils/blob/master/vts_crypt.inc.php

Test Vectors

Test vector 1:

Test vector 2:

Security Considerations

Hash values play a crucial role in various security contexts, such as password verification. For detailed guidance on securely managing hashes, please consult the relevant literature or documentation. Marschall [Page 4]

RA Considerations

References

Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, [https://www.rfc-editor.org/info/rfc2119](https://www.rfc-editor.org/info/rfc2119).

Informative References

None