So, we are working on iOS push notifications for vendors that make apps and I think i am seeing two different ways that it can be sent to us. I am just wanting to know if this is a true or am i going down the wrong path.
I see that they can either A take the DeviceToken for push (NSObject) and Base64 Encode it and passes it to us to send. OR they could take the NSObject and HEX string it and pass it to us and not do the Base64 Encoding.
is this true? is it separate logic for handling when trying to send to Apple?
Thanks ahead of time guys!
Basically, you are correct. A hexadecimal number is definitely not the same as base64-encoded data. Theoretically, there is an infinite number of other possible encodings you could use to send the token to your server, but those two are probably among the most popular.
Base64 uses more characters for encoding so it needs less space, and it is kind of a de-facto standard for sending binary data over the network, so that's what I would opt for.
Related
I googled but mostly found links to 3rd part libraries for encryption/decryption works. However, I saw Security articles on the Apple site, though without examples.
Can you please show me an example of a simple encrypt/decrypt a string with a key function?
Security and CommonCrypto are low level frameworks. They only provide security primitives, not a full encrypted data format. It is challenging to build a secure format out of the primitives, and most examples you'll find online are insecure. Either the author did not know how to build a secure format, or the author assumes you know how to take what they've written and finish building a secure format.
There is no such thing as "decrypting a string" in the way that you likely mean. All encryption functions generate raw bytes. If you want a string, convert it to base64 or hex or whatever. Some libraries automatically add this, but it often leads to strange artifacts like double-base64-encoded data.
If you want a cross-platform "out of the box" encryption format, see RNCryptor or libSodium. Both of these convert data-to-data. If you want strings, just encode and decode the data as you like (usually as base64 or hex).
What I have found you can have a look at this url : Swift Default Encryption
Good day everyone! I've been using AFNetworking 2.0 for a quite a while and because input was always of https with json - never had any problem. Yet now we have a custom written on C server which works only with HTTP and sends encrypted raw byte data.
As far as I understand it's necessary to use some sort of serializer , but i can choose only from: AFHTTPResponseSerializer/AFJSONResponseSerializer/AFXMLParserResponseSerializer/AFXMLDocumentResponseSerializer/AFPropertyListResponseSerializer and none of them seems to fit.
What's the best solution?
As result i need decrypted NSData which i can parse byte by byte.
All the possibilities of encryption rule out a standard ResponseSerializer. Some of the encryption properties include algorithm, key, key size, mode, possible iv and padding.
The solution is to decrypt the received data in a separate step.
In order to decrypt the data you need to know the algorithm, it's parameters and the encryption key. It is also possible that additional encryption information is added to the encrypted data such as an iv, KDF reputation count, etc. You need to obtain this information from the server developers.
I have an erlang program which generates data. This data needs to be transferred via udp to a non-erlang program for further processing. I already have this part working - sending the data via udp and receiving it on the other non-erlang side.
Here's the problem. The data (erlang terms like tuples containing lists) doesn't seem to be able to go over "as is" (i.e. I can't just send arbitrary erlang terms). It apparently needs to be converted to either text or binary first. Converting to binary seems easy enough with a bif I found. The problem is, binary gobbledygook comes out the other side, and I don't know any easy way to decode it (the other side is non-erlang).
Barring someone telling me some easy way to decode binary gobbledygook on the other side, I'd like the data to be sent as a simplistic string representation of the terms - for instance a tuple like this:
{[1,2,3],[4,5,6]}
sent like this:
"{[1,2,3],[4,5,6]}"
I haven't seen any such bif, i.e. "convert_term_to_ascii/1" etc. I know I could scan it and send token representations of the terms, but I don't want to do that - decoding that on the other side is just a pain I don't want to deal with.
I know I'm not the first, second, or third person to have this problem. It has to be fairly common. How is it normally dealt with?
Can someone point me to some resource showing me how to either 1) convert binary gobbledygook to ascii (needed on the non-erlang side), or 2) straightforwardly convert terms to a string (needed on the erlang side)?
Or, tell me how I'm wrong and how I should really be doing this?
Thanks.
1) you can convert any term to string using
R= io_lib:format("~p",[yourtermhere]),
lists:flatten(R)
2) you might look at erlang external binary format, a lot of other languages have libraries for encode/decode that erlang binaries format. And in erlang you can encode any term by term_to_binary
I'd recommend converting the erlang terms into JSON, with either of known libraries (heard good words regarding rfc4267). It'd be a trivial task to convert JSON back with any non-erlang platform, I guess. )
I am building an application which is talking to my .Net WebService. Application is transmitting some sensitive client information to my WebService which I want to encrypt before I wrap it in the SOAP Envelop. And web service will decrypt it on the other side before using it.
Can someone suggest me how to achieve this. I know .Net has some security which allow you to do some authentication and encryption but I dont want to go to that path at this stage, as I want to make data secure going to and from the iOS device to my webservice.
If any tutorial or example exists please let me know as this is first time I am using encryption decryption.
AES is available on pretty much every platform. What you have to do is to make sure that everything else is the same on both platforms:
1.The same mode; use either CBC or CTR mode.
2.The same IV; set it explicitly, don't use the default because it will often be different on different systems.
3.The same key; obvious, but they need to be the same at the byte level because text can be encoded differently on different systems. Explicitly state the encoding you are using.
4.The same padding; for AES use PKCS7, again don't rely on the default which may be different on different systems.
Whatever you chose do set things explicitly and don't rely on defaults. Defaults can differ between systems and any difference will cause decryption to fail.
Use an HTTPS connection. This will encrypt your entire connection, and it's trivial to use and built in to both the iPhone and .NET.
I have an external device that spits out UDP packets of binary data and software running on an embedded system that needs to read this data stream, parse it and do somethign useful. The binary data gets logged to a file as well. I would like to write a parser that can easily take the input directly from either the UDP stream, or a file, parse the data into a specific format and then direct the output to either a file (e.g. matlab dat file) or to another process that will do some real time processing. Are there any resources that would help me with this and what is the best way to go about this? I think it might make sense to use C++ streams but I'm not familiar with creating custom output streams. Does this seem like a good approach to take or is there a better way to go about it?
Thanks.
The beauty of binary data is that its is generally of very fixed format.
A typical method of parsing it is to declare a structure that maps onto the received packets, and then to just use type-casts to read the fields as structure elements.
The beauty is that this requires no parsing.
you have to be careful about structure packing rules, and endian-ness to make the structure map exactly the same way. Use of the C "offsetof" and "sizeof" macros is useful to emit some debug info to check that your structure is indeed mapping to what you think it is mapping.
Packing rules can typically be altered either by directives (such as #pragma's) or command line options. Endian-ness you are stuck with. If its different from what your embedded system uses, declare all the fields as bytes, or use something like the "ntoh" macro to do the byte swapping.
The New Jersey Machine Code Toolkit is a scheme for decoding arbitrary binary patterns. It was originally designed for decoding instruction sets, but it ought to be just fine for decoding message formats. You provide a description of the binary format, it synthesizes code to access the fields of that format (when valid). THus you can refer to message fields using generated function calls rather than think about where the field is or how it is encoded.