/*
 * CDDL HEADER START
 *
 * The contents of this file are subject to the terms of the
 * Common Development and Distribution License (the "Licence").
 * You may not use this file except in compliance with the Licence.
 *
 * You can obtain a copy of the licence at RISC OS path @.^.LICENCE
 * or  http://www.riscosdev.com/lanman98/LICENCE.CDDL
 * See the Licence for the specific language governing permissions
 * and limitations under the Licence.
 *
 * When distributing Covered Code, include this CDDL HEADER in each
 * file and include the Licence file. If applicable, add the
 * following below this CDDL HEADER, with the fields enclosed by
 * brackets "[]" replaced with your own identifying information:
 * Portions Copyright [yyyy] [name of copyright owner]
 *
 * CDDL HEADER END
 *   Portions Copyright RISC OS Developments 2019+, credited to the RISC OS One Project.
 */

/*
 *   NTLMv2 responses, as [MS-NLMP] section 3.3.2.
 *
 *   NTLMv1 keys the DES transform in c.smb directly off the password hash,
 *   which lets a server challenge be replayed and is refused by default by
 *   Samba, by Windows above LmCompatibilityLevel 2, and by macOS.  The v2
 *   scheme keys an HMAC off the hash and the account name instead, and
 *   mixes in a client challenge so the server cannot choose the whole
 *   input.
 *
 *   Nothing here touches the network or the operating system, so it can be
 *   checked against the published test values.
 */

#ifndef _NTLM_
#define _NTLM_

#define NTLM_HASH_LEN   (16)    /* MD4 of the password, and the v2 key */
#define NTLM_CHAL_LEN   (8)     /* server and client challenges alike */
#define NTLM_LMV2_LEN   (24)    /* an LMv2 response is always this long */

/*
    The smallest NTLMv2 response this builds: the 16 byte proof, the 28
    byte fixed part of the blob, an empty target information list and its
    4 byte terminator.
*/
#define NTLM_NTV2_MIN   (16 + 28 + 4 + 4)

void NTLMPasswordHash(char *passwd, unsigned char out[NTLM_HASH_LEN]);
/*
    MD4 of the password in UTF-16LE, which is what both the old and the new
    schemes are keyed on.  Called NTOWFv1 in the specification.
*/

void NTLMv2Key(char *user, char *domain,
               unsigned char nt_hash[NTLM_HASH_LEN],
               unsigned char key[NTLM_HASH_LEN]);
/*
    NTOWFv2: the key both responses are computed under.  nt_hash is the
    MD4 of the password in UTF-16LE, which is what NTLMv1 already uses.
    The user name is upper cased and the domain is taken as given, both
    widened to UTF-16LE, exactly as [MS-NLMP] specifies - get either wrong
    and the server computes a different key and rejects the logon.
*/

int NTLMv2Response(unsigned char key[NTLM_HASH_LEN],
                   char *challenge,
                   unsigned char *client_challenge,
                   unsigned int time_low, unsigned int time_high,
                   const unsigned char *target_info, int target_len,
                   unsigned char *out, int out_max);
/*
    Build the NTLMv2 response, returning its length, or 0 if out_max was
    too small.  time_low and time_high are a Windows FILETIME.  target_info
    may be NULL, which is the usual case here: a server only supplies one
    through extended security, which this dialect does not use.
*/

void LMv2Response(unsigned char key[NTLM_HASH_LEN],
                  char *challenge,
                  unsigned char *client_challenge,
                  unsigned char out[NTLM_LMV2_LEN]);
/*
    The LMv2 response, for the slot the LM response used to occupy.  It is
    not the old LM response under another name: that one is what servers
    with lanman auth disabled reject out of hand.
*/

#endif
