From jon@callas.org Fri Jul 6 02:42:45 2018 From: Jon Callas To: cypherpunks-legacy@lists.cpunks.org Subject: Re: [cryptography] Tigerspike claims world first with Karacell for mobile security Date: Fri, 06 Jul 2018 02:42:45 +0000 Message-ID: <172289280103.3881296.8924048021556919834.generated@mail.pglaf.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7093989779668114424==" --===============7093989779668114424== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I took a look at it. Amusing. I didn't spend a lot of time on it. Probably no= t more than twice what it took me to write this. It has an obvious problem with known plaintext. You can work backward from kn= own plaintext to get a piece of their "tumbler" and since the tumbler is just= a big bitstring, work from there to pull out the whole thing. The encrypted Karacell file format has 64 bits that must decrypt to zero. Sin= ce encryption is an XOR onto a pseudo-one-time-pad, this leaks 64 bits of the= tumbler. Similarly, the "checksum" at the end is a bunch of hash blocks of t= heir special hash all XORed together. This doesn't work against malicious mod= ificationp; you can cut-and-paste through XOR, etc. There are obvious vulnerabilities to linear and differential cryptanalysis. I= t is a lot of XORing on large-ish fixed longterm secrets with only bit-rotati= ng through the secrets, and between the vulnerabilities of known plaintext as= well as the leaks in it, I don't see a lot of long-term strength. I bet that= you can use known structure of plaintext (like that it's ASCII/UTF8, let alo= ne things like known headers on XML files) to start prying bits out of the tu= mblers and you just work backwards.=20 But beyond that, it isn't even particularly fast. Since it needs a lot of bit= extraction and rotations, I doubt it would be as fast as AES on a processor = with AES-NI instructions. The whole thing is based on doing 16-bit calculatio= ns and some bit sliding; I don't expect it to be as fast as RC4 or some of th= e fast estream ciphers. Obviously, I could be missing something, but there are other errors of art th= at lead me to think there isn't a lot here. For example, if your basic encryp= tion system is to take a one-time-pad and try to expand that out to more uses= , zero constants are errors of art. You should know better. There are similar= errors like easily deducible parameters that give more known plaintext. The = author discusses using a text string directly as a key, which is very bad wit= h his expansion system. He invented his own "message digest" functions, and t= hey look like complete linear functions to me. They're in uncommented C that'= s light on indenting and whitespace. Confirmation bias might be making me mis= s something, but it's not like he made it easy for me. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFQ225dsTedWZOD3gYRArauAKC5vrbr9HKPd0a0NoXL+eVQq428uQCgiiFE GFlyVpZAY6w80CBqxXl2qHs=3D =3DgncJ -----END PGP SIGNATURE----- _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- --=20 Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE --===============7093989779668114424==--