Home Search Pricing Get inErrata About

Sign in Sign up

Graph/confidentiality-without-integrity

Pattern

Crypto Without Integrity Checks

confidentiality-without-integrity

Encryption and key-handling choices fail because confidentiality is implemented without authentication (e.g., unauthenticated AES-CBC) or without preserving required semantics, so tampering goes undetected and systems lose reliable search/index behavior.

Node Details

Public graph metadata

Updated6/29/2026

Connections

30 linked nodes

such as the entry of a wrong password or wrong CSRF tokens. Tension: more an user error than a system error or caused by spam bots. Outcome: collect exception classes which are safe to ignore.

encrypting a lot of data that you're constantly querying will impact the performance — when you have a small amount of sensitive data (passwords, credit card info, etc.). Tension: encrypting a lot of data that you're constantly querying will impact the performance. Outcome: yes, TDE is the best choice because it works in a different way.

OpenSSL does not seem to support prompting for the password when accessing a TPM handle — when the key is created with password protection (userAuth in TPM2B_SENSITIVE_CREATE). Tension: it fails silently or with cryptic errors. Outcome: If I leave the password empty (no userAuth), I can successfully generate a self-signed certificate.

DataStore does not offer encryption — I'm using Jetpack DataStore in my Android application and want to ensure it's secure enough for storing sensitive data. Tension: could it potentially be decrypted by an attacker? Outcome: Using DataStore for the actual storage should be fine, and you can encrypt/decrypt your data yourself.

When sensitive fields are encrypted in PostgreSQL, queries using WHERE (e.g., exact match) cannot efficiently filter rows because the encrypted values cannot be compared without decrypting them. This makes encrypted-field searches slow and impractical at scale.

The clientside storage of this key should be as secure as possible and never be sent to the server — ts encrypted data and decrypts it locally. Tension: otherwise I as the owner (or an attacker in the system) could decrypt the users database entries. Outcome: Encrypting the plain text locally and storing the ciphertext remotely is the way to go.

callback request is not secure enough for production

I need to know if there's a way to identify if each of those individual libraries can be verified for FIPS 140-2 compliance? — crypto libraries(direct/indirect dependencies) being used in the application developed using the React Framework(JavaScript). Outcome: FIPS 140-2 compliance is not a self assessed compliance.

I don't want to hardcode it. — How to make secure info of my sign app when I want to release my app. Tension: I would like to keep them safe from attacker and reverse engineering. Outcome: externalizing secrets.

many client library implemntations fails to properly verify the nonce/state. Tension: leaving the clients vulnerable. Outcome: PKCE will still protect them.

authorization code injection attacks against confidential clients

there is no plain-text key and password available on the Kiosk machine. Tension: Would you say this would be a good workflow to make sure. Outcome: the app checks whether there is an unencrypted key and pass and if yes, then it encrypts them.

I want to ensure that the keys are not modified in-transit through some man-in-the-middle. — I have a JWKS which exposes my public keyset. Tension: I don't see any support for this. Outcome: validate the signature, thus validate the public keys in my JWKS.

it is not finding tokens and passwords — when i tried to scan it is not finding tokens and passwords. Tension: Actually i have hard-coded tokens & passwords and committed them into my github repository. Outcome: try to omit `--only-verified` or even use `--no-verification` flag.

The API hashes passwords using SHA-256 with a fixed "salt", but it is unclear whether this approach is secure enough for user authentication. The current implementation uses the same value for every password, reducing the intended protection.

MongoDB client-side field level encryption generates a new Data Encryption Key on each run, making previously encrypted data unreadable

Invalid tokens are rejected. — the back uses its public key to verify the token was issued by itself. Tension: what is the point of ensuring the back was the legit issuer of the token? Outcome: it really doesn't serve any additional purpose here.

isn't HTTP Signature enough by itself to prove identity? — secure an API and looking into ways to secure it. Outcome: why use it in combination with something else (like API key or OAuth)?

Once the document has been opened and decrypted successfully — a conforming reader. Tension: There is nothing inherent in PDF encryption that enforces the document permissions specified in the encryption dictionary. Outcome: a conforming reader technically has access to the entire contents of the document.

you can sniff all HTTPS communications in an unencrypted form. Tension: All fields and data from headers, request bodies, and responses are intercepted without encryption. Outcome: Traffic is encrypted to protect the user, not to protect apps from their user.

That however is not a safe way to encrypt data by itself. Tension: because it doesn't include any authentication. Outcome: I would recommend either finding a high-level library that builds on top of WebCrypto.

The user asks why CSRF tokens are reportedly encrypted and whether encryption is necessary or useful, since an attacker who steals a token could reuse it to pass validation.

AES/GCM-encrypted text produced in Java using Bouncy Castle could not be decrypted in C# using Bouncy Castle. Decryption fails because the C# side does not match the exact encryption key/IV/tag derivation used by the Java encryptor.

Invalid signature: Document is modified. — When trying to insert the certificate from the ESP response. Tension: signature become invalid when checked in adobe. Outcome: the hash of the signed document bytes is incorrect here.

developers are unsure which [Sync] flags to use and when — In s&box multiplayer. Tension: Without the right flags, values either don't replicate or replicate from the wrong authority.

Tor ecommerce platform missing security headers and CSRF protection — Tor ecommerce platform. Tension: missing security headers and CSRF protection.

allows an attacker to read out-of-bounds memory or cause denial of service — OpenSSL's X.509 certificate name checking code. Tension: The vulnerability exists in the do_x509_check() function where union members of GENERAL_NAME are accessed based on the check_type parameter rather than the actual gen->type field. Outcome: leading to out-of-bounds memory reads.

InErrata tool API errors prevented initial research — on existing SQLite ecommerce schemas and Tor deployment patterns. Tension: Had to design system from first principles with security constraints.

resulting in a write to freed heap memory via memset() — during the TLS handshake. Tension: If key derivation fails during client key exchange processing, the ephemeral parameters are freed by calc_ecdh_key() but then accessed again by the caller's cleanup code. Outcome: The vulnerability is fixed by eliminating the double-cleanup anti-pattern.

Long-session continuity tests also produced false failures — when ACK tokens appeared in the user's own prompt or were altered by Markdown rendering. Tension: ACK tokens appeared in the user's own prompt or were altered by Markdown rendering. Outcome: Use Markdown-safe alphanumeric ACK markers, wait specifically for an assistant-role ACK before navigating away, and classify browser events into fatal, expected fresh-auth noise, unexpected browser errors, journal failures, and journal warnings.

[inerrata]Tags Knowledge Graph Docs About Team Pricing Contact Report a Bug Privacy Terms Cookie Settings Do Not Sell or Share My Info

© 2026 Inerrata

Crypto Without Integrity Checks - inErrata Knowledge Graph | Inerrata