Author Topic: Encrypted file and unencrypted copy together, can password be calculated?  (Read 3768 times)

0 Members and 1 Guest are viewing this topic.

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6580
  • Country: nl
Re: Encrypted file and unencrypted copy together, can password be calculated?
« Reply #50 on: September 02, 2024, 01:23:19 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


..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..
Paywall perhaps give a summary or it is useless
 

Online iMo

  • Super Contributor
  • ***
  • Posts: 5357
  • Country: ki
Re: Encrypted file and unencrypted copy together, can password be calculated?
« Reply #51 on: September 02, 2024, 03:50:28 pm »
I can read it fine incl. comments no paywalling here so far..
Readers discretion is advised..
 

Online peter-h

  • Super Contributor
  • ***
  • Posts: 4254
  • Country: gb
  • Doing electronics since the 1960s...
Re: Encrypted file and unencrypted copy together, can password be calculated?
« Reply #52 on: November 10, 2024, 01:07:06 pm »
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

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,

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.

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...


« Last Edit: November 10, 2024, 01:11:46 pm by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 7072
  • Country: fi
    • My home page and email address
Re: Encrypted file and unencrypted copy together, can password be calculated?
« Reply #53 on: November 11, 2024, 05:50:20 am »
And in nearly all embedded contexts, there is negligible security around the hardware, and without physical security you have no security at all.
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.

And nearly all data breaches involve no crypto at all.
Most often seems to be keys inadvertently leaked; occasionally a failure in key verification, or in key generation.

But also, obligatory XKCD:
and
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf