-4

I'm encountering this problem converting a byte[] in C# to SOME kind of data type in Objective-C. If it's a byte[] in C#, then what should it be in Obj-C; const char, unsigned char, NSMutableData, NSMutableArray etc... whatever array format it's in, it need to have some kind of .Length property which NSMutableData has, but the straight one to one conversion seems to be found in this post: http://stackoverflow.com/questions/876598/byte-array-in-objective-c

Ultimately there are over 10 methods in a C# encryption process that may need to be replicated to decrypt a password sent via a SOAP web service XML attribute. Is this going to be possible in general? Taking a password that was encrypted in C# using SHA hashing then decrypted via Objective-C?

EDIT BECAUSE OF DOWNVOTES

Made edits to be more clear, however I'm not going to "post my encryption logic" on SO, so I'm trying to explain the steps without explaining the steps??

Basically the pw string is being AES128 Encrypted then this then that, but my basic question still remains; If the Obj-C methods mimic the C# methods in the exact order, which include the decryption logic using a key and an iv that are hashed as well, that DOES work on the C# side, will this work in theory? Or is this known not to be possible?

Trying to figure out if I need to import a dyLib into my proj from a C# dll...

whyoz
  • 5,168
  • 47
  • 53
  • 4
    `...was encrypted in C# using SHA hashing` Hashing is not the same as encrypting. Hashing is one way and cant be reversed. – Ňɏssa Pøngjǣrdenlarp Mar 08 '18 at 16:42
  • @Plutonix I can reword that to be more clear, and include general conversions done on the C# side.. there's sha512 and sha256 hashing and aes128 encryption on the hash.. you responded before I even had a chance to edit! Give me a chance to change that downvote and we can figure some interesting stuff out – whyoz Mar 08 '18 at 19:48
  • The phrase I quoted is still in the post 3 hours later, so the time of my comment is irrelevant. Also, not my DV - you are asking about making two bits of code to work together without showing either one which is probably the reason for them...or perhaps the notion that hashing is the same as encryption (dunno). – Ňɏssa Pøngjǣrdenlarp Mar 08 '18 at 19:52
  • 2
    `however I'm not going to "post my encryption logic" on SO` we cannot fix code we cannot see. Especially if it is hashing, there isnt really any danger in posting it. And if it is a "pw string" it *certainly* ought to be hashed and salted (not encrypted) making it very difficult to undo it. – Ňɏssa Pøngjǣrdenlarp Mar 08 '18 at 20:09
  • with regards to what you said about refusing to post encryption logic, you should familiarize yourself with Kerckhoff's principle, https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle. – ɯɐɹʞ Mar 08 '18 at 21:22
  • I'm not a cryptography expert, so maybe I shouldn't go by the "If you give Edward Snowden a Rubik's Cube as a gift that has a secret compartment in it, don't be surprised when he uses it against you" principal! Thanks @Plutonix and "Mark".. good stuff – whyoz Mar 08 '18 at 23:55

2 Answers2

1

As @Plutonix said hashing is not encrypting. The main goal of hashing is that the hash should not be reversed. You can use rainbow tables to try to get the original value.

Here is a list of rainbow tables where you can find SHA.

Enrique Bermúdez
  • 1,740
  • 2
  • 11
  • 25
1

If it mimics the C# methods in the exact order, which include the decryption logic with a key and an iv that are hashed as well, that does work on the C# side, then is it possible this could never work?

Assuming you mean "could ever work" then the answer is yes, there is very little your C# code could do that you could not code in Objective-C. So if you've got your decryption algorithm in C# implementing it in Objective-C (and plenty of other languages) should not be too hard.

I'm encountering this problem converting a byte[] in C# to SOME kind of data type in Objective-C. If it's a byte[] in C#, then what should it be in Obj-C; const char, unsigned char, NSMutableData, NSMutableArray etc...

This is your key issue, picking the best type for your algorithm in Obj-C. Your C# byte[] is a value array, Objective-C has value arrays from C and object arrays/collections (NSArray, NSData).

If you pick a value array (say unsigned char [] or by reference unsigned char *) you need to manage memory lifetime and deallocation - value arrays are not passed by value in (Objective-)C but by reference. However index operations are direct.

If you pick an Objective-C collection (NSArray, NSData etc) then lifetime and deallocation is handled by ARC. However index operations require calls and are less flexible than you might be using in your C# implementation of your algorithm. This may or may not matter - it is going to be algorithm dependent.

There is a midway point. You can allocate a C style byte buffer and then wrap it as an NSMutableData handing over responsibility for memory management to ARC. You can then recover an unsigned char * to the wrapped bytes and process away.

You will need to pick between these options depending on how the bytes arrive in your program and how your algorithm needs to manipulate them. But overall the simple answer is if you've an algorithm you have implemented in C# you can do so with similar ease/difficulty in Objective-C.

HTH

CRD
  • 52,522
  • 5
  • 70
  • 86
  • 1
    See [example code](https://stackoverflow.com/a/23641521/451475). `NSData` has a `dataWithBytes:length:` method to create an `NSData` object from bytes. – zaph Mar 08 '18 at 23:18
  • Thanks CRD and @zaph .. exactly what I was looking for! Zaph, I'm using that code already but it had: kCCOptionECBMode|kCCOptionPKCS7Padding ... the C# side is aes.Mode = CipherMode.CBC; which hung me up before all the data type conversion concerns.. thanks for reading into the issue and understanding the key question, is this possible?! I'll figure it out after this explanation – whyoz Mar 08 '18 at 23:41
  • Remove `kCCOptionECBMode`, the Common Crypto `CCCrypt ` default mode is CBC mode. – zaph Mar 09 '18 at 00:49