Enc: en krypterad meddelandetjänst baserat på engångslänkar

Meddelandet och filerna som skickas till servern, krypteras innan de sparas i databasen (funktionen som används är endecrypt()), som det ska vara. Sen är uppkopplingen till webbsidan krypterad också, tack vare HTTPS. Om anslutningen inte är HTTPS utan HTTP, så får jag läsa på någonstans om hur jag löser det.

Hanlon? Hanlons?

Uppdatering
Läste nu att 302-statuskoden är en överföring som görs med http/1.1 (precis som i din skärmdump och när jag själv kollade i min webbläsare). Källa: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/302. Ska se vad jag kan göra åt saken. Om du har några tips, dela gärna med dig.

Jag har ännu inte lärt mig hur man skickar något via helvägskryptering (E2EE). Jag har noll intresse av att läsa det andra skriver till varann. Men om ni inte litar på mig, så kan ni enkelt ladda hem filerna från Codeberg (direktlänk till nedladdningslänken: https://codeberg.org/airikr/enc/archive/main.zip) och använda tjänsten på eran egna server.

Tack

Jo, det går att lita på tjänsten om man har den på sin egna server. Men sen att andra inte litar på den, kan jag mycket väl förstå. Gällande Signal. Ja, de har kokat ihop en fin lösning, som även OMEMO använder sig av.

Tack igen. Ska göra mitt bästa

Har sökt runt en hel del och allt jag får veta, även om sökfrasen är "how to use ssl in post" eller liknande, är att man ska använda SSL för att säkert skicka datan via en POST. Ingen berättar hur jag löser det hela, mer än att lägga in använda hela adressen med https://, vilket jag nu gör. Men datan skickas fortfarande med 302-statuskoden. Och att få veta vad för statuskod den egentligen ska spotta ut när SSL är aktiverat, har jag inte heller fått veta.

Har valt att låta detta vara, för ingen ger mig konkret information (med exempel) om hur jag löser problemet. Om någon här vet lösningen och är villig att hjälpa mig lösa det hela, snälla, skriv ett inlägg i den här tråden.

Ok, tack för svaren, @pv2b, @Pamudas och @Xcorp Ska se vad jag kan snickra ihop. Vill ju att Enc ska vara säker för alla. Och om man inte litar på mig trots allt, ladda hem filerna från Codeberg och lägg upp webbsidan på sin egna server.

Gällande helstreckskryptering. Blir det per automatik E2EE om jag låter JavaScript kryptera strängarna? Jag trodde att båda parterna (den som skickar och den som tar emot) måste dela sina nycklar med varann, och att dessa nycklar krypterar och avkrypterar datan (eller nått sånt). Jag kan inte tänka klart just nu. Har mycket att göra på samma gång. Kaka på kaka, typ.

Alright. Och om jag har förstått det hela helt rätt, filer som laddas upp till servern, måste även dessa krypteras av klienten? Eller kan jag låta det vara som det är nu (att servern krypterar dom)?

Har hittat en lösning till att kryptera meddelandet på klientnivå med hjälp av CryptoJS (vilket jag antar använder sig av Web Crypto API). Håller på och lägger in detta till Enc just nu.

Ok. Tack för informationen. Jag är helt ny inom kryptering och sånt, främst gällande E2EE. Plus, kan inte tänka logiskt i kväll, vilket är bevisat nog nu, haha!

Nu har jag lyckats fixa in kryptering med AES i JavaScript (CryptoJS). Förhoppningsvis funkar allt klockrent för alla Testa gärna och återkom om ni stöter på några problem.

Först och främst, tack för skärmdumpen. Visste inte om att jag kunde kika på sånt där i Request-fliken.

Hm. Kan ju kryptera meddelandefältet innan datan hinner skickas iväg till share.php. Då kan man ju även skippa det gömda textfältet för meddelandet.

Dock har jag inte hittat någon lösning till hur man kan kopiera text i input type="password", samtidigt som lösenordet kan kopieras i klartext på nästa sida. Clipboard.js klarar inte av att kopiera innehållet i input type="password". Kan inte heller testa Clipboard API då den kräver HTTPS, vilket jag inte har lokalt. Hade tänkt att påtvinga besökaren att kopiera lösenordet innan hen väljer "Share", men ångrade mig. Kanske måste ha det så ändå?

Jag kan ju ändra så att man kan själv ange ett lösenord. Men min tanke med att påtvinga ett generativt lösenord är att bevara säkerheten. Det är mycket enkelt att hacka till exempel H3js4n, medan det är dyngsvårt att knäcka en lösenordsfras. Det tar årtionden att knäcka till exempel Priced-Complete-Final-Minority samtidigt som det är lätt att komma ihåg, medan det tar 4 sekunder att knäcka H3js4n.

Anledningen till varför jag begränsade till JPG, WEBP och PNG är för att grundidén var att endast kunna dela bilder med ens meddelande. Men om önskan är stor att kunna skicka andra filformat, så tar jag ju såklart bort spärren.

Vill bara tacka er alla för alla tips ni har gett mig, och att ni ska veta att jag arbetar på det. Men det kan ta sin lilla tid. Mycket med det här projektet är nytt för mig och det visste jag redan från början. Ville utmana mig själv och jisses vilken utmaning det är! xD Mycket tänkeverksamhet som jag inte alltid klarar i och med min autism, men jag arbetar på det