I have inherited Android code that uses the following cipher:
ks = new SecretKeySpec(key, "AES");
ciph = Cipher.getInstance("AES");
As only "AES" is given, I don't know what the keysize, modes, and padding are. I've looked over the Bouncy Castle* documentation, but I can't find where the "AES" instance is described. I'd like to use a more explicit instance description (e.g. "AES/ECB/PCKS5Padding"), if I can.
Does anyone know what the keysize, modes, and padding are of this instance?
Thanks!
*I've read that Android uses Bouncy Castle as its default provider, but I haven't found that anywhere official, so I could be making an unhelpful assumption here.
Java defaults to "AES/ECB/PKCS5Padding" by default, as specified by the Oracle documentation.
If no mode or padding is specified, provider-specific default values
for the mode and padding scheme are used. For example, the SunJCE
provider uses ECB as the default mode, and PKCS5Padding as the default
padding scheme for DES, DES-EDE and Blowfish ciphers. This means that
in the case of the SunJCE provider:
Cipher c1 = Cipher.getInstance("DES/ECB/PKCS5Padding"); and
Cipher c1 = Cipher.getInstance("DES"); are equivalent statements.
See creating a Cipher object in the Oracle documentation.
I've just checked using a debugger myself. At least for Android 4.0 it seems that Android defaults to the same encryption and padding mode (as expected). The outcome using the default provider of a single (00-valued) byte is a padded plain text with value 000F0F0F0F0F0F0F0F0F0F0F0F0F0F0F in hexadecimals. This is clearly PKCS#5 padding, or more correctly PKCS#7 padding which is the same padding as PKCS#5 for 16-byte block ciphers.
In principle any provider can have a different default from the default "SunJCE" provider. However, that would break applications that assume that the Oracle / OpenJDK default is used.
Instead of leaving your colleague programmers in the dark, it is strongly recommended to specify the entire string including mode & padding and not to rely on defaults for cryptographic algorithms (with the exception of SecureRandom, where specifying the algorithm is usually not recommended).
From what I know, In java it stands for AES in ECB mode without padding
. And I think it's the same on android. I would recomend you running a simple test encrypt something on android and decrypt it using AES/ECB/NoPadding using Java or android. Plus if you don't see any IV in this app it's another, point in this direction.
Related
I use MAC(Message Authentication Code) with Crypto++ library to secure MANET.
The library provides a lot of MACs algorithms.
I found DMAC in the MAC list and i don't know what does it mean?
Message Authentication Code
Best ragards
Hajji
A bit hidden in the class description is a link:
CBC MAC for Real-Time Data Sources (08.15.1997) by Erez Petrank and Charles Rackoff
Which then points to the paper of which the description reads:
We first present a variant of CBC MAC, called double MAC (DMAC) which handles messages of variable unknown lengths. Computing DMAC on a message is virtually as simple and as efficient as computing the standard CBC MAC on the message. We provide a rigorous proof that its security is implied by the security of the underlying block cipher. Next, we argue that the basic CBC MAC is secure when applied to prefix free message space. A message space can be made prefix free by authenticating also the (usually hidden) last character which marks the end of the message.
Double MAC consists of performing CBC-MAC followed by another CBC-MAC over the result, which should thwart length extension attacks on CBC-MAC.
I haven't heard of it before; I guess everybody uses CMAC instead nowadays. CMAC is more efficient as it only requires one additional run of the block cipher, and requires this up front (during initialization of the cipher).
I want to know the sample code for sending message to server and get back response to verifone vx520 terminal using ISO 8583.
As noted in a comment on your question, this is not a code sharing site, so such an open-ended question is a bit difficult to answer, but perhaps I can get you started on the right foot.
First of all, let me start by suggesting that if you have control over the terminal code and the server that it will be talking to, I suggest you NOT use ISO8583. Yes, it's an industry standard and yes, it communicates data efficiently, BUT it is much more difficult to use than, say, VISA-1 or XML, or JSON etc. That means you have more opportunities for bugs to creep into your code. It also means that if something goes wrong, it takes a lot more effort to try and figure out what happened and try and fix it. I have used all these protocols and others besides and I'll tell you that ISO8583 is one of my least favorite to work with.
Assuming you do not have a choice and you must use ISO8583 then it's worth noting that ISO8583 is nothing but a specification on how to assemble data packets in order to communicate. There is nothing special about the Vx520 terminal (or any other VeriFone terminal) that would change how you would implement it verses how you might do so on any other C++ platform EXCEPT that VeriFone DOES provide you with a library for working with this spec that you are free to use or ignore as you see fit.
You don't need to use this library at all. You can roll your own and be just fine. You can find more information on the specification itself at Wikipedia, Code Project, and several other places (just ask your favorite search engine). Note that when I did my 8583 project, this library was not available to me. Perhaps I wouldn't have hated this protocol so much if I had had access to it... who knows?
If you are still reading this, then I'll assume that ISO8583 is a requirement (or you are a glutton for punishment) and that you are interested in trying out this engine that VeriFone has provided.
The first thing you will need to do (and hopefully, you have already done it) is to install ACT as part of the development suite (I also suggest you head over to DevNet and get the latest version of ACT before you get started...). Once installed, the library header can be found at %evoact%\include\iso8583.h. Documentation on how to use it can be found at %evoact%\docs. In particular, see chapter 6 of DOC00310_Verix_eVo_ACT_Programmers_Guide.pdf.
Obviously, trying to include a whole chapter's worth of information here would be out of scope, but to give you a high-level idea of how the engine works, allow me to share a couple excerpts:
This engine is designed to be table driven. A single routine is used
for the assembly and disassembly of ISO 8583 packets. The assembly and
disassembly of ISO 8583 packets is driven by the following structures:
Maps One or more collections of 64 bits that drive packet assembly and
indicate what is in a message.
Field table Defines all the fields used
by the application.
Convert table Defines data-conversion routines.
Variant tables Optional tables used to define variant fields.
The process_8583() routine is used for the assembly and disassembly of ISO
8583 packets.
An example of using process_8583() is given elsewhere as follows:
#include "appl8583.h"
int packet_sz;
void assemble_packet ()
{
packet_sz = process_8583 (0, field_table, test_map, buffer, sizeof( buffer));
printf ("\ fOUTPUT SIZE %d", packet_sz);
}
void disassemble_packet ()
{
packet_sz = process_8583 (1, field_table, test_map, buffer, packet_sz);
printf ("\ fINPUT NOT PROCESSED %d", packet_sz);
}
To incorporate this engine into an application, modify the APPL8583.C
and APPL8583.H files so that each has all the application variables
required in the bit map and set up the map properly. Compile
APPL8583.C and link it with your application and the ISO 8583 library.
Use the following procedures to transmit or receive an ISO 8583 packet
using the ISO 8583 Interface Engine:
To transmit an ISO 8583 packet
1 Set data values in the application variables for those to transmit.
2 Call the prot8583_main() routine. This constructs the complete
message and returns the number of bytes in the constructed message.
3 Call write() to transmit the message.
To receive a message
1 Call read() to receive the message.
2 Call the process_8583() routine. This results in all fields being
deposited into the application variables.
3 Use the values in the application variables.
I'm experimenting with SSL in Erlang, and I've run into a problem.
The device which I'm talking to requires me to set the max send fragment size. In OpenSSL, this would be done with SSL_CTX_ctrl(ctx, SSL_CTRL_SET_MAX_SEND_FRAGMENT, ...).
Is there any way to do this in Erlang?
Erlang does not rely on OpenSSL for its SSL implementation.
Unfortunately, it seems that it currently does not support an option to limit fragment size or RFC 6066's maximum fragment length negotiation. It simply fragments at 16 KB (2^14), the maximum fragment size defined in RFC 2246.
The code that splits fragments is in ssl_record:encode_data/3. Supporting an option like OpenSSL seems trivial to implement, and RFC 6066 negotiation does not seem hard either. You would probably just need to extend connection_state record. Please do not hesitate to submit a patch.
The documentation says
OpenSSL keeps an internal table of digest algorithms and ciphers. It uses this table to lookup ciphers via functions such as EVP_get_cipher_byname().
OpenSSL_add_all_digests() adds all digest algorithms to the table.
My question is, where is this table stored? How does my code know that this method has executed?...how does it work internally, what if i want more SSL connections and one to have all digests added and one not?
Does anyone know any good documentation for this?
Thank you
The NOTES section of the manual page pretty much sums it up:
A typical application will call OpenSSL_add_all_algorithms() initially and EVP_cleanup() before exiting.
and
The cipher and digest lookup functions are used in many parts of the library. If the table is not initialized several functions will misbehave and complain they cannot find algorithms. This includes the PEM, PKCS#12, SSL and S/MIME libraries. This is a common query in the OpenSSL mailing lists.
So assuming that you are writing a typical application, you will add this to your OpenSSL initialization code:
OpenSSL_add_all_algorithms();
and this to the OpenSSL cleanup code:
EVP_cleanup();
and you are done. You are always responsible for calling these yourself in applications which use OpenSSL. If you want to know how OpenSSL stores the table internally, use the source, Luke.
To control which ciphers are available for a specific SSL context, you would use SSL_CTX_set_cipher_list.
As for better documentation than the manual page, I can recommend "Network Security with OpenSSL" by John Viega, Matt Messier & Pravir Chandra. The book is old and does not cover newer versions of OpenSSL, but most of it is still very applicable.
OpenSSL_add_all_algorithms() is not needed for newer OpenSSL versions and is ignored.
For backward and forward compatibility, use this:
# if OPENSSL_API_COMPAT < 0x10100000L
OpenSSL_add_all_algorithms();
# endif
And
# if OPENSSL_API_COMPAT < 0x10100000L
EVP_cleanup();
# endif
The same applies to OpenSSL_add_all_ciphers() and OpenSSL_add_all_digests().
For more details, see the man page at
https://www.openssl.org/docs/man1.1.0/man3/OpenSSL_add_all_digests.html
This is an old question. The API was deprecated some years ago:
The OpenSSL_add_all_algorithms(), OpenSSL_add_all_ciphers(), OpenSSL_add_all_digests(), and EVP_cleanup(), functions were deprecated in OpenSSL 1.1.0 by OPENSSL_init_crypto().
Reference:
https://www.openssl.org/docs/man1.1.0/man3/OpenSSL_add_all_algorithms.html
This is a multi-part question to SO folks before I engage more with core team.
Summary: On OS X, pdfs should be created using quartz, not postscript. Files are smaller, anti-aliased better, OS fonts including opentype are readily available, encoding is less painful, overall I think it’s a better device. On other platforms, it would be reasonable to use cairo, again a more modern pdf-writing device.
Consider the behavior of the png() device. Although it is allegedly slated to move out of x11.R, it handles c("cairo", "Xlib", "quartz") with a default (options("bitmapType")) set by zzz.R (quartz if capabilities("aqua"), cairo if available, Xlib otherwise). PDF needs to behave the same way, so that in Sweave (or babel or whatever) my pdf figures can be generated using the appropriate device.
My Sweave png patch works because png() takes care of getting the device option. An earlier version of the patch (which I still use) flips the device in Sweave, but I was smacked down for this and I know it’s sort of the wrong the place to do it.
There’s some alias cairo_pdf() (also in x11.R) that probably should not be there, shouldn’t that be merged into a device-switching pdf() ?
One approach is to add option "pdfType", which in turn I think should probably be more general – there is already a default device, it’s just that pdf() ignores it! I’m especially wary of introducing new global options because they are more likely to be rejected by core.
I don't think you'd need to implement a device driver. Mostly it sounds like you want to alias pdf() so that it calls quartz() or cairo() as appropriate. The quartz() device already supports PDF output to a file (among others) on OS X.
For your own personal use (I doubt this would find its way into core) you could just alias pdf() to take the appropriate action on each of your platforms and bring it in as a package or in your Rprofile.
pdf.orig = pdf
pdf = function(...) {
// Insert code here
}