compatibility and one or two other issues

Discussion related to AES Crypt, the file encryption software for Windows, Linux, Mac, and Java.
Post Reply
jgisme
Posts: 7
Joined: Fri Feb 26, 2016 12:06 am

compatibility and one or two other issues

Post by jgisme » Fri Feb 26, 2016 12:31 pm

This is my first posting wrt AES and I would like to thank the folks who make this board and forum possible.

The AES method is block based, plus it contains salted blocks which are assumed to be different from use to use. I mention this because the method works, both design elements increase the difficulty of an adversarial decrypt. Still, I've been playing...

Is the Apple code public? While I don't have any means to undo the ten-time limit the Apple hardware/software imposes, I do have something, call it experimental, and I'd like to know:

IS THE APPLE AES-256 code public?, and if so where is it posted? I want a copy. I can't change the hardware, I can't affect the limit count.

Still, if someone can point me to the Apple code, I would like to experiment.

jgisme
Posts: 7
Joined: Fri Feb 26, 2016 12:06 am

Re: compatibility and one or two other issues

Post by jgisme » Fri Feb 26, 2016 4:42 pm

I have the code now.

I appreciate the drama-free environment here

Thanks guys!

User avatar
paulej
Posts: 524
Joined: Sun Aug 23, 2009 7:32 pm
Location: Research Triangle Park, NC, USA
Contact:

Re: compatibility and one or two other issues

Post by paulej » Fri Feb 26, 2016 4:45 pm

If you're referring to the encryption used to protect the iPhone data, I seriously doubt it's public. Even if you know what encryption algorithm is employed, you'd need to know what the data looks like, what block cipher modes were employed, etc.

In any case, this really is off topic. For all I know, the encryption they use isn't even AES. I have no idea.

jgisme
Posts: 7
Joined: Fri Feb 26, 2016 12:06 am

Re: compatibility and one or two other issues

Post by jgisme » Fri Feb 26, 2016 5:48 pm

No, it is AES-256.

But that doesn't say (and I don't know,) any of the particular configuration / settings.

On the matter of the San Bernardino muslim killer's, I happen to take the FBI's side in it's conflict with Apple. And I'm not in law enforcement; I actually am an outsider.

But if I had an AES-256 file image, well I'd have enough to do something. Call it an experiment. But if i'm going to do it I'd like to do it on an actual Apple AES-256 message image.

Before anything gets the wrong idea, I am not a whiz at security issues, I do experiments in computer science. Sometimes I get things right, but this is a new field for me...

User avatar
paulej
Posts: 524
Joined: Sun Aug 23, 2009 7:32 pm
Location: Research Triangle Park, NC, USA
Contact:

Re: compatibility and one or two other issues

Post by paulej » Sat Feb 27, 2016 9:44 am

I don't mind publicly stating that the FBI is going too far. I'm very much in Apple's camp on this issue. Here's why: the FBI isn't seeking to only unlock that phone. They want a tool to get into any iPhone. I read the court order. To comply with it, there are two serious issues. Most significantly, the government is requiring Apple to do work. And it's not work like opening a door, but software development to bypass security mechanisms. Second, they want a phone image with weak security.

If the FBI wanted that data, all they'd have to do is copy what's on the device to a computer. I'm pretty sure they have the resources to do that. For sure, the technology exists to do that. Then they can hack on the raw data all day long.

But what they want is a court precedent to give themselves new power to dig into whatever they want. This is scary.

And with Congress considering back doors in software and hardware, just imagine all the hacking hackers can do. We don't need any systems to be made vulnerable to exploits.

People have offered to help the FBI get the data of the phone. They're ignoring those orders. They don't care about the data. They're wanting a court victory.

jgisme
Posts: 7
Joined: Fri Feb 26, 2016 12:06 am

Re: compatibility and one or two other issues

Post by jgisme » Sat Feb 27, 2016 1:21 pm

Well we disagree...

And what you don't say is that the business of decapping the chip and reading the contents using an electron 'microscope' is dicey, no reputable security provider would promise that; Too many things can go wrong for that to be the best choice at this juncture.

I do CS experiments. More than twenty years ago I looked at repeatable file compression and looked to make a working system. I found several methods and have working systems today. And no customers.

In fact, when some long-standing friends needed belief reinforcement I began giving away a demo program and decided to offer it for sale on the 'net. The download could be accomplished without paying first but I asked folks to pay $20 per CPU on which the program was run.

Thousands downloaded my demo. No one paid for it. Not one person. I am no longer in the repeatable compression business. This is exactly what I saw from major US companies, too. And the US patenting system is a terrible fraud on the independent researcher. (Actually a fraud I might have fallen for but for one of your co-employee's. He and I have had our problems but his remarks as to the value of patents have been spot-on.)

Anyway I moved on. I do something now that doesn't require customers. I have a blog, it's emmettbrownblog.wordpress.com.

I've also been experimenting with recovering file content from files processed using AES256, and I've discovered that what you said (recently,) is certainly true, the number and type of options available to a system designer are myriad, it's not like a simple XOR encode. Block cipher's are easily many millions of times more complex than the simple XOR.

I am not a hardware person so I can't read the chip either. (And I'm the very last person who would attempt such a thing.)

What I have doesn't work in the general case because the problem space isn't simply the problem of recovering a password; In order to do that one has to already know the various settings of salted bytes and algorithm options that are part of the AES-256 system.

What I have is much more basic than a usable tool, it's this:

You are given an image of an encrypted message; You have a decrypting engine and already know all the settings. All that is missing is the password.

Okay.

Now, imagine that you have all possible passwords, from all-zeros to all-ones. Arrange these passwords to be in lexical order and choose the password at the mid-point.

