In Microsoft- CHAP (Challenge Handshake Authentication Protocol), the message block is divided into three blocks and each having 7 bytes and all block are encrypted using three different keys.
Now the brute force attack combination required is
2^56 + 2^56 + 2^56
out of the three blocks the original content is of only 16 bytes (divided in to 7,7 and 2) and remaining 5 bytes are padded to bring the third 7 bytes block size .
Hence they have given the brute force attack combination required is
2^56 + 2^56 + 2^16 approximately equal to 2^57.
I would like to know how the 2^16 and 2^57 comes.
Also they have given Attackers do not need 2^192 effort only 2^56 + 2^56 + 2^16 approximately equal to 2^57 is required.
It is available in the "www.cs.sjsu.edu/~stamp/CS265/projects/Spr05/ppt/MS-CHAP.ppt"
Can any one help me in this issue?
It's kind of unclear what you're asking for, but I'll try to help out.
2^16 comes from the 16 bytes "the original content" you mention at near the top of your post.
2^57 is approximately 2^56 + 2^56 + 2^16, as you said, so that's where it comes from.
Related
I mostly get RFC 1951, however I'm not too clear on how to manage the case where (when using dynamic Huffman tables) no distance codes are needed or present. For example, let's take the input:
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890987654321ZYXWVUTSR
where no backreference is possible since there are no repetitions of length >= 3.
According to RFC 1951, at least one distance code must be present regardless, otherwise it wouldn't be possible to encode HDIST - 1. I understand, according to the reference, that such code should be of zero bits to signal "no distance codes".
One distance code of zero bits means that there are no distance codes
used at all (the data is all literals).
In infgen symbols, I'd expect to see a dist 0 0.
Analyzing what gzip does with infgen, however, I see that TWO distance codes are emitted (each 1 bit long) for the above input (even though none is actually used then):
! infgen 2.4 output
!
gzip
!
last
dynamic
litlen 48 6
litlen 49 6
litlen 50 6
...cut...
litlen 121 6
litlen 122 6
litlen 256 6
dist 0 1
dist 1 1
literal 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890987654321Z
literal 'YXWVUTSR
end
!
crc
length
So what's the correct behavior in these cases?
If there are no matches in the deflate block, there will be no lengths from the length/literal code, and so the decoder will never look for a distance code. In that case, what would make the most sense is to provide no information at all about a distance code.
However the format does not permit that, since the 5-bit HDIST value in the header is interpreted as 1 to 32 distance codes, for which lengths must be provided for in the header. You must provide at least one distance code length in the header, even though it will never be used.
There are several valid things you can do in that case. RFC 1951 notes you can provide a single distance code (HDIST == 0, meaning one length), with length zero, which would be just one zero in the list of lengths.
It is also permitted to provide a single code of length one, or you could do as zlib is doing, which is to provide two codes of length one. You can actually put any valid distance code description you like there, and it will still be accepted.
As to why zlib's deflate is choosing to define two codes there, I can only guess that Jean-loup was being conservative, writing something he knew that even an over-simplified inflator would have to accept. Both gzip and zopfli do the same thing. They all do the same thing when there is only one distance code used. They could emit just the single one-bit distance code, per the RFC, but they emit two single-bit distance codes, one of which is never used.
Really the right thing to do would be to write a single zero length as noted in the RFC, which would take the fewest number of bits in the header. I will consider updating zlib to do that, to eke out a few more bits of compression.
What are some good algorithms to compute the hash from (192.168.0.1, 34829, 80.229.161.151, 80, 6) which I can use to lookup the connection in a hash table?
192.168.0.1:34829 -> 80.229.161.151:80
(3232235521, 34829, 1357226391, 80, 6)
I read in this article that a popular way to do this, is to sum the integers then mod N, were N is the maximum number of connections.
3232235521 + 34829 + 1357226391 + 80 + 6 = 4589496827 mod 65536 = 10747
However this would collide with the following:
3232235521 + 34818 + 1357226391 + 80 + 17 = 4589496827 mod 65536 = 10747
Would it be better to do this?
3232235521 ⊕ 34829 ⊕ 1357226391 ⊕ 80 ⊕ 6 mod 65536
Just to make sure, the following TCP connection isn't possible because the source port 80 isn't available, as it's already in listening mode on that host?
80.229.161.151:80 ->192.168.0.1:34829
(1357226391, 80, 3232235521, 34829, 6)
Could I use the toeplitz hash or is that just for load balancing packets to cpu cores?
You can just concatenate the input as strings and then use any common hash function like SHA-1, which is fast (about 10—30 million hashes per second on a modern PC). You can concatenate the values as bytes instead of strings but it doesn't really matter (e.g. in case of SHA-1 anything under 56 bytes is a one block).
If your computational resources are constrained and you need higher speed, you can use CRC32 or something like xxHash or MurmurHash. Some modern CPUs support crc32c instruction and then the throughput is up to one billion hashes per second per core.
You can use Toeplitz hash as well but it's really primitive and collisions are more likely.
Diffie-Hellman key exchange algorithm uses operations like 2^8 mod n where n is a prime number.
What is the reason for using prime numbers instead of other numbers?
Prime numbers don't break down into smaller factors, making cracking the code or hash much harder than using, say 12, which breaks down with /2 or /3 or /4 or /6. The prime number 7, is less than 12, but only has the factor of 7, so there are less attack vectors. This is a drastic oversimplification, but hopefully helps a little.
Here's a specific example:
2^x mod 12
This only has 2 possible values, for any x above 1: 4 or 8. Since this is used to generate the shared key in a similar way, you end up with the same two possibilities. In other words, once you know that the base and mod are 2 and 12 (which any computer listening in on the conversation would be able to pick up), you automatically know that the shared secret encryption key can be only one of two possibilities. It only takes two simple operations to determine which decrypts the message. Now let's look at a prime mod:
2^x mod 13
This has 12 different possibilities, for x>1. It also has 12 different possible shared keys that can be generated. Thus it requires 6x more computing power to decrypt a message based on this prime modulus, than it would on the mod 12 example.
2^x mod 14 has 4 possibilities.
2^x mod 15 has 4
2^x mod 16 collapses completely into 1 possibility after x=3 (which is why choosing a base that fits the DH requirements is important)
2^x mod 17 has... you guessed it, 16 possibilities! Aren't primes cool? :)
Thus, yes the factorability of the modulus number has everything to do with crackability of the encrypted message.
I have used pgpdump on an encrypted file (via BouncyCastle) to get more information about it and found several lines about partial start, partial continue and partial end.
So I was wondering what exactly this was describing. Is it some sort of fragmentation of plain text?
Furthermore what does the bit count stand for after the RSA algorithm? In this case it's 1022 bits, but I've seen files with 1023 and 1024bits.
Partial body lengths are pretty well explained by this tumblr post. OpenPGP messages are composed of packets of a given length. Sometimes for large outputs (or in the case of packets from GnuPG, short messages), there will be partial body lengths that specify that another header will show up that tell the reader to continue reading From the post:
A partial body length tells the parser: “I know there are at least N more bytes in this packet. After N more bytes, there will be another header to tell if how many more bytes to read.” The idea being, I guess, that you can encrypt a stream of data as it comes in without having to know when it ends. Maybe you are PGP encrypting a speech, or some off-the-air TV. I don’t know. It can be infinite length — you can just keep throwing more partial body length headers in there, each one can handle up to a gigabyte in length. Every gigabyte it informs the parser: “yeah, there’s more coming!”
So in the case of your screenshot, pgpdump reads 8192 bytes, then encounters another header that says to read another 2048 bytes. after that 2k bytes, it hits another header for 1037 bytes, so on and so forth until the last continue header. 489 bytes after that is the end of the message
The 1022 bits, is the length of the public modulus. It is always going to be close to 1024 (if you have a 1024-bit key) but it can end up being slightly shorter than that given the initial selection of the RSA parameters. They are still called "1024-bit keys" though, even though they are slightly shorter than that.
I use AES128 crypto in CTR mode for encryption, implemented for different clients (Android/Java and iOS/ObjC). The 16 byte IV used when encrypting a packet is formated like this:
<11 byte nonce> | <4 byte packet counter> | 0
The packet counter (included in a sent packet) is increased by one for every packet sent. The last byte is used as block counter, so that packets with fewer than 256 blocks always get a unique counter value. I was under the assumption that the CTR mode specified that the counter should be increased by 1 for each block, using the 8 last bytes as counter in a big endian way, or that this at least was a de facto standard. This also seems to be the case in the Sun crypto implementation.
I was a bit surprised when the corresponding iOS implementation (using CommonCryptor, iOS 5.1) failed to decode every block except the first when decoding a packet. It seems that CommonCryptor defines the counter in some other way. The CommonCryptor can be created in both big endian and little endian mode, but some vague comments in the CommonCryptor code indicates that this is not (or at least has not been) fully supported:
http://www.opensource.apple.com/source/CommonCrypto/CommonCrypto-60026/Source/API/CommonCryptor.c
/* corecrypto only implements CTR_BE. No use of CTR_LE was found so we're marking
this as unimplemented for now. Also in Lion this was defined in reverse order.
See <rdar://problem/10306112> */
By decoding block by block, each time setting the IV as specified above, it works nicely.
My question: is there a "right" way of implementing the CTR/IV mode when decoding multiple blocks in a single go, or can I expect it to be interoperability problems when using different crypto libs? Is CommonCrypto bugged in this regard, or is it just a question of implementing the CTR mode differently?
The definition of the counter is (loosely) specified in NIST recommendation sp800-38a Appendix B. Note that NIST only specifies how to use CTR mode with regards to security; it does not define one standard algorithm for the counter.
To answer your question directly, whatever you do you should expect the counter to be incremented by one each time. The counter should represent a 128 bit big endian integer according to the NIST specifications. It may be that only the least significant (rightmost) bits are incremented, but that will usually not make a difference unless you pass the 2^32 - 1 or 2^64 - 1 value.
For the sake of compatibility you could decide to use the first (leftmost) 12 bytes as random nonce, and leave the latter ones to zero, then let the implementation of the CTR do the increments. In that case you simply use a 96 bit / 12 byte random at the start, in that case there is no need for a packet counter.
You are however limited to 2^32 * 16 bytes of plaintext until the counter uses up all the available bits. It is implementation specific if the counter returns to zero or if the nonce itself is included in the counter, so you may want to limit yourself to messages of 68,719,476,736 = ~68 GB (yes that's base 10, Giga means 1,000,000,000).
because of the birthday problem you've got a 2^48 chance (48 = 96 / 2) of creating a collision for the nonce (required for each message, not each block), so you should limit the amount of messages;
if some attacker tricks you into decrypting 2^32 packets for the same nonce, you run out of counter.
In case this is still incompatible (test!) then use the initial 8 bytes as nonce. Unfortunately that does mean that you need to limit the number of messages because of the birthday problem.
Further investigations sheds some light on the CommonCrypto problem:
In iOS 6.0.1 the little endian option is now unimplemented. Also, I have verified that CommonCrypto is bugged in that the CCCryptorReset method does not in fact change the IV as it should, instead using pre-existing IV. The behaviour in 6.0.1 is different from 5.x.
This is potentially a security risc, if you initialize CommonCrypto with a nulled IV, and reset it to the actual IV right before encrypting. This would lead to all your data being encrypted with the same (nulled) IV, and multiple streams (that perhaps should have different IV but use same key) would leak data via a simple XOR of packets with corresponding ctr.