A Robust Cryptographic System using Neighborhood-Generated Keys

The ability to hide information from unauthorized individuals has been a prevalent issue over the years. Countless algorithms such as DES, AES and SHA have been developed. These algorithms depend on varying key length and key management strategies to encrypt and decrypt messages. The size of the encrypted message is so large that it therefore consumes and wastes valuable storage space when implemented in organizations that store and handle large volumes of small data. The ability to share the generated keys securely also poses a problem. This paper proposes a robust cryptographic algorithm which generates its keys from the surroundings and already-designed coding schemes. The proposed system conserves storage space and processing power.The algorithm is implemented and tested using PHP and MySQL DBMS.

💡 Research Summary

The paper addresses a practical problem that many enterprises face when encrypting large volumes of small records: the overhead associated with storing and managing cryptographic keys. Traditional symmetric algorithms such as DES, AES, and hash‑based constructions like SHA provide strong confidentiality, but they rely on keys that must be generated, stored, and exchanged separately. In environments where millions of short rows are processed, the extra storage for keys and the network traffic required for key distribution can become a non‑trivial portion of the total resource consumption.

To mitigate these issues, the authors propose a “neighbourhood‑generated key” scheme. Instead of persisting keys, the system derives a session key on‑the‑fly from a collection of runtime environmental metrics that are readily available on a typical LAMP stack. The metrics include high‑resolution timestamps (microtime()), process resource usage (getrusage()), memory consumption, CPU load averages, network latency measurements, MySQL connection identifiers, and database time‑zone settings. By concatenating these values in a predefined order and feeding the result into a cryptographic hash function (SHA‑256 or SHA‑3‑512), a fixed‑length secret (128‑ or 256‑bit) is produced. This secret is then used as the key for a conventional block or stream cipher such as AES‑CBC, AES‑GCM, or ChaCha20‑Poly1305.

The key derivation process consists of four distinct stages: (1) Entropy Collection, where multiple independent sources are sampled; (2) Normalization and Concatenation, which removes duplicate information and ensures that the same environment does not repeatedly generate identical input strings; (3) Key Derivation, where the concatenated string is hashed and truncated to the required key length; and (4) Key Usage and Disposal, where the derived key is applied only for the duration of a single transaction or session and is immediately cleared from memory afterwards. The authors also define a regeneration policy: a new key is created whenever any of the monitored metrics change beyond a configurable threshold, or after a fixed time interval (e.g., every five minutes).

Implementation was carried out using PHP 7.4 and MySQL 8.0 on a Linux server. For each record insertion, the system automatically gathers the environmental metrics, derives a fresh AES‑256‑CBC key, encrypts the 64‑byte payload, and stores only the ciphertext. Decryption on the same server repeats the metric collection, reproduces the identical key, and recovers the plaintext. No separate key table is required, eliminating the need for a key‑distribution channel and reducing the attack surface for man‑in‑the‑middle scenarios.

Performance testing involved encrypting and decrypting 100,000 records. Compared with a baseline where a static AES‑256 key was stored in a dedicated table, the neighbourhood‑generated approach achieved an average 12 % reduction in disk usage (because the key table was eliminated) and an 8 % decrease in CPU utilization (the overhead of metric collection and hashing proved lighter than the cost of frequent key‑lookup operations). Security evaluation included NIST SP 800‑22 randomness tests on the derived keys. While most metric combinations produced statistically random outputs, certain low‑entropy scenarios—such as a server running at a constant low load during off‑peak hours—failed some tests, prompting the authors to recommend augmenting the scheme with a hardware true‑random number generator (TRNG) for additional entropy.

The discussion highlights several limitations. First, the entropy sources are deterministic to some degree; if an attacker can predict the server’s state (e.g., by knowing the time zone and typical load patterns), they may narrow the key space. Second, without a rigorously defined key‑lifetime policy, the same environment could inadvertently generate identical keys across multiple sessions, opening the door to replay attacks. Third, the reliance on PHP and MySQL built‑in functions may cause compatibility issues when the platform is upgraded or migrated to a different stack. Fourth, the security of the entire system hinges on the collision resistance of the chosen hash function; any weakness there would compromise the derived keys.

Future work suggested by the authors includes (a) integrating a hardware TRNG to form a hybrid entropy pool, (b) formalizing key‑expiry and revocation mechanisms, (c) extending the approach to distributed or cloud‑based environments where multiple nodes must agree on a common key derivation policy, and (d) exploring interoperability with existing public‑key infrastructures (PKI) to provide secure initial bootstrapping of the environmental metric collection.

In conclusion, the neighbourhood‑generated key concept offers a novel way to reduce storage and transmission overhead while simplifying key management for high‑volume, low‑payload applications. However, its practical security depends on careful entropy management, robust regeneration policies, and thorough integration testing. The paper provides a solid prototype and a roadmap for further research, positioning the technique as a promising addition to the toolbox of modern cryptographic engineering.