My program can determine whether the correct password is to the left or the right of the mid-point. This delivers one bit and your new problem is now half as tough as it was (and you can safely discard half of your passwords as not needed for this problem.) This gives you a new mid-point and you run my process again, etc...

And Paul, I have a different opinion from you...

I think the FBI is a stalking horse for the NSA and that Apple, far from being the righteous knight in shining armour is working in concert with our government. Why?, to what purpose?

Because wouldn't it be wonderful if Apple wins and everyone decides that Apple boxes are secure from government intrusion, causing the bad-guys to go out and buy those nice Apples (which is a mistake I'll never make again!, once was enough.)

Oh yeah, except they are not...

I should say that I have no government or corporate affiliation, this is just my opinion, and why do I think this?, because I've dealt with Apple and found them not to be the kind of company that cares about their customer. Yes, they pretend, they do that very well.

I have my tool-set for predicting small, very small, aspects of the future; I've been running the system with lottery data and probably this is it for me.

User avatar
paulej
Posts: 524
Joined: Sun Aug 23, 2009 7:32 pm
Location: Research Triangle Park, NC, USA
Contact:

Re: compatibility and one or two other issues

Post by paulej » Sun Feb 28, 2016 3:31 am

You're saying you think you can crack AES with a simply binary search? I seriously doubt that's going to work. This algorithm has been studied at great length by both the private and government researchers.

AES uses key lengths of 128, 192, or 256 bits. AES Crypt uses a 256 bit key. The most vulnerable thing is that one can just try random passwords. The weakness is that humans often select weak passwords. But, that's the attack the government wants to take. They have the resources to test tons of passwords per second, except the iPhone will block them. Which is another reason why they should just copy the internal storage and attack it outside the phone. And they can. They don't need to hire anyone. Even so, they have received offers to hack the phone for them. The government isn't interested. They just want that backdoor.

jgisme
Posts: 7
Joined: Fri Feb 26, 2016 12:06 am

Re: compatibility and one or two other issues

Post by jgisme » Sun Feb 28, 2016 10:26 am

I need to be very precise here.

If one has an AES256 image (probably, of some length, of at least several kb,) I have the means to do password recovery.

The method depends on knowing all parameter settings and having the various salt values, too. All of that must be known.

The method produces one bit of the password per major iteration with a probability of .70, maybe as high as .75. Bad choices require back-tracking. A bad choice becomes increasingly obvious; Changes I'm making to the program will support retreating ten steps, making the other choice and going forward again.

Also (thanks for supplying a PREVIEW,) the process is more a consultant's tool. One has to build some things, and to build them one has to know the various settings in advance. That's the only gotcha I can think of. Otherwise, for me, this is working technology. (Look at that simple function rdRELATION, that code was constructed mechanically. I use hundreds of small programs like that and the process makes pretty good decisions!)

Several months ago I was considering building/marketing some AES256 programs. You have my demo program, that's not AES related but it does show what I say in my note.

I had decided not to engage the AES marketplace, then recently saw what happened in San Bernardino. I don't have any idea of the correct settings and such that Apple might apply, apparently they're willing to let the bad-guys win some.

I don't want to do security work. You have my emailed note...

jgisme
Posts: 7
Joined: Fri Feb 26, 2016 12:06 am

Re: compatibility and one or two other issues

Post by jgisme » Wed Mar 16, 2016 5:27 am

I had, a few months ago, experimented with AES, applying a technology I have to develop a system for recovering (that's a big word, how about guessing, much more accurate,) a password one bit per iteration. And yes I actually do iterative binary decomposition to obtain the complete password. I'm back to restate one or two things...

I don't have a turn-key product ready for use by someone unfamiliar with the technology. I do have a set of tools that can, and has, been used to recover AES256 passwords, but only in a test environment.

And of course I am wondering if there are organizations that would like to know more. But this isn't a general call, I think it's important to keep such technology in the hands of the "white hats." Me thinks this is true today, more than ever.

One component I definitely have, probably the most important element, is the means to mechanically examine a block and decide if the N'th bit of the encoding password is to the left or right (eg., a zero or one.)

I acknowledge that these statements might be difficult to accept and thus, my suggestion to examine a small demo program I give away, (supplied here,) a program that reads a previously compressed file and guesses the arithmetic relation between each client byte and the output of a pseudo-random number generator. (I write this: int p = r >= d;) Of course this seems like it should be 50/50, but no, it's 75/25, and guess what!, the client file doesn't even have to exist at the time the comparison is made. One can effectively 'read' a file that may not even exist at the time it's read.
a1.c
This is my $20 program, you need to point it to a compressed file, but it does what I claim for it, guessing "r >= d" even if the 'd' value (a byte in a file,) diesn't even exist yet. Notice, in order to demonstrate that it works I read the 'd' bytes but only to compute the success merit (of 75%,) otherwise the 'd' value is never read or used. Here, in this demo, I use the value from a PRNG. It's available and convenient, but otherwise not interesting.
(4.62 KiB) Downloaded 202 times
I charge $20 per CPU for this program, it's written in C. I supply the source code as an attachment to this note.

My point: the crucial code, a function called 'rdRELATION' was mechanically produced. Similarly I produce hundreds of similar functions that, together, make pretty good guesses as to the correct next bit in an AES password.

Again, I don't have a turn-key program, only a consultant's tool.

Initially, one has a lo (lowest possible password,) and a hi password, and a process chooses the space to the left or right of the midpoint. A process, effectively, delivered a direction, making the new space either (lo .. mid) or (mid .. hi), depending on the guessed direction.

Post Reply