Products > Security
Encrypted file and unencrypted copy together, can password be calculated?
Kjelt:
--- Quote from: iMo on September 02, 2024, 12:08:58 pm ---In this FT article they talk about the Durov team (incl. the indication of the salaries of his 30 core people), etc.. Interesting when true..
https://www.ft.com/content/429f9092-5447-4e4c-b3b6-ffa2bc357ca4
--- Quote from: radiolistener on August 30, 2024, 08:05:35 pm ---..As for telegarm, I think this is just yet another project for mass consumption and Durov is probably just a talking head representing a project that is actually run by a hidden organization that lay in the shadows..
--- End quote ---
--- End quote ---
Paywall perhaps give a summary or it is useless
iMo:
I can read it fine incl. comments no paywalling here so far..
peter-h:
Always fun to read threads on comms security ;)
--- Quote ---You can go on the NSA's website and read copies of the Vernona intercepts that were only decrypted much later and the real names and the code names of Soviet agents in the US and Britain that were identified by those decrypted messages
--- End quote ---
Venona is an unbreakable OTP which was cracked because the Russian OTP printing shop was unable to cope with the demand, due to the sheer number of spies they were running in the West :) So they duplicated some print runs, and a smart cryptographer spotted the resulting matching patterns. It was a valuable programme and it ran until about 1980, but which time any remaining agents (and other relevant factors) would have been out of action. That was decrypting traffic whose vulnerability ended about 1944! (Philby blew the break to the Russians c. 1944).
--- Quote --- they did not crack Enigma by brute force,
--- End quote ---
Even today, Enigma is very hard to crack by brute force. At a primitive level, the key size is (IIRC) of the order of 100 bits. And there were many versions of "Enigma", with the naval version using 2-letter lookup tables to break the obvious weaknesses which enabled the early breaks. But it can be done, with specific approaches, with a lot of computer power and a lot of time. With a dedicated box, say 1M FPGAs, it would be much faster but nobody would bother building such a box now.
--- Quote ---Don't know what ciphers Telegram is using.
--- End quote ---
TG stores the stuff in plaintext on its servers. That is actually a very handy thing because you get multiple devices syncing perfectly and in real time. Unlike say Whatsapp which sends everything via the one phone and has stupid limits on how many other devices it can be installed on. 99.9% of people with a brain will assume the NSA and probably the FSB can read it all but they don't care because who cares about the FSB knowing you are going to the village cross-stitching competition ;)
The bottom line is that in some 99.9% of applications, nobody will have the opportunity to collect the ciphertext anyway. And in nearly all embedded contexts, there is negligible security around the hardware, and without physical security you have no security at all. And if a State agency is decrypting AES256 (we must assume the NSA can do this) they won't be advertising it by using the crack to put away some bank robbers :) And finally some 99.9% of data is completely worthless to an attacker :)
Lots of civil liberties people get excited about GDPR for example. As anybody running a forum will know, you get a steady stream of people who threw their toys out of the pram and demand the deletion of their forum posts. GDPR actually explicitly protects forum posts... only the person's profile info can be demanded to be deleted. Then they moan about google analytics (resulting in the stupid cookie consent popups) when their GSM phone location is logged, essentially for ever, every 10 mins, both google and apple log the GPS position much faster than that (which is how google maps knows where the traffic jams are). And nearly all data breaches involve no crypto at all.
In the 1980s, Zilog and AMD made a DES chip (they were supposedly 2nd sourcing each other but many 2nd sources were actually fake, and were just different markings). I was told by a Zilog rep back then that the NSA placed a huge order for these chips. To be expected I am sure... That was 40 years ago. But 25 years ago it was easy to unroll the whole DES algorithm (eliminating the loops) and pop it into a Xilinx XC3090 FPGA, with a propagation time of ~100ns, so testing 10M keys per second. Now buy say 100k of these FPGAs, and you have a near real time known-plaintext cracking capability. Around 1992 I was making some DES line encryptors (banking customers) and you could sell (and export) them freely if it used plain DES, even if you used RSA to change the key every minute. Go figure...
Nominal Animal:
--- Quote from: peter-h on November 10, 2024, 01:07:06 pm ---And in nearly all embedded contexts, there is negligible security around the hardware, and without physical security you have no security at all.
--- End quote ---
This.
I've finally ordered some ATECC608B chips for experimenting with, for storing encryption keys and offloading certificate validation. While the chips are at least resistant to physical attacks, anyone can desolder the chip and solder a new one (or implement similar attacks, depending on the exact PCB layout, that may not even be visible under normal scrutiny), bypassing such security altogether. The same applies to any device, at all scales. Nothing is unfakeable.
--- Quote from: peter-h on November 10, 2024, 01:07:06 pm ---And nearly all data breaches involve no crypto at all.
--- End quote ---
Most often seems to be keys inadvertently leaked; occasionally a failure in key verification, or in key generation.
But also, obligatory XKCD:
and
Navigation
[0] Message Index
[*] Previous page
Go to full version