Skip to content

Commit 2aaf7ef

Browse files
mealycppmealycpp
authored
Update index.html
Signed-off-by: Mohamed El-Hadedy <47838875+mealycpp@users.noreply.github.com>
1 parent b9b6b54 commit 2aaf7ef

1 file changed

Lines changed: 127 additions & 13 deletions

File tree

‎index.html‎

Lines changed: 127 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -58,20 +58,134 @@ <h2>🔐 Post-Quantum Cryptography (PQC)</h2>
5858
</div>
5959

6060

61-
<div class="section">
62-
<h2>Lightweight Cryptography</h2>
63-
<p><strong>Ascon</strong> (NIST’s 2023 lightweight standard) uses a sponge-based AEAD and hash design to encrypt/authenticate on tiny microcontrollers with minimal CPU, RAM, and power.</p>
64-
</div>
61+
<div class="section">
62+
<h2>🔒 Lightweight Cryptography</h2>
63+
64+
<p>
65+
While traditional ciphers like AES excel in data centers, they’re too heavy for tiny, battery-powered edge nodes.
66+
<strong>Lightweight cryptography</strong> fills that gap by delivering strong security with minimal footprint—CPU cycles, RAM, and power.
67+
</p>
68+
69+
<!-- Comparison: AEAD vs Block Ciphers -->
70+
<h3>AEAD vs. Block Ciphers</h3>
71+
<table>
72+
<tr><th>Feature</th><th>AEAD (e.g. Ascon)</th><th>Block Cipher + MAC (e.g. AES-GCM)</th></tr>
73+
<tr><td>Encryption + Auth</td><td>Single pass, atomic</td><td>Two steps (encrypt then tag)</td></tr>
74+
<tr><td>Code Size</td><td>≈2–5 kB</td><td>≈10–20 kB</td></tr>
75+
<tr><td>RAM Usage</td><td>≈200–500 bytes</td><td>≈1–2 kB</td></tr>
76+
<tr><td>Throughput</td><td>2–5 cycles/byte</td><td>10–15 cycles/byte</td></tr>
77+
<tr><td>Security Goal</td><td>Confidentiality & Authenticity</td><td>Confidentiality & Authenticity</td></tr>
78+
</table>
79+
80+
<!-- ASCON Deep Dive -->
81+
<h3>ASCON Internals</h3>
82+
<img src="assets/Ascon_sponge_diagram.png" alt="Ascon Sponge Diagram" style="display:block;margin:10px auto;max-width:400px;">
83+
<table>
84+
<tr><th>Property</th><th>Value</th></tr>
85+
<tr><td>Permutation Size</td><td>320 bits (5 x 64-bit lanes)</td></tr>
86+
<tr><td>Rate</td><td>64 bits / 8 bytes per absorption/squeeze</td></tr>
87+
<tr><td>Initialization Rounds</td><td>12</td></tr>
88+
<tr><td>Intermediate Rounds</td><td>6</td></tr>
89+
<tr><td>Finalization Rounds</td><td>12</td></tr>
90+
<tr><td>Key Size</td><td>128 bits (optional 256 bits)</td></tr>
91+
<tr><td>Nonce Size</td><td>128 bits</td></tr>
92+
<tr><td>Tag Size</td><td>128 bits</td></tr>
93+
<tr><td>Performance (Cortex-M4)</td><td>≈1 MB/s</td></tr>
94+
</table>
95+
96+
<p>
97+
ASCON’s design is built around a <em>sponge construction</em>, where data and keys are absorbed into an internal state
98+
that is repeatedly permuted. This single-pass approach (absorb-permute-squeeze) gives both encryption and
99+
authentication in one go, cutting code size and RAM needs by up to 50% compared with AES-GCM on the same hardware.
100+
</p>
101+
102+
<!-- Security Comparison -->
103+
<h3>Security Strength vs. Block Ciphers</h3>
104+
<table>
105+
<tr><th>Security Aspect</th><th>ASCON (128-bit key)</th><th>AES-128 (GCM)</th></tr>
106+
<tr><td>Bit-security</td><td>≥ 128 bits</td><td>128 bits</td></tr>
107+
<tr><td>Integrity Bound</td><td>2^64 forgery bound</td><td>2^64 forgery bound</td></tr>
108+
<tr><td>Resistance to Side-Channel</td><td>Simple permutation—easier to mask</td><td>Complex S-boxes—harder to mask</td></tr>
109+
</table>
110+
111+
<p>
112+
By choosing ASCON for Ptah’s edge modules, we ensure each micro-controller—or even a small FPGA slice—can
113+
authenticate and encrypt telemetry with minimal overhead, leaving headroom for sensor processing and control loops.
114+
</p>
115+
</div>
116+
117+
118+
<div class="section">
119+
<h2>⚙️ Orchestration Frameworks</h2>
120+
<p>
121+
Managing a distributed Edge-AI/PQC cluster requires a lightweight yet powerful orchestrator. Below we compare three leading container orchestration platforms on footprint, feature set, and resource utilization—then dive deeper into how GPU scheduling and CPU allocation work in K3s for drones and UGVs.
122+
</p>
123+
124+
<!-- Topology Diagram Placeholder -->
125+
<p style="text-align: center;">
126+
<img src="assets/orchestration_topology.png" alt="Cluster Topology Diagram" style="max-width:600px; width:100%;">
127+
</p>
128+
129+
<!-- Feature & Footprint Comparison -->
130+
<h3>Feature & Footprint Comparison</h3>
131+
<table>
132+
<tr><th>Framework</th><th>Binary Size</th><th>Memory Overhead<sup>1</sup></th><th>Supported APIs</th><th>Ideal Use Case</th></tr>
133+
<tr><td><strong>Docker Swarm</strong></td><td>~200 MB</td><td>~150 MB</td><td>Core Swarm, Stacks</td><td>Simple clusters & rapid prototyping</td></tr>
134+
<tr><td><strong>K3s</strong></td><td>~50 MB</td><td>~70 MB</td><td>Kubernetes v1.x (core)</td><td>Edge/IoT & power-constrained nodes</td></tr>
135+
<tr><td><strong>Kubernetes</strong></td><td>~1 GB+</td><td>~1 GB+</td><td>Full k8s API</td><td>Enterprise datacenters</td></tr>
136+
</table>
137+
<p><sup>1</sup> Memory measured as RSS of control-plane components on a baseline Pi 4.</p>
138+
139+
<!-- CPU & GPU Scheduling -->
140+
<h3>CPU & GPU Resource Allocation</h3>
141+
<p>
142+
In K3s, you can label nodes with <code>cpu</code> and <code>gpu</code> capacity, then request them in your Pod specs. Below is an example of how a PQC service and an AI inference service would request resources:
143+
</p>
144+
<pre><code># PQC signature service (runs on any CPU node)
145+
resources:
146+
requests:
147+
cpu: "0.5"
148+
memory: "256Mi"
149+
limits:
150+
cpu: "1"
151+
memory: "512Mi"
152+
153+
# AI inference service (runs on GPU-enabled node)
154+
resources:
155+
limits:
156+
nvidia.com/gpu: 1
157+
memory: "1Gi"
158+
</code></pre>
159+
160+
<!-- Performance Estimates -->
161+
<h3>Performance Estimates</h3>
162+
<table>
163+
<tr><th>Node Type</th><th>CPU Cores</th><th>Clock (GHz)</th><th>GPU Cores</th><th>Approx. Throughput</th></tr>
164+
<tr><td>Raspberry Pi CM4</td><td>4</td><td>1.5</td><td>–</td><td>~200 Dilithium ops/sec</td></tr>
165+
<tr><td>TRK1 (Rockchip RK3588)</td><td>8</td><td>2.4</td><td>–</td><td>~1 200 Dilithium ops/sec</td></tr>
166+
<tr><td>Jetson Nano</td><td>4</td><td>1.43</td><td>128 (Maxwell)</td><td>– GPU: ~500 ASCON ops/sec<br>– CPU: ~400 Dilithium ops/sec</td></tr>
167+
<tr><td>Jetson Orin NX</td><td>6</td><td>2.2</td><td>1024 (Ampere)</td><td>– GPU: ~5 000 ASCON ops/sec<br>– CPU: ~800 Dilithium ops/sec</td></tr>
168+
</table>
169+
170+
<!-- When to use which -->
171+
<h3>Which to Choose?</h3>
172+
<ul>
173+
<li>
174+
<strong>Drone Swarms (ClusterHat):</strong> K3s on Pi Zero W can run ultra-light pods (<code>cpu: "0.1"</code>) with Ascon AEAD for telemetry, preserving battery life.
175+
</li>
176+
<li>
177+
<strong>UGV / Rover Platforms (TuringPi + Orin NX):</strong> K3s with GPU scheduling enables offloading neural nets to Orin NX while still hosting PQC services on CM4 nodes.
178+
</li>
179+
<li>
180+
<strong>Hybrid Deployments:</strong> Leverage <code>nodeSelector</code> and <code>affinity</code> to ensure heavy workloads land on TRK1/Orin, and lightweight tasks run on Pi-class nodes.
181+
</li>
182+
</ul>
183+
184+
<p>
185+
By using K3s with fine-grained resource requests and node labels, you can orchestrate a heterogeneous cluster that maximizes both performance and power-efficiency—crucial attributes for computer architects designing next-generation edge-AI & space systems.
186+
</p>
187+
</div>
65188

66-
<div class="section">
67-
<h2>Orchestration Frameworks</h2>
68-
<ul>
69-
<li><strong>Docker Swarm:</strong> simple, ~200 MB footprint, basic features.</li>
70-
<li><strong>K3s:</strong> lightweight Kubernetes (~100 MB), ideal for drones/UGVs.</li>
71-
<li><strong>Kubernetes:</strong> full feature set, heavy (~1 GB+), enterprise-grade.</li>
72-
</ul>
73-
<p><em>K3s</em> was chosen to orchestrate containers across resource-constrained nodes while preserving rich scheduling and community support.</p>
74-
</div>
75189

76190
<div class="section">
77191
<h2>Hardware Architectures</h2>

0 commit comments

Comments
 (0)