I've found several website exchange data with the browser through a seemingly similar encoding consisting of [A-z0-9/+] such as
11UmFuZG9tSVYkc2RlIyh9YWJdm48m5cJDWuLLIYaigN6cCfiKOtB/Xb00yCTJRLU1iZilyDQAF8okuqrX2gHm2pVsKeYHWxDNNLB9teqqv2msRNJADEmHqHJWhIpgq6kB4LRtzrU7x1ms9VfChurilER4JfNiBiNqsetbxxPaDn3+SZFhbqDh1V6ufUeNbri49YKKra3WOe4=
or
11UmFuZG9tSVYkc2RlIyh9YWJdm48m5cJDWuLLIYaigN6cCfiKOtB/Xb00yCTJRLU1iZilyDQAF8okuqrX2gHm2pVsKeYHWxDN9IdK3oj1qFvfsjLKRaHSu60i6RSRagBfu5CtrYWAiHIZXA5wKwOGZwh5lUwHApYhPZzbdpfT6ubbVr5WFlrO5VHDBw9bFi1hduxQaia2i8k=
or
11UmFuZG9tSVYkc2RlIyh9YUbM7JQKVn66Jan93YWDhnDQ1nd8g669ScUfvmjw724qB521xitv+brNAzNRj46wgJBqF3rIKqgVRRsk8d9ccybqIhLm0E76CUjS/XnuWXzxZM+wTAx8lSbkiqHWg7hcwb7Fr8bMqW0d+1gZqUJto3zdImOPwDTNRFmEmRhWnOEAV86C5yFfCyw=
It appears to be more than a simple ID - rather encoded data of some sort.
I've tried Base 64 - the second half (following the /) appears to be a valid base64 encoding of non Text data.
The hex values of the example strings (base64 decoded after the /) are:
5d bd 34 c8 24 c9 44 b5 35 89 98 a5 c8 34 00 17 ca 24 ba aa d7 da 01 e6 da 95 6c 29 e6 07 5b 10 cd 34 b0 7d b5 ea aa bf 69 ac 44 d2 40 0c 49 87 a8 72 56 84 8a 60 ab a9 01 e0 b4 6d ce b5 3b c7 59 ac f5 57 c2 86 ea e2 94 44 78 25 f3 62 06 23 6a b1 eb 5b c7 13 da 0e 7d fe 49 91 61 6e a0 e1 d5 5e ae 7d 47 8d 6e b8 b8 f5 82 8a ad ad d6 39 ee
5d bd 34 c8 24 c9 44 b5 35 89 98 a5 c8 34 00 17 ca 24 ba aa d7 da 01 e6 da 95 6c 29 e6 07 5b 10 cd f4 87 4a de 88 f5 a8 5b df b2 32 ca 45 a1 d2 bb ad 22 e9 14 91 6a 00 5f bb 90 ad ad 85 80 88 72 19 5c 0e 70 2b 03 86 67 08 79 95 4c 07 02 96 21 3d 9c db 76 97 d3 ea e6 db 56 be 56 16 5a ce e5 51 c3 07 0f 5b 16 2d 61 76 ec 50 6a 26 b6 8b c9
5e 7b 96 5f 3c 59 33 ec 13 03 1f 25 49 b9 22 a8 75 a0 ee 17 30 6f b1 6b f1 b3 2a 5b 47 7e d6 06 6a 50 9b 68 df 37 48 98 e3 f0 0d 33 51 16 61 26 46 15 a7 38 40 15 f3 a0 b9 c8 57 c2 cb
Related
I want to understand a weird observation I had while working with h264 encoded AVC files. In such files, each NAL unit is preceded by 1/2/4 bytes that encode the size of the NAL unit (without the size header). However, there has been some cases where the end of one NAL unit doesn't take to another NAL unit, instead it takes to a sequence of some data till it eventually reaches another NAL unit
For example, starting at 01ADF399, we have:
*00 00 35 99 41* 9A 12 25 83 A5 F0 7A 08 41 0C 1E 02 50 20 03 80 A4 12 30 B6 44 90
0C E1 CD A2 68 9F 9F 2E C0 2E 1C 18 A2 28 8A 85 65 AC 0B 7D F1 DD 0F ...
Which ends at 01AE2936 as:
21 1A 54 6D FC 34 3B 32 FA AA D6 71 8A BC 92 F9 95 79 75 8A E6 B5 A9 77 24 4A AC
1C E3 EF A2 9D 97 30 51 D1 7B EB 75 FD B2 8D 8A A7 B9 47 8A C6 59 1A 32 FB 9E 77
03 8E CA 67 23 B7 52 EE 2E A4 BA 43 CE F9 CD 46 48 C5 C4 41 35 32 F3 D6 5B CD BE
DA B8 B3 3E 1B 33 87 AE 65 A0 45 74 DF EB 37 96 2F DA 9C ...
Clearly not the start of an NAL unit (since FC doesn't have forbidden zero bit)
However, at 01AE7535, we have the following:
00 00 27 EA 41 9A 14 29 81 29 7C 80 41 04 18 98 44 64 01 C6 54 00 0D 9F 34 58 71
E5 0A A6 CD B0 4B 38 60 7F E6 1F C8 00 24 7A 06 E5 9B 21 99 F0 51 24 9B ...
Which is the start of an NAL unit. I verified that those two NAL units are consecutive since filtering the file to the annex B h264 format removes the unknown data in between and places those two exact NAL units right next to each other.
I tried looking at ISO 14496 part 15 but it doesn't mention anything about this.
I have this code (can be run in a playground):
import UIKit
import CryptoKit
let url: URL = URL(string: "https://apple.com")!
final class SSLExtractor: NSObject, URLSessionDelegate {
private var session: URLSession!
init(url: URL) {
super.init()
let session = URLSession.init(configuration: .default, delegate: self, delegateQueue: nil)
session.dataTask(with: url).resume()
}
func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: #escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {
guard challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodServerTrust,
let serverTrust = challenge.protectionSpace.serverTrust,
let publicKey = SecTrustCopyKey(serverTrust),
let publicKeyData = SecKeyCopyExternalRepresentation(publicKey, nil)
else { return }
let publicKeyHash = SHA256.hash(data: publicKeyData as Data)
print("publicKey: \(publicKey)")
print("publicKey: \(publicKeyData)")
print("publicKey: \((publicKeyData as Data).base64EncodedString() )")
print(publicKeyHash)
}
}
let extractor = SSLExtractor(url: url)
Supposedly the last print should give me the server's public key:
SHA256 digest: b0faa00170de7c1ac7994644efadb59f149656546394bd22c95527e78f1984b6
However, when I use OpenSSL:
$ openssl s_client -connect apple.com:443 | openssl x509 -pubkey -noout | openssl rsa -pubin -outform der| openssl dgst -sha256
I get a different hash:
1786e93d8e16512ea34ea1475e39597e77d7e39239ba1a97dcd71f97e64d6619
How to get the correct hash ?
Edit: Also tried
let certificate = SecTrustGetCertificateAtIndex(serverTrust, 0),
let certifKey = SecCertificateCopyKey(certificate),
let certifPubKey = SecKeyCopyPublicKey(certifKey),
let certifPubKeyData = SecKeyCopyExternalRepresentation(certifPubKey, nil)
But I got the same result
Only sort of an answer but too much for comments. You found that the 'external' publickey provided (and hashed) by Swift is a suffix of that used by OpenSSL.
OpenSSL uses, as I referenced, the 'SPKI' (SubjectPublicKeyInfo) structure defined by X.509/PKIX=RFC5280 section 4 which is a DER-encoded ASN.1 SEQUENCE containing an AlgorithmIdentifier and a BIT STRING cotaining embedded algorithm-specific data. RFC 7468 section 13 (which partly officializes OpenSSL, although it doesn't say so) confirms this is the content of a 'standard' public key representation, and RFC 3279 section 2.3.1 defines that for RSA (which the Apple cert's key is) the content of the BIT STRING part is the ASN.1 structure RSAPublicKey which actually was defined (though 3279 doesn't say so for the key, while it does for the signature in 2.2.1) in PKCS1 currently RFC8017 section A.1.1 (but unchanged from earlier versions).
Because of the way DER encoding works, the content of the BIT STRING -- in this case the ASN.1 structure RSAPublicKey -- is exactly a suffix of the encoding of the whole SPKI.
If we look at, and parse, the SPKI OpenSSL gets from the cert (with x509 -pubkey)
$ openssl rsa -pubin -in applespki -outform der |od -Ax -tx1
writing RSA key
000000 30 82 01 22 30 0d 06 09 2a 86 48 86 f7 0d 01 01
000010 01 05 00 03 82 01 0f 00 30 82 01 0a 02 82 01 01
000020 00 e0 e5 ca aa 34 ea 32 d1 f5 e3 56 e5 05 e8 07
000030 c3 d3 3b 86 93 60 94 37 20 9f 8d d0 17 8f ba da
000040 16 f1 b2 6a bc 41 7a 6f dc 22 87 4b 05 e8 57 48
000050 56 3c da a2 02 e5 57 73 94 95 18 dd 7c c9 b0 68
000060 fe 17 2c 8b 6f fa 42 a9 b1 a8 77 88 22 d4 41 08
000070 08 d9 80 59 92 bc e9 3a 0a 17 e0 2b 13 fe bf ec
000080 69 7d 61 15 14 21 71 73 a0 70 fd 6d a0 0f 46 13
000090 60 8d c1 bd 8c 66 60 04 05 e0 44 f0 a1 53 b7 00
0000a0 7f a3 f3 55 da d2 6c c6 dd 7f 83 79 1f 6e cb 1d
0000b0 78 3e d9 9f fa 58 34 38 41 c5 70 c1 c7 dd ea b0
0000c0 81 c0 d4 a3 18 a4 da 02 15 b8 cb 48 10 fa 42 86
0000d0 75 1c 55 51 6b 48 6e 37 43 98 09 af 4f 52 c0 c8
0000e0 75 40 a5 e7 65 ba 62 2a be 6c 2a 6d 72 5b 82 21
0000f0 d1 75 97 ea 7e 21 a1 04 f4 76 7c 85 db 50 c7 9f
000100 b5 d8 f7 80 15 ba a5 83 9e 2c da f0 73 c6 14 9a
000110 fd 35 07 41 4b 53 21 8d 0d 01 f1 05 b3 04 05 83
000120 cb 02 03 01 00 01
000126
$ openssl asn1parse -i -dump -in applespki1
0:d=0 hl=4 l= 290 cons: SEQUENCE
4:d=1 hl=2 l= 13 cons: SEQUENCE
6:d=2 hl=2 l= 9 prim: OBJECT :rsaEncryption
17:d=2 hl=2 l= 0 prim: NULL
19:d=1 hl=4 l= 271 prim: BIT STRING
0000 - 00 30 82 01 0a 02 82 01-01 00 e0 e5 ca aa 34 ea .0............4.
0010 - 32 d1 f5 e3 56 e5 05 e8-07 c3 d3 3b 86 93 60 94 2...V......;..`.
0020 - 37 20 9f 8d d0 17 8f ba-da 16 f1 b2 6a bc 41 7a 7 ..........j.Az
0030 - 6f dc 22 87 4b 05 e8 57-48 56 3c da a2 02 e5 57 o.".K..WHV<....W
0040 - 73 94 95 18 dd 7c c9 b0-68 fe 17 2c 8b 6f fa 42 s....|..h..,.o.B
0050 - a9 b1 a8 77 88 22 d4 41-08 08 d9 80 59 92 bc e9 ...w.".A....Y...
0060 - 3a 0a 17 e0 2b 13 fe bf-ec 69 7d 61 15 14 21 71 :...+....i}a..!q
0070 - 73 a0 70 fd 6d a0 0f 46-13 60 8d c1 bd 8c 66 60 s.p.m..F.`....f`
0080 - 04 05 e0 44 f0 a1 53 b7-00 7f a3 f3 55 da d2 6c ...D..S.....U..l
0090 - c6 dd 7f 83 79 1f 6e cb-1d 78 3e d9 9f fa 58 34 ....y.n..x>...X4
00a0 - 38 41 c5 70 c1 c7 dd ea-b0 81 c0 d4 a3 18 a4 da 8A.p............
00b0 - 02 15 b8 cb 48 10 fa 42-86 75 1c 55 51 6b 48 6e ....H..B.u.UQkHn
00c0 - 37 43 98 09 af 4f 52 c0-c8 75 40 a5 e7 65 ba 62 7C...OR..u#..e.b
00d0 - 2a be 6c 2a 6d 72 5b 82-21 d1 75 97 ea 7e 21 a1 *.l*mr[.!.u..~!.
00e0 - 04 f4 76 7c 85 db 50 c7-9f b5 d8 f7 80 15 ba a5 ..v|..P.........
00f0 - 83 9e 2c da f0 73 c6 14-9a fd 35 07 41 4b 53 21 ..,..s....5.AKS!
0100 - 8d 0d 01 f1 05 b3 04 05-83 cb 02 03 01 00 01 ...............
we can see the content of the BIT STRING, skipping the first byte 00 because of the way DER works for BIT STRING, and thus starting at offset 24=0x18 and continuing to the end, is itself a DER encoding of RSAPublicKey (30 82 01 0a is the SEQUENCE, 02 82 01 01 ... is the INTEGER (signed) modulus, 02 03 01 00 01 is the INTEGER (signed) publicExponent). OpenSSL 1.0.0 up (which is now ubiquitous, though I remember when it wasn't) can extract this, and get your expected hash:
$ openssl rsa -pubin -in applespki -RSAPublicKey_out -outform der |od -Ax -tx1
writing RSA key
000000 30 82 01 0a 02 82 01 01 00 e0 e5 ca aa 34 ea 32
000010 d1 f5 e3 56 e5 05 e8 07 c3 d3 3b 86 93 60 94 37
000020 20 9f 8d d0 17 8f ba da 16 f1 b2 6a bc 41 7a 6f
000030 dc 22 87 4b 05 e8 57 48 56 3c da a2 02 e5 57 73
000040 94 95 18 dd 7c c9 b0 68 fe 17 2c 8b 6f fa 42 a9
000050 b1 a8 77 88 22 d4 41 08 08 d9 80 59 92 bc e9 3a
000060 0a 17 e0 2b 13 fe bf ec 69 7d 61 15 14 21 71 73
000070 a0 70 fd 6d a0 0f 46 13 60 8d c1 bd 8c 66 60 04
000080 05 e0 44 f0 a1 53 b7 00 7f a3 f3 55 da d2 6c c6
000090 dd 7f 83 79 1f 6e cb 1d 78 3e d9 9f fa 58 34 38
0000a0 41 c5 70 c1 c7 dd ea b0 81 c0 d4 a3 18 a4 da 02
0000b0 15 b8 cb 48 10 fa 42 86 75 1c 55 51 6b 48 6e 37
0000c0 43 98 09 af 4f 52 c0 c8 75 40 a5 e7 65 ba 62 2a
0000d0 be 6c 2a 6d 72 5b 82 21 d1 75 97 ea 7e 21 a1 04
0000e0 f4 76 7c 85 db 50 c7 9f b5 d8 f7 80 15 ba a5 83
0000f0 9e 2c da f0 73 c6 14 9a fd 35 07 41 4b 53 21 8d
000100 0d 01 f1 05 b3 04 05 83 cb 02 03 01 00 01
00010e
$ openssl rsa -pubin -in applespki -RSAPublicKey_out -outform der |openssl sha256
writing RSA key
(stdin)= b0faa00170de7c1ac7994644efadb59f149656546394bd22c95527e78f1984b6
This only works for RSA. It might be interesting to see how your Swift code handles a certificated non-RSA key, although at present those are hard to find on the public web; the only stable ones I currently know of are at 'badssl' like https://ecc256.badssl.com .
I'm looking at an RSA private key in PEM format. When I decode the base64 string and review the components of the key, some of them have an extra byte, specifically the modulus, P, DP, and IQ. They all have a leading 0x00 byte. I'm handling this by just trimming the byte[] down to the expected lengths of 256 or 128 so I can use them with .NET RSAParameters and RSACryptoServiceProvider, but wondering why some of these INTEGER structures have the extra byte while others don't. It would appear that online and other libraries that decode the PEM to XML, etc handle this gracefully, so is this part of the RFC, just something that you have to protect against, or only a concern because I'm using the .NET libraries after decoding? Here's an example of the modulus with 257 bytes:
00 B7 55 AA 3F 14 89 BC CE ED AF 80 1C 54 2A DF
AB 3C 6A 44 B4 55 58 90 0E 0D 32 96 E6 EF 35 2D
AD B7 44 A7 AB CE 6F D3 BB 9D B4 4B FD 0A DE 87
96 03 55 23 81 49 FE 1B 3E CE 62 B6 2F B1 4C 33
E4 F8 C2 09 5F 0E 10 78 22 D0 F3 C9 BF B9 AC AC
11 00 17 28 09 23 10 D5 8A C9 2B E2 86 96 A7 E2
57 68 D7 3B 63 BE 74 ED B8 02 E2 63 EF F5 40 85
0C A6 9F D0 B6 88 36 8B 4E 6B 35 27 BE 11 CC C8
C3 0A 66 25 E0 AB B6 DD 6D E6 2B AF 9E 1C D7 11
CE 5F E7 C8 1F EB 3D 79 B3 B2 E1 FF D8 20 6D 76
A2 43 9E 20 67 58 97 39 46 D8 73 F6 F0 76 01 E0
61 8E 4A EE C4 03 A6 44 C7 D3 50 E3 C8 62 CF 33
D1 37 6B 85 F5 D4 3C 6D 1F 1A 14 B3 30 B5 E0 82
A5 94 83 4F 7A 17 DA 86 2B F7 2A 47 A3 5F D2 D5
7B 96 32 86 27 5E 2A 6A 85 6E C6 24 15 A9 09 65
BB 04 8C 0D 39 F7 15 D4 F0 F8 5F 0F B0 1D A7 2F
D7
Here's an example of the "D" parameter that is not padded with a leading 0x00:
04 07 EF 8A 5D 88 3D C7 8B 00 5D DF C1 96 03 BE
FF 20 1D 0C A8 07 BF 7B 1F 9D 2A 26 3F C2 3A 93
E4 40 B5 33 18 E1 EA 94 E8 7D C0 61 EF F8 3E A0
F4 C7 CD 75 0D 4C 72 0A EA 7C CF 26 B3 4E 4A A1
D1 3A 6A FA 55 11 D5 A2 66 57 C5 EA DA 49 4A AB
41 06 41 52 1A 1C 47 A5 BA 90 A5 75 72 20 94 E0
79 24 AA 60 A2 12 6E 1B AA AC 91 A7 F8 0B 88 21
64 14 85 81 4D F3 6D 12 B7 56 BE DD F6 04 3B B1
CC 95 A6 8C 9D A6 8D BF 05 C1 72 A4 0B 03 75 F6
40 B6 8E 25 91 3D 87 84 CD 23 EF 2C 29 13 DD A7
75 6E 48 F4 DE 49 98 4F B7 09 CF 5A A3 F5 39 05
37 C8 2B 79 64 F0 B8 AD 11 EF 79 FD 78 C0 6B 2B
50 7F DE BC 59 3D D1 A1 90 59 B7 7E 57 B4 2C A0
D2 20 D2 D6 7C 4A B3 3C 63 5D FA E6 67 18 58 AC
F3 EF 0E E1 C0 C9 B6 D9 8C D1 8E 3D CE 8A FF F0
12 BF C2 FE 72 DC 07 E4 3C 00 5B BE 05 D9 5A 61
And the DP parameter without leading 0:
3E 50 B2 28 A3 B1 71 F3 D5 31 B1 2D FD B3 60 4B
57 F8 C1 46 C7 89 B7 95 F4 7D AE 54 F2 EA 11 98
F7 61 93 30 50 D9 24 19 BF 7F 06 19 DB 97 01 06
8B 20 D7 7A 5E 1A FA 76 9A 0E 27 46 AB FF 25 3C
74 61 E2 9B 3E CE A5 F9 58 40 70 15 94 F2 58 3E
DB E4 90 91 3C 50 B0 24 8F C7 A7 55 EB E3 59 A7
5D 01 19 29 4F F9 F9 E6 EB 78 D1 93 14 61 E4 5C
36 D7 E7 82 58 E7 C5 60 21 F3 1E 5A D4 49 C6 D1
The RSA modulus is a positive number, and ASN.1 integers are all signed.
So if the leading 0x00 wasn't there, this byte encoding would represent a negative number because the first byte would have the high bit set (0xB7 >= 0x80). As a consequence, the 0x00 gets inserted into the DER data stream.
.NET's representation is based on the Windows CAPI representation. CAPI uses domain knowledge to know that the values are all unsigned integers, and then omits the leading 0x00 bytes. So it's up to whoever translates between the DER data and the .NET/CAPI data to add or remove the bytes as needed.
These values are encoded as INTEGER ASN type which uses two-complement notation. That is if most significant bit is set to 1, then the number is negative. However, all numbers (modulus, exponents, primes) in key are positive numbers and prepended with extra leading zero octet to denote positive integer. If the most significant bit is already set to 0, then no extra bytes are added.
I am currently trying to enable a spnego based SSO Application.
As part of this I seek to get the delegated credentials.
How to verify that the credential I get after
GSSContext.acceptSecContext(gss, 0, gss.length); is a delegated credential or not.
GSSContext.getCredDelegState() is true.
My primary doubt is whether the server principal in the ticket should be
krbtgt/ABC.XYZ.COM#ABC.XYZ.COM or should be the service (HTTP/host.ABC.XYZ.com) for which the ticket was delegated?``
Delegated Credential is.....[GSSCredential:
client#ABC.XYZ.COM 1.2.840.113554.1.2.2 Initiate [Ticket (hex) =
0000: 61 81 F3 30 81 F0 A0 03 02 01 05 A1 0F 1B 0D 55 a..0...........A
0010: 53 2E 4F 52 41 43 4C 45 2E 43 4F 4D A2 22 30 20 BC.XYZ.COM."0
0020: A0 03 02 01 00 A1 19 30 17 1B 06 6B 72 62 74 67 .......0...krbtg
0030: 74 1B 0D 55 53 2E 4F 52 41 43 4C 45 2E 43 4F 4D t..ABC.XYZ.COM
0040: A3 81 B3 30 81 B0 A0 03 02 01 01 A1 03 02 01 01 ...0............
0050: A2 81 A3 04 81 A0 35 DF 47 76 64 F4 79 80 7C 2B ......5.Gvd.y..+
0060: 33 92 54 3B EA C8 F4 DE 62 19 37 AE BF 27 7C 9E 3.T;....b.7..'..
0070: BA 1D E6 BA B0 90 3D 2E 41 7E 41 0D 07 2A 2D AB ......=.A.A..*-.
0080: 33 88 11 40 69 CE 07 6E CE 84 C3 B1 95 22 CE 8B 3..#i..n....."..
0090: 76 98 01 61 C3 FA B7 CB 9F 95 C8 1F C7 AF F4 48 v..a...........H
00A0: 87 35 5D 83 CB D2 DA 86 56 2B 80 BC 33 CD A8 B8 .5].....V+..3...
00B0: 7B 8B 5E A2 D5 6C 27 F3 D6 ED 4E 77 17 68 7E C6 ..^..l'...Nw.h..
00C0: 85 00 9D B5 43 87 44 BC EA F5 67 12 12 96 B4 AE ....C.D...g.....
00D0: C6 B0 49 5C 08 9E 6F BB 7E E4 91 32 D0 0A 68 FA ..I\..o....2..h.
00E0: 9E 9C 6A 16 96 45 B6 87 58 86 ED 3B 12 EA 98 B8 ..j..E..X..;....
00F0: 6E A9 F9 3E D4 D1 n..>..
Client Principal = client#ABC.XYZ.COM
Server Principal = krbtgt/ABC.XYZ.COM#ABC.XYZ.COM
Session Key = EncryptionKey: keyType=1 keyBytes (hex dump)=
0000: 8F B5 AB AE B9 89 F1 5D
Forwardable Ticket true
Forwarded Ticket true
Proxiable Ticket false
Proxy Ticket false
Postdated Ticket false
Renewable Ticket false
Initial Ticket false
Auth Time = Mon Jun 17 03:53:45 PDT 2013
Start Time = Mon Jun 17 06:49:34 PDT 2013
End Time = Tue Jun 18 03:53:45 PDT 2013
Renew Till = null
Client Addresses Null ]]
I am using a linux based KDC and linux hosts for this.
Is there any reference to what the delegated ticket should be like?
The delegated ticket has been created for the UPN of your machine, if you use MIT/Heimdal KDC (no experience with) it's probably host/fqdn#REALM. In Windows (AD KDC) it is hostname$#REALM. Only that machine is able to extract the delegated credential.
The whole point of delegated credential is that there should be no difference between a delegated and a initial credential for an end service.
Can anybody give me the S-Box used for 128 bit AES CFB mode of encryption.
Will this S-Box be same for every 128 -bit AES CFB Implementation.
Thanks
Here it is:
| 0 1 2 3 4 5 6 7 8 9 a b c d e f
---|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|
00 |63 7c 77 7b f2 6b 6f c5 30 01 67 2b fe d7 ab 76
10 |ca 82 c9 7d fa 59 47 f0 ad d4 a2 af 9c a4 72 c0
20 |b7 fd 93 26 36 3f f7 cc 34 a5 e5 f1 71 d8 31 15
30 |04 c7 23 c3 18 96 05 9a 07 12 80 e2 eb 27 b2 75
40 |09 83 2c 1a 1b 6e 5a a0 52 3b d6 b3 29 e3 2f 84
50 |53 d1 00 ed 20 fc b1 5b 6a cb be 39 4a 4c 58 cf
60 |d0 ef aa fb 43 4d 33 85 45 f9 02 7f 50 3c 9f a8
70 |51 a3 40 8f 92 9d 38 f5 bc b6 da 21 10 ff f3 d2
80 |cd 0c 13 ec 5f 97 44 17 c4 a7 7e 3d 64 5d 19 73
90 |60 81 4f dc 22 2a 90 88 46 ee b8 14 de 5e 0b db
a0 |e0 32 3a 0a 49 06 24 5c c2 d3 ac 62 91 95 e4 79
b0 |e7 c8 37 6d 8d d5 4e a9 6c 56 f4 ea 65 7a ae 08
c0 |ba 78 25 2e 1c a6 b4 c6 e8 dd 74 1f 4b bd 8b 8a
d0 |70 3e b5 66 48 03 f6 0e 61 35 57 b9 86 c1 1d 9e
e0 |e1 f8 98 11 69 d9 8e 94 9b 1e 87 e9 ce 55 28 df
f0 |8c a1 89 0d bf e6 42 68 41 99 2d 0f b0 54 bb 16
It can also be found in FIPS Pub 197, the official standard.
And yes, it is exactly the same for every implementation of AES. Otherwise you wouldn't be able to encrypt something others could decrypt or vice-versa